クロスサイトリクエストフォージェリ「クロスサイトスクリプティング」とは異なります。Webアプリケーションの脆弱性の一つ[1]もしくはそれを利用した攻撃。読まれる事もある[2][3])、またはXSRF。1990年代はイメタグ攻撃とも呼ばれていた[要出典]。(CWE-352)[5]。ひとつとして分類されており[5]、全く異なる種類の攻撃である。CSRF脆弱性とは以下のような攻撃(CSRF攻撃)を可能にする脆弱性を指す[1]:攻撃者はブラウザなどのユーザ・クライアントを騙し、意図しないリクエスト(たとえばHTTPリクエスト)をWebサーバに送信させる。Webアプリケーションがユーザ・クライアントからのリクエストを十分検証しないで受け取るよう設計されている場合、このリクエストを正規のものとして扱ってしまい、被害が発生する。CSRF攻撃はURL[1]、画像の読み込み[1]、XMLHttpRequest[1]などを利用して実行される。具体的被害としてはデータの漏えい[1]、意図しないコードの実行[1]、権限の取得[1]、なりすまし[1]、防御メカニズムの回避[1]、アプリケーションデータの読み取り[1]などがありうる。権限の取得が可能な場合、その被害はユーザの持つ権限に依存する。騒動)といった事件が発生した。詳細[編集]CSRF脆弱性を具体例を用いて説明する。HTTP/1.1というHTTPリクエストが銀行のWebサイトに向かって送信されるものとする[7]。HTTP/1.1というURLを公開掲示板に張ったり、不特定多数にメールしたりする[7]。HTTP/1.1というHTTPリクエストが銀行に向かって送信される[7]。この際たまたまALICEが銀行にログインしていたら、銀行のサーバはこのリクエストを送金要求だと解釈してしまい、ALICEの口座からMARIAの口座に一万ドルが不正送金されてしまう。本来、銀行のサーバは、ALICEのブラウザから受け取ったHTTPリクエストが本当にALICE当人の意志で送られたものなのかをチェックし、チェックを通った時のみHTTPリクエストを受け付けるべきである。上述した銀行サーバのWebサイトの実装にはこのようなチェック機構は備わっておらず、これがMARIAにCSRF攻撃を可能にしてしまった原因である。HTTP/1.1のようにセッションIDを含め、これが正しいIDであるかを銀行サーバ側でチェックするというものがある(重要な注:説明を平易にする為この対策を記したが、この対策方法はセッションハイジャックの危険という別の問題をはらんでいるので使用すべきではない[8][9]。よい対策方法は次章を参照)。このようにすると、MARIAは(少なくとも前述の方法では)CSRF攻撃を行うことができない。セッションIDはALICEがログインするたびにランダムに決まるものなので、MARIAにはセッションIDを予想してURLを公開掲示板などに記載するのは不可能だからである[10]。偽装工作[編集]CSRFの攻撃者は、攻撃用URLが銀行のものだとALICEに気づかれないようにするため、偽装工作をはかる事がある。border="0">を貼り付けたりする事で偽装できる[11]。後者の偽装工作の場合、この画像が貼られたサイトにアクセスしてしまうと、ブラウザが自動的にこの「画像」を読み込んでしまうので、攻撃が成功する。対策[編集]利用者側[編集]ログインしていることが必要な手続きにおいては、ログアウトをしてセッションを破棄しておけば認証確認の段階で手続きが拒否されるので被害が抑えられる。必要な手続きを済ませたならログアウトすることが望ましい。Webサイト・Webアプリケーション製作者側[編集]フォームを受け付けるWebサイト管理者(情報機器の設定のためにウェブインタフェースを提供しているあらゆるメーカーを含む)は、以下のような対策を施さなければならない。POST時にその両者の値の同一性を検証するという方法がある(偽造を防ぐため、formのhidden値は暗号学的ハッシュ関数を通しておく)。外部サイトの作成者はこれらの値を偽造することができないため、不正なPOSTはすべてサーバ側で検出できる。(但し、HTTPヘッダ・インジェクション、セッションハイジャック、クロスサイトスクリプティングについても対策を施さなければ意味がない。Form生成用ライブラリの多くは、この機能をあらかじめ備えている。用いて対策することもできる。CSRFは外部のドメインからのHTTPリクエストであるため、HTTPのRefererを取得し照合することによって外部サイトからの不正なPOSTを判別できる。第三者のサイトから、Refererを偽造したPOSTを送信させることは不可能であるため、Referer値をチェックすることで不正な送信を検出できる。HTTPリクエストの送信者自身がRefererを偽造することは容易であるため、Referer照合はCSRFの対策とはなっても、不正なセッションが作成されることへの対策にはならない。リファラはブラウザの設定で非送信にすることができ、リファラを非送信に設定した利用者は正規のサイトから手続きを行っても不正としてはじかれてしまう。事案[編集]日本においては、2005年4月19日ごろにmixiで発生したはまちや2による「ぼくはまちちゃん」騒動(後述)によってその存在が広く知られることとなった。1997年5月に起きた農水省オウムソング事件も本手法を用いたものである。こんにちはこんにちは!!」という定型文が、投稿者の意図せぬまま書きこまれるという事態が発生した。この書き込みには別のmixi利用者を同様の罠におびき寄せるような細工がしてあったため、同メッセージは急速にmixi上にあふれることとなった。利用者たちは当初、いったい何がどうしてどういったことが起こっているのかわからず、慌てることとなった。mixi利用者の中には少なからぬ数のシステムエンジニアもいたことから、そういった利用者の間には、次第に、この混乱の原因がクロスサイトリクエストフォージェリであることがわかっていった。memo」や「ITmediaニュース」、「インプレスwatch」などでも取りあげられるなど、mixiの外でも話題となった[12]。2009年12月上旬に開始したばかりのサービスであるAmebaなうでも同様の事態が起きた[13]。横浜市ウェブサイトの意見投稿コーナーに、同市保土ヶ谷区の小学校への無差別殺人予告が投稿された事件で、犯人はクロスサイトリクエストフォージェリを利用することで無関係の他人に書込をさせていたことが判明している。被害にあったパソコンを所有していた大学生が逮捕・起訴され保護観察処分となったが、のちに神奈川県警が誤認逮捕を認めて謝罪した[14]。2008年7月3日閲覧。共通脆弱性タイプ一覧CWE概説。これらのHTTPリクエストやURLはOWASP(英語版)のサイト[3]に脆弱性の例として記載されているものを引用した。厳密に言うと、MARIAが適当に予想したセッションIDがたまたま本物のセッションIDと一致して攻撃が成功してしまう場合がある。これを防ぐためセッションIDとしてエントロピーが十分に大きいものを使う必要がある。これらもOWASP(英語版)のサイト[3]に記載されている偽装工作の例を参考にして作成。2016年9月15日閲覧。2016年9月15日閲覧。2016年9月15日閲覧。脆弱性が生まれる原理と対策の実践』SBクリエイティブ、2011年3月1日。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。Cookieに関する声明モバイルビュ。