「クロスサイトリクエストフォージェリ」の版間の差分

編集の要約なし
'''クロスサイトリクエストフォージェリ'''(Cross site request forgeries、略記:'''CSRF'''、または'''XSRF''')は、[[World Wide Web|WWW]] における攻撃手法の一つである
具体例として、掲示板に意図しない書き込みをさせられたり、[[オンラインショップ]]で買い物をさせられたりするなどの被害が起こる。また、設定用[[ウェブページ]]を通して、[[ルーター]]や[[無線LAN]]等のあらゆる情報機器の設定の、意図しない変更をされる可能性もある。
 
日本のニュースサイトにおいては[[mixi]] で[[2005年]][[4月19日]]ごろに発生した[[はまちや2]]による「ぼくはまちちゃん」騒動(後述)によってその存在が広く知られることとなった。また、90年代は'''イメタグ攻撃'''とも呼ばれていた。
 
1997年5月に起きた[[農水省オウムソング事件]]も、本手法を用いたものとして知られる。
 
具体的な被害として、掲示板に意図しない書き込みをさせられたり、[[オンラインショップ]]で買い物をさせられたりするなどの被害起こ挙げられる。また、設定用[[ウェブページ]]を通して、[[ルーター]]や[[無線LAN]]等のあらゆる情報機器のWebインタフェースが攻撃対象となれば、それらの機器の設定の、意図しないを勝手に変更される可能性もある。
 
日本のニュースサイトにおいては[[mixi]] で[[2005年]][[4月19日]]ごろに[[mixi]]で発生した[[はまちや2]]による「ぼくはまちちゃん」騒動(後述)によってその存在が広く知られることとなった。また、901990年代は'''イメタグ攻撃'''とも呼ばれていた。1997年5月に起きた[[農水省オウムソング事件]]も本手法を用いたものである
 
== 原理 ==
攻撃の大まかな流れは以下の通り。
# 攻撃者が、攻撃用の Web ページを作成して WWW 上に公開する。
#:(WWW上ででなくとも、未対策のHTMLメーラーにウェブページをHTMLメールとして送信するだけでもよいなど、様々な攻撃手法が考えうる。)
# 第三者が、攻撃用の Web ページにアクセスする。
# 第三者は、攻撃者が用意した任意の HTTP リクエストを送信させられる。
== 対策 ==
=== 利用者側 ===
クライアント側でCSRFの被害を根本的に防止する手法は特にないと考えて良い。CSRF自体、http_requestHTTPリクエストの根本的な問題を孕んだものであり、本来想定されていなかったものでもある。
 
よって、対策はWebサイトの管理者や開発者が行うべきであり、利用者が対策することは、対応するセキュリティアプリケーションを導入する以外には、通常存在しない。
<!--以下、有効な対策手法ではないためコメントアウト--><!--
CSRFによる被害を軽減するために、利用者側で出来る対策の一つは、認証手段としての[[HTTP cookie|Cookie]] の使用を最小限に留めることである。クロスサイトリクエストフォージェリの攻撃の中には、ブラウザが送信する Cookie 情報に依存しているものがあるため、Cookie をこまめに破棄することで被害を受ける可能性を少なくすることが出来る。
 
認証制の Web システムの中には、[[mixi]] や [[Wikipedia]] のように、Cookie を使って自動的にログインする機能を持つものがあるが、攻撃を受ける可能性を少なくするために、そのような機能を利用しないようにするか、こまめにログアウトしておくことが望ましい。
 
そのほか、任意の Web システムを利用している最中は、むやみに他のサイト(あらゆる情報機器の設定用[[ウェブページ]]を含む)を閲覧しないようにすることも大切である。(セッション情報やcookie情報をCSRFに悪用される可能性がある。)
 
上記の前提として、攻撃者が用意した攻撃用の Web ページを踏まない事も重要である。(HTMLメーラーは使用しないか、イメージブロック機能などの対策を施したものを使用する。)-->
 
=== Webサイト管理者側 ===
フォームを受け付けるWebサイト管理者(および情報機器設定用[[ウェブインタフェジ]]を用意しているあらゆる情報機器のメーカーを含む)は、点についてような対策が必要であるを施さなければならない
 
CSRFは、外部formからのhttp_requestであるため、環境変数のhttp_refererを取得し照合することによって簡単に判定することが可能である。攻撃者自身の環境ではhttp_refererを捏造することが可能であるが、CSRFは匿名性を重視するため、第三者のインターネット接続環境で実行させることが重要となる。第三者の環境においてhttp_refererを偽装させる事は、上記に述べられる手法では不可能であるため、http_refererをモニタリングするのみで簡単に対策することが出来る。掲示板スクリプトは、掲示板荒らしの対策として同様な機能を実装しているものが大半である。
 
http_refererの情報に頼らない方法として、FormをHTTP GETする際に、[[暗号論的擬似乱数生成器|暗号論的擬似乱数]]を[[電子署名]]([[メッセージ認証コード]])付きの[[Cookie]]値およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある。Cookieには電子署名が付けられているため、第三者はこれを捏造することができず、不正なPOSTを送信させることができない。現代的なHTML Form生成用ライブラリは、この仕組みの実現を支援する機能を備えている。
CSRFは、外部formからのhttp_requestであるため、環境変数のhttp_refererを取得し照合することによって簡単に判定することが可能である。
 
<!--以下、一般的な対策手法ではないためコメントアウト--><!--いえ、この説明が少し悪いだけで、このアプローチは本質的なものであるので(refererベースよりずっといい)、改善して上に加えました。--><!--
攻撃者自身の環境ではhttp_refererを捏造することが可能であるが、CSRFは匿名性を重視するため、第三者のインターネット接続環境で実行させることが重要となる。第三者の環境においてhttp_refererを偽装させる事は、上記に述べられる手法では不可能であるため、http_refererをモニタリングするのみで簡単に対策することが出来る。掲示板スクリプトは、掲示板荒らしの対策として同様な機能を実装しているものが大半である。
<!--以下、一般的な対策手法ではないためコメントアウト--><!--
第三者が知り得ない情報をフォームに入力させる(あるいはフォームの hidden パラメータに設定しておく)というのが基本的な対策方針である。ここで利用する第三者が知り得ない情報は、推測されにくい文字列であり、かつ総当り攻撃に対して耐性がある必要がある。具体的には以下の方法が挙げられる。
;認証情報を入力させる:認証制の Web システムの場合、入力フォームにユーザIDとパスワードを含めるという方法がある。システムの利用者から見れば、既にログイン画面で認証を行っているため冗長な操作であるが、クロスサイトリクエストフォージェリの対策としては最も効果がある。
匿名利用者