|
== 対策 ==
=== 利用者側 ===
クライアント側でCSRFの被害を根本的に防止する手法は特にないと考えて良い。CSRF自体HTTPリクエストの根本的な問題を孕んだものであり、本来想定されていなかったものでもある。よって、対策はWebサイトの管理者や開発者が行うべきであり、利用者が対策することは、対応するセキュリティアプリケーションを導入する以外には、通常存在しない。
よって、対策はWebサイトの管理者や開発者が行うべきであり、利用者が対策することは、対応するセキュリティアプリケーションを導入する以外には、通常存在しない。
<!--以下、有効な対策手法ではないためコメントアウト--><!--
CSRFによる被害を軽減するために、利用者側で出来る対策の一つは、認証手段としての[[HTTP cookie|Cookie]] の使用を最小限に留めることである。クロスサイトリクエストフォージェリの攻撃の中には、ブラウザが送信する Cookie 情報に依存しているものがあるため、Cookie をこまめに破棄することで被害を受ける可能性を少なくすることが出来る。
認証制の Web システムの中には、[[mixi]] や [[Wikipedia]] のように、Cookie を使って自動的にログインする機能を持つものがあるが、攻撃を受ける可能性を少なくするために、そのような機能を利用しないようにするか、こまめにログアウトしておくことが望ましい。
そのほか、任意の Web システムを利用している最中は、むやみに他のサイト（あらゆる情報機器の設定用[[ウェブページ]]を含む）を閲覧しないようにすることも大切である。（セッション情報やcookie情報をCSRFに悪用される可能性がある。）
上記の前提として、攻撃者が用意した攻撃用の Web ページを踏まない事も重要である。（HTMLメーラーは使用しないか、イメージブロック機能などの対策を施したものを使用する。）-->
=== Webサイト管理者側 ===
現代的な対策方法の１つとして、FormをHTTP GETする際に、[[暗号論的擬似乱数生成器|暗号論的擬似乱数]]を[[Cookie]]値（しばしば改ざん防止のために[[メッセージ認証コード]]も付けられる）およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある。外部サイトの作成者はこれらの値を偽造することができないため、不正なPOSTはすべてサーバ側で遮断される。現代的なHTML Form生成用ライブラリは、この仕組みの実現を支援する機能を備えている。
http_referer[[HTTPリファラ]] (Referer) を用いて対策することもできる。CSRFは外部formからのHTTPリクエストであるため、環境変数HTTPのhttp_refererRefererを取得し照合することによって外部サイトからの不正なPOSTを判別することができる。攻撃者自身の環境ではhttp_refererを捏造することが可能であるが、CSRFは匿名性を重視するため、第三者のサインターネット接続環境で実行から、Refererを偽造したPOSTを送信させることが重要となる。第三者の環境においてhttp_refererを偽装させる事は、上記に述べられる手法では不可能であるため、http_refererReferer値をモニタリングチェックするのみことで簡単に対策することが出来る。掲示板スクリプトは、掲示板荒らしの対策として同様な機能を実装しているものが大半である。
== 「ぼくはまちちゃん」 騒動==
| 