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

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
Wanson (会話 | 投稿記録)
284 回編集
73行目: 73行目:
フォームを受け付けるWebサイト管理者（情報機器の設定のためにウェブインタフェースを提供しているあらゆるメーカーを含む）は、以下のような対策を施さなければならない。
フォームを受け付けるWebサイト管理者（情報機器の設定のためにウェブインタフェースを提供しているあらゆるメーカーを含む）は、以下のような対策を施さなければならない。


よく知られた対策方法として、FormをHTTP GETする際に、[[暗号論的擬似乱数生成器|暗号論的擬似乱数]]値（いわゆる[[nonce]]）を、[[Cookie]]値およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある（偽造を防ぐため、どちらかの値は暗号論的に安全なハッシュ関数を通しておく）。外部サイトの作成者はこれらの値を偽造することができないため、不正なPOSTはすべてサーバ側で検出できる。現代的なHTML Form生成用ライブラリの多くは、この機能をあらかじめ備えている。
よく知られた対策方法として、FormをHTTP GETする際に、[[暗号論的擬似乱数生成器|暗号論的擬似乱数]]値（いわゆる[[nonce]]）を、[[Cookie]]値およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある（偽造を防ぐため、どちらかの値は[[暗号学的ハッシュ関数]]を通しておく）。外部サイトの作成者はこれらの値を偽造することができないため、不正なPOSTはすべてサーバ側で検出できる。現代的なHTML Form生成用ライブラリの多くは、この機能をあらかじめ備えている。


より安易な方法として、[[HTTPリファラ]] (Referer) を用いて対策することもできる。CSRFは外部のドメインからのHTTPリクエストであるため、HTTPのRefererを取得し照合することによって外部サイトからの不正なPOSTを判別できる。第三者のサイトから、Refererを偽造したPOSTを送信させることは不可能であるため、Referer値をチェックすることで不正な送信を検出できる。ただしHTTPリクエストの送信者自身がRefererを偽造することは容易であるため、Referer照合はCSRFの対策とはなっても、不正なセッションが作成されることへの対策にはならない点に注意が必要である。また、リファラはブラウザの設定で容易に非送信にすることができる。リファラを非送信に設定した利用者は正規のサイトから手続きを行っても不正としてはじかれてしまうため、この対策方法の導入には検討が必要である。
より安易な方法として、[[HTTPリファラ]] (Referer) を用いて対策することもできる。CSRFは外部のドメインからのHTTPリクエストであるため、HTTPのRefererを取得し照合することによって外部サイトからの不正なPOSTを判別できる。第三者のサイトから、Refererを偽造したPOSTを送信させることは不可能であるため、Referer値をチェックすることで不正な送信を検出できる。ただしHTTPリクエストの送信者自身がRefererを偽造することは容易であるため、Referer照合はCSRFの対策とはなっても、不正なセッションが作成されることへの対策にはならない点に注意が必要である。また、リファラはブラウザの設定で容易に非送信にすることができる。リファラを非送信に設定した利用者は正規のサイトから手続きを行っても不正としてはじかれてしまうため、この対策方法の導入には検討が必要である。

2014年11月24日 (月) 05:45時点における版

クロスサイトリクエストフォージェリ（Cross site request forgeries、略記：CSRF、またはXSRF）は、WWW における攻撃手法のひとつである。

具体的な被害としては、掲示板に意図しない書き込みをさせられたり、オンラインショップで買い物をさせられたりするなどが挙げられる。また、ルーターや無線LAN等の情報機器のWebインタフェースが攻撃対象となれば、それらの機器の設定を勝手に変更される懸念もある。

日本においては、2005年4月19日ごろにmixiで発生したはまちや2による「ぼくはまちちゃん」騒動（後述）によってその存在が広く知られることとなった。また、1990年代はイメタグ攻撃とも呼ばれていた。1997年5月に起きた農水省オウムソング事件も本手法を用いたものである。

原理

攻撃の大まかな流れは下記の通り。

  1. 攻撃者が、攻撃用の Web ページを作成して WWW 上に公開する。
    （WWW上ででなくとも、未対策のHTMLメーラーにウェブページをHTMLメールとして送信するなど、様々な攻撃手法が考えうる。）
  2. 第三者が、攻撃用の Web ページにアクセスする。
  3. 第三者は、攻撃者が用意した任意の HTTP リクエストを送信させられる。
  4. 送信させられた 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 に自動的に書き込み処理が行われる。

  1. clickme.html のインラインフレーム内で attack.html が呼び出される。
  2. attack.html の body 要素に指定された onload 属性により、ページが読み込まれるのと同時に、そのページ内のフォームの送信ボタンが自動的に押される。
  3. 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]。

対策

利用者側

ログインしていることが必要な手続きにおいては、ログアウトをしてセッションを破棄しておけば認証確認の段階で手続きが拒否されるので被害が抑えられる。必要な手続きを済ませたならログアウトすることが望ましい。

Webサイト・Webアプリケーション製作者側

フォームを受け付けるWebサイト管理者（情報機器の設定のためにウェブインタフェースを提供しているあらゆるメーカーを含む）は、以下のような対策を施さなければならない。

よく知られた対策方法として、FormをHTTP GETする際に、暗号論的擬似乱数値（いわゆるnonce）を、Cookie値およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある（偽造を防ぐため、どちらかの値は暗号学的ハッシュ関数を通しておく）。外部サイトの作成者はこれらの値を偽造することができないため、不正なPOSTはすべてサーバ側で検出できる。現代的なHTML Form生成用ライブラリの多くは、この機能をあらかじめ備えている。

より安易な方法として、HTTPリファラ (Referer) を用いて対策することもできる。CSRFは外部のドメインからのHTTPリクエストであるため、HTTPのRefererを取得し照合することによって外部サイトからの不正なPOSTを判別できる。第三者のサイトから、Refererを偽造したPOSTを送信させることは不可能であるため、Referer値をチェックすることで不正な送信を検出できる。ただしHTTPリクエストの送信者自身がRefererを偽造することは容易であるため、Referer照合はCSRFの対策とはなっても、不正なセッションが作成されることへの対策にはならない点に注意が必要である。また、リファラはブラウザの設定で容易に非送信にすることができる。リファラを非送信に設定した利用者は正規のサイトから手続きを行っても不正としてはじかれてしまうため、この対策方法の導入には検討が必要である。

「ぼくはまちちゃん」 騒動

2005年4月中旬ごろ、SNS サイトの一つである mixi において、突如として「ぼくはまちちゃん！ こんにちはこんにちは!!」という定型文が、投稿者の意図せぬまま書きこまれるという事態が発生した。この書き込みには別の mixi 利用者を同様の罠におびき寄せるような細工がしてあったため、同メッセージは急速に mixi 上にあふれることとなった。利用者たちは当初、いったい何がどうしてどういったことが起こっているのかわからず、慌てることとなった。mixi 利用者の中には少なからぬ数のシステムエンジニアもいたことから、そういった利用者の間には、次第に、この混乱の原因がクロスサイトリクエストフォージェリであることがわかっていった。しかし、その後の mixi 運営当局側の対処が付け焼き刃的で抜本的なものでなかったこと[要出典]、また告知が不十分だったり不親切だったりするのではないかといった指摘があったこと[要出典]などの要因もあいまって、mixi の利用者に困惑がひろがり、ついには「セキュリティホール memo」や「IT Mediaニュース」、「インプレスwatch」などでも取りあげられるなど、 mixi の外でも話題となった[2]。
また、2009年12月上旬に開始したばかりのサービスであるAmebaなうでも同様の事態が起きた[3]。

横浜市小学校襲撃予告事件

「パソコン遠隔操作事件」を参照

横浜市ウェブサイトの意見投稿コーナーに、同市保土ヶ谷区の小学校への無差別殺人予告が投稿された事件で、犯人はクロスサイトリクエストフォージェリを利用することで無関係の他人に書込をさせていたことが判明している。被害にあったパソコンを所有していた大学生が逮捕・起訴され保護観察処分となったが、のちに神奈川県警が誤認逮捕を認めて謝罪した[4]。

脚注

[脚注の使い方]
  1. ^ http://scan.netsecurity.ne.jp/article/2002/08/01/6139.html
  2. ^ 「ぼくはまちちゃん」 ――知られざるCSRF攻撃 - ＠IT
  3. ^ http://www.itmedia.co.jp/news/articles/0912/11/news033.html
  4. ^ 神奈川県警幹部、誤認逮捕を謝罪…少年宅を訪問 2012年10月20日22時31分 読売新聞

関連項目

外部リンク

クロスサイト攻撃
インジェクション攻撃 (CWE-74)
スプーフィング攻撃
セッションハイジャック関連
DoS攻撃
サイドチャネル攻撃
不適切な入力確認 (CWE-20)
未分類
対策
関連項目
「https://ja.wikipedia.org/w/index.php?title=クロスサイトリクエストフォージェリ&oldid=53610306」から取得