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

クロスサイトリクエストフォージェリ  は、Webアプリケーションの脆弱性の一つCWE-352もしくはそれを利用した攻撃。略称はCSRF、またはXSRF。リクエスト強要IPA、セッションライディング  とも呼ばれる。1990年代はイメタグ攻撃とも呼ばれていたdate=2016年9月}}。脆弱性をツリー型に分類するCWEではCSRFをデータ認証の不十分な検証  による脆弱性のひとつとして分類している 。

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

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

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

1. 詳細
-----

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

BOB100

というHTTPリクエストが銀行のWebサイトに向かって送信されるものとするname="owasp"。

攻撃者MARIAは

MARIA10000

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

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

MARIA10000

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

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

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

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

GET =13276598501

のようにセッションIDとは別の送金用のtokenを含め、これが正しいtokenであるかを銀行サーバ側でチェックするというものがある。

このようにすると、MARIAはCSRF攻撃を行うことができない。tokenはALICEがログインするたびにランダムに決まるなど、MARIAがtokenを予想してURLを公開掲示板などに記載するのは困難な為である。

1.1. 偽装工作
---------

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

と記載したりname="owasp2"、サイズ0x0の画像

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

2. 対策
-----

2.1. 利用者側
---------

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

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

フォームを受け付けるWebサイト管理者は、以下のような対策を施さなければならない。

よく知られた対策方法として、FormをHTTP GETする際に、十分な長さの暗号論的擬似乱数値をformのhidden値として発行し、HTTP POST時にサーバーに保存していた値とPOSTされてきた値の同一性を検証するという方法がある。外部サイトの作成者はこれらの値を推測することが困難なため、不正なPOSTはサーバ側で検出できる。現代的なHTML Form生成用ライブラリの多くは、この機能をあらかじめ備えている。

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

3. 事案
-----

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

3.1. 「ぼくはまちちゃん」 騒動
------------------

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

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

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

4. 脚注
-----

4.1. 注釈
-------

4.2. 出典
-------

5. 関連項目
-------

6. 参考文献
-------

独立行政法人 情報処理推進機構 セキュリティーセンター，[1]