「クロスサイトリクエストフォージェリ」の版間の差分
編集の要約なし |
→対策: 特定のWeb serverに依存した表記をしない |
||
| 69行目: | 69行目: | ||
== 対策 == |
== 対策 == |
||
=== 利用者側 === |
=== 利用者側 === |
||
クライアント側でCSRFの被害を根本的に防止する手法は特にないと考えて良い。CSRF自体HTTPリクエストの根本的な問題を孕んだものであり、本来想定されていなかったものでもある。 |
クライアント側でCSRFの被害を根本的に防止する手法は特にないと考えて良い。CSRF自体HTTPリクエストの根本的な問題を孕んだものであり、本来想定されていなかったものでもある。よって、対策はWebサイトの管理者や開発者が行うべきであり、利用者が対策することは、対応するセキュリティアプリケーションを導入する以外には、通常存在しない。 |
||
よって、対策はWebサイトの管理者や開発者が行うべきであり、利用者が対策することは、対応するセキュリティアプリケーションを導入する以外には、通常存在しない。 |
|||
<!--以下、有効な対策手法ではないためコメントアウト--><!-- |
|||
CSRFによる被害を軽減するために、利用者側で出来る対策の一つは、認証手段としての[[HTTP cookie|Cookie]] の使用を最小限に留めることである。クロスサイトリクエストフォージェリの攻撃の中には、ブラウザが送信する Cookie 情報に依存しているものがあるため、Cookie をこまめに破棄することで被害を受ける可能性を少なくすることが出来る。 |
|||
認証制の Web システムの中には、[[mixi]] や [[Wikipedia]] のように、Cookie を使って自動的にログインする機能を持つものがあるが、攻撃を受ける可能性を少なくするために、そのような機能を利用しないようにするか、こまめにログアウトしておくことが望ましい。 |
|||
そのほか、任意の Web システムを利用している最中は、むやみに他のサイト（あらゆる情報機器の設定用[[ウェブページ]]を含む）を閲覧しないようにすることも大切である。（セッション情報やcookie情報をCSRFに悪用される可能性がある。） |
|||
上記の前提として、攻撃者が用意した攻撃用の Web ページを踏まない事も重要である。（HTMLメーラーは使用しないか、イメージブロック機能などの対策を施したものを使用する。）--> |
|||
=== Webサイト管理者側 === |
=== Webサイト管理者側 === |
||
| 83行目: | 76行目: | ||
現代的な対策方法の１つとして、FormをHTTP GETする際に、[[暗号論的擬似乱数生成器|暗号論的擬似乱数]]を[[Cookie]]値（しばしば改ざん防止のために[[メッセージ認証コード]]も付けられる）およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある。外部サイトの作成者はこれらの値を偽造することができないため、不正なPOSTはすべてサーバ側で遮断される。現代的なHTML Form生成用ライブラリは、この仕組みの実現を支援する機能を備えている。 |
現代的な対策方法の１つとして、FormをHTTP GETする際に、[[暗号論的擬似乱数生成器|暗号論的擬似乱数]]を[[Cookie]]値（しばしば改ざん防止のために[[メッセージ認証コード]]も付けられる）およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある。外部サイトの作成者はこれらの値を偽造することができないため、不正なPOSTはすべてサーバ側で遮断される。現代的なHTML Form生成用ライブラリは、この仕組みの実現を支援する機能を備えている。 |
||
[[HTTPリファラ]] (Referer) を用いて対策することもできる。CSRFは外部formからのHTTPリクエストであるため、HTTPのRefererを取得し照合することによって外部サイトからの不正なPOSTを判別することができる。第三者のサイトから、Refererを偽造したPOSTを送信させることは不可能であるため、Referer値をチェックすることで対策することが出来る。 |
|||
== 「ぼくはまちちゃん」 騒動== |
== 「ぼくはまちちゃん」 騒動== |
||
2013年5月17日 (金) 13:26時点における版
クロスサイトリクエストフォージェリ（Cross site request forgeries、略記：CSRF、またはXSRF）は、WWW における攻撃手法の一つである。
具体的な被害としては、掲示板に意図しない書き込みをさせられたり、オンラインショップで買い物をさせられたりするなどが挙げられる。また、ルーターや無線LAN等の情報機器のWebインタフェースが攻撃対象となれば、それらの機器の設定を勝手に変更される可能性もある。
日本においては、2005年4月19日ごろにmixiで発生したはまちや2による「ぼくはまちちゃん」騒動（後述）によってその存在が広く知られることとなった。また、1990年代はイメタグ攻撃とも呼ばれていた。1997年5月に起きた農水省オウムソング事件も本手法を用いたものである。
原理
攻撃の大まかな流れは以下の通り。
- 攻撃者が、攻撃用の Web ページを作成して WWW 上に公開する。
- （WWW上ででなくとも、未対策のHTMLメーラーにウェブページをHTMLメールとして送信するなど、様々な攻撃手法が考えうる。）
- 第三者が、攻撃用の Web ページにアクセスする。
- 第三者は、攻撃者が用意した任意の HTTP リクエストを送信させられる。
- 送信させられた HTTP リクエストによって、攻撃者の意図した操作が行われる。
- （ここで「第三者」とは、被攻撃サイトに意図せずアクセスさせられると言う意味で用いている。）
簡単な HTML を例示して、その原理を具体的に解説する。
- attack.html
<!DOCTYPE html>
<html lang="ja">
<head>
<title>攻撃用のページ</title>
</head>
<body onload="document.attackform.submit();">
<form name="attackform" method="post" action="http://example.com/bbs/register.cgi">
<input type="hidden" name="title" value="攻撃者が指定した題名">
<input type="hidden" name="article" value="攻撃者が指定した本文">
<input type="submit" value="送信">
</form>
</body>
</html>
- clickme.html
<!DOCTYPE html>
<html lang="ja">
<head>
<title>誘導用のページ</title>
</head>
<body>
<p>ようこそいらっしゃいました。</p>
<iframe width="1" height="1" src="attack.html"></iframe>
</body>
</html>
第三者が clickme.html にアクセスすると、以下のような流れで http://example.com/bbs/register.cgi に自動的に書き込み処理が行われる。
- clickme.html のインラインフレーム内で attack.html が呼び出される。
- attack.html の body 要素に指定された onload 属性により、ページが読み込まれるのと同時に、そのページ内のフォームの送信ボタンが自動的に押される。
- http://example.com/bbs/register.cgi に自動的にアクセスが行われ、attack.html のフォーム内に指定された内容の書き込みを行う。
なお、これらの出来事はすべて clickme.html 内に存在する 1 ピクセル四方のインラインフレームで行われるため、被害者に攻撃を受けたことを気付かれにくくなっている。「ぼくはまちちゃん」騒動で使用された攻撃では、インラインフレームの代わりに img タグを利用した巧妙な偽装が行われていた。
imgタグに偽装した手法は以下のようなものである。
<html>
<body>
<img src="http://example.com/bbs/register.cgi?title=攻撃者が指定した題名&article=攻撃者が指定した本文">
</body>
</html>
この手法では、http request methodはpostでなくgetとなってしまうため、文字数に限界があるものの、実質1行ですべてを表す事が可能であり、上記例であれば本文や題名を変更したhtmlタグを複数記述することによって対象とするregister.cgiに複数回のアクセスを行う事が可能となる。 こういった手法が日本において初めて用いられたのは1997年のあやしいわーるどであり、当時は掲示板荒らしの手法、またメールボムの手法として、悪戯に用いられていた[1]。
対策
利用者側
クライアント側でCSRFの被害を根本的に防止する手法は特にないと考えて良い。CSRF自体HTTPリクエストの根本的な問題を孕んだものであり、本来想定されていなかったものでもある。よって、対策はWebサイトの管理者や開発者が行うべきであり、利用者が対策することは、対応するセキュリティアプリケーションを導入する以外には、通常存在しない。
Webサイト管理者側
フォームを受け付けるWebサイト管理者（および情報機器設定用ウェブインタフェースを用意しているあらゆる情報機器のメーカー）は、以下のような対策を施さなければならない。
現代的な対策方法の１つとして、FormをHTTP GETする際に、暗号論的擬似乱数をCookie値（しばしば改ざん防止のためにメッセージ認証コードも付けられる）およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある。外部サイトの作成者はこれらの値を偽造することができないため、不正なPOSTはすべてサーバ側で遮断される。現代的なHTML Form生成用ライブラリは、この仕組みの実現を支援する機能を備えている。
HTTPリファラ (Referer) を用いて対策することもできる。CSRFは外部formからのHTTPリクエストであるため、HTTPのRefererを取得し照合することによって外部サイトからの不正なPOSTを判別することができる。第三者のサイトから、Refererを偽造したPOSTを送信させることは不可能であるため、Referer値をチェックすることで対策することが出来る。
「ぼくはまちちゃん」 騒動
2005年4月中旬ごろ、SNS サイトの一つである mixi において、突如として「ぼくはまちちゃん！ こんにちはこんにちは!!」という定型文が、投稿者の意図せぬまま書きこまれるという事態が発生した。この書き込みには別の mixi 利用者を同様の罠に誘き寄せるような細工がしてあったため、同メッセージは急速に mixi 上に溢れることとなった。利用者たちは当初、いったい何がどうしてどういったことが起こっているのかわからず、慌てることとなった。mixi 利用者の中には少なからぬ数のシステムエンジニアもいたことから、そういった利用者の間には、次第に、この混乱の原因がクロスサイトリクエストフォージェリであることがわかっていった。しかし、その後の mixi 運営当局側の対処が付け焼き刃的で抜本的なものでなかったこと[要出典]、また告知が不十分だったり不親切だったりするのではないかといった指摘があったこと[要出典]などの要因もあいまって、mixi の利用者に困惑がひろがり、ついには「セキュリティホール memo」や「IT Mediaニュース」、「インプレスwatch」などでも取りあげられるなど、 mixi の外でも話題となった[2]。
また、2009年12月上旬に開始したばかりのサービスであるAmebaなうでも同様の事態が起きた[3]。
![[icon]](/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Wiki_letter_w_cropped.svg){kind=small} | この節の加筆が望まれています。 |
横浜市小学校襲撃予告事件
横浜市ウェブサイトの意見投稿コーナーに、同市保土ヶ谷区の小学校への無差別殺人予告が投稿された事件で、犯人はクロスサイトリクエストフォージェリを利用することで無関係の他人に書込をさせていたことが判明している。被害にあったパソコンを所有していた大学生が逮捕・起訴され保護観察処分となったが、のちに神奈川県警が誤認逮捕を認めて謝罪した[4]。
脚注
- ^ http://scan.netsecurity.ne.jp/article/2002/08/01/6139.html
- ^ 「ぼくはまちちゃん」 ――知られざるCSRF攻撃 - ＠IT
- ^ http://www.itmedia.co.jp/news/articles/0912/11/news033.html
- ^ 神奈川県警幹部、誤認逮捕を謝罪…少年宅を訪問 2012年10月20日22時31分 読売新聞