クロスサイトリクエストフォージェリ

情報セキュリティ > 脆弱性・攻撃手法 > クロスサイトリクエストフォージェリ
曖昧さ回避 「クロスサイトスクリプティング」とは異なります。

クロスサイトリクエストフォージェリ (cross-site request forgery) は、Webアプリケーションの脆弱性の一つ[1]もしくはそれを利用した攻撃。略称はCSRF（シーサーフ (sea-surf) と読まれる事もある[2][3]）、またはXSRF。リクエスト強要[4]、セッションライディング (session riding[3]) とも呼ばれる。1990年代はイメタグ攻撃とも呼ばれていた[要出典]。脆弱性をツリー型に分類するCWEではCSRFをデータ認証の不十分な検証 (CWE-345) による脆弱性のひとつとして分類している (CWE-352)[5]。

なおCSRFの正式名称はクロスサイトスクリプティング (XSS) と似ているが、XSSは不適切な入力確認 (CWE-20) によるインジェクション (CWE-74) のひとつとして分類されており[5]、全く異なる種類の攻撃である。

CSRF脆弱性とは以下のような攻撃（CSRF攻撃）を可能にする脆弱性を指す[1]：攻撃者はブラウザなどのユーザ・クライアントを騙し、意図しないリクエスト（たとえばHTTPリクエスト）をWebサーバに送信させる。Webアプリケーションがユーザ・クライアントからのリクエストを十分検証しないで受け取るよう設計されている場合、このリクエストを正規のものとして扱ってしまい、被害が発生する。CSRF攻撃はURL[1]、画像の読み込み[1]、XMLHttpRequest[1]などを利用して実行される。

具体的被害としてはデータの漏えい[1]、意図しないコードの実行[1]、権限の取得[1]、なりすまし[1]、防御メカニズムの回避[1]、アプリケーションデータの読み取り[1]などがありうる。権限の取得が可能な場合、その被害はユーザの持つ権限に依存する。ログインしていない状態でも起こりうる主な被害としてユーザ・クライアントに電子掲示板などへ書き込みをさせる行為があり[6]、これを利用してユーザを装った犯罪予告（例：パソコン遠隔操作事件）や大量の書き込みをさせるDoS攻撃（例：「ぼくはまちちゃん」 騒動）といった事件が発生した。

詳細

[編集]

CSRF脆弱性を具体例を用いて説明する。 今ある銀行のWebサイト（標的サイト）にログインしているユーザALICEが自身の口座からBOBという別のユーザの口座に100ドルを送金する際、ALICEのブラウザから 

GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

というHTTPリクエストが銀行のWebサイトに向かって送信されるものとする[注釈 1]。

攻撃者MARIAは 

http://bank.com/transfer.do?acct=MARIA&amount=10000 HTTP/1.1

というURLを公開掲示板に張ったり、不特定多数にメールしたりする[注釈 1]。

銀行のユーザALICEがこのURLをクリックしてしまうと、ALICEのブラウザから 

GET http://bank.com/transfer.do?acct=MARIA&amount=10000 HTTP/1.1

というHTTPリクエストが銀行に向かって送信される[注釈 1]。この際たまたまALICEが銀行にログインしていたら、銀行のサーバはこのリクエストを送金要求だと解釈してしまい、ALICEの口座からMARIAの口座に一万ドルが不正送金されてしまう。

本来、銀行のサーバは、ALICEのブラウザから受け取ったHTTPリクエストが本当にALICE当人の意志で送られたものなのかをチェックし、チェックを通った時のみHTTPリクエストを受け付けるべきである。

しかし上述した銀行サーバのWebサイトの実装にはこのようなチェック機構は備わっておらず、これがMARIAにCSRF攻撃を可能にしてしまった原因である。

上述の攻撃に対する対策の一例として、送金のHTTPリクエストに 

GET http://bank.com/transfer.do?token=13276598501&acct=BOB&amount=100 HTTP/1.1

のようにセッションIDとは別の送金用のtokenを含め、これが正しいtokenであるかを銀行サーバ側でチェックするというものがある（重要な注：説明を平易にする為この対策を記したが、この対策方法(他人に知られてはならない情報をURLへ含む方法？)はセッションハイジャックの危険という別の問題をはらんでいるので使用すべきではない[7][8]。よりよい対策方法は次章を参照）。

このようにすると、MARIAは（少なくとも前述の方法では）CSRF攻撃を行うことができない。tokenはALICEがログインするたびにランダムに決まるなど、MARIAがtokenを予想してURLを公開掲示板などに記載するのは困難な為である[注釈 2]。

偽装工作

[編集]

CSRFの攻撃者は、攻撃用URLが銀行のものだとALICEに気づかれないようにするため、偽装工作をはかる事がある。例えば攻撃用URLを直接記載する代わりに 

<a href="（攻撃用URL）">面白い画像をみつけました</a>

と記載したり[注釈 3]、サイズ0x0の画像（のふりをした攻撃用URL） 

<img src="（攻撃用URL）" width="0" height="0" border="0">

を貼り付けたりする事で偽装できる[注釈 3]。なお、後者の偽装工作の場合、この画像が貼られたサイトにアクセスしてしまうと、ブラウザが自動的にこの「画像」を読み込んでしまうので、攻撃が成功する。

対策

[編集]

利用者側

[編集]

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

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

[編集]

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

よく知られた対策方法として、FormをHTTP GETする際に、十分な長さの暗号論的擬似乱数値（いわゆるnonce）をformのhidden値として発行し、HTTP POST時にサーバーに保存していた値とPOSTされてきた値の同一性を検証するという方法がある。外部サイトの作成者はこれらの値を推測することが困難なため、不正なPOSTはサーバ側で検出できる。（但し、HTTPヘッダ・インジェクション、セッションハイジャック、クロスサイトスクリプティングについても対策を施さなければ意味がない。）現代的なHTML Form生成用ライブラリの多くは、この機能をあらかじめ備えている。

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

事案

[編集]

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

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

[編集]

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

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

[編集]
→「パソコン遠隔操作事件」を参照

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

脚注

[編集]
[脚注の使い方]

注釈

[編集]
  1. ^ a b c これらのHTTPリクエストやURLはOWASP（英語版）のサイト[3]に脆弱性の例として記載されているものを引用した。
  2. ^ 厳密に言うと、MARIAが適当に予想したtokenがたまたま本物のtokenと一致して攻撃が成功してしまう場合がある。これを防ぐためtokenとしてエントロピーが十分に大きいものを使う必要がある。
  3. ^ a b これらもOWASP（英語版）のサイト[3]に記載されている偽装工作の例を参考にして作成。

出典

[編集]
  1. ^ a b c d e f g h i j k CWE-352 2011.
  2. ^ Shiflett, Chris (December 13, 2004). “Security Corner: Cross-Site Request Forgeries”. php|architect (via shiflett.org). 2008年7月3日閲覧。
  3. ^ a b c d OWASP 2016.
  4. ^ IPA 2014.
  5. ^ a b 共通脆弱性タイプ一覧CWE概説。IPA。2016/9/15閲覧
  6. ^ トレンドマイクロ セキュリティ情報 脅威と対策 「クロスサイトリクエストフォージェリ（CSRF）」
  7. ^ 金床 2009.
  8. ^ 徳丸 2011, p. 159,165-166.
  9. ^ 「ぼくはまちちゃん」 ――知られざるCSRF攻撃 - ＠IT
  10. ^ URL踏むと「こんにちは　こんにちは!!」　AmebaなうのCSRF脆弱性で“意図しない投稿”広がる ITmedia
  11. ^ 神奈川県警幹部、誤認逮捕を謝罪…少年宅を訪問 2012年10月20日22時31分 読売新聞

関連項目

[編集]

参考文献

[編集]
  • “CWE-352 クロスサイトリクエストフォージェリ”. JVN iPedia (2011年4月21日). 2016年9月15日閲覧。
  • “セキュアプログラミング講座 Webアプリケーション編 第4章 セッション対策リクエスト強要（CSRF）対策”. 独立行政法人 情報処理推進機構 (IPA) セキュリティーセンター (2014年10月2日). 2016年9月15日閲覧。
  • “Cross-Site Request Forgery (CSRF)”. OWASP（英語版） (2016年5月22日). 2016年9月15日閲覧。
  • 金床 (2009年7月11日). “開発者のための正しいCSRF対策”. 2016年9月15日閲覧。
  • 独立行政法人 情報処理推進機構 セキュリティーセンター，「CSRFについて」（2007年7月12日）
  • 徳丸浩『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』SBクリエイティブ、2011年3月1日。ISBN 978-4797361193。 


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