クロスサイトリクエストフォージェリ（Cross site request forgeries）は、Webアプリケーションの脆弱性の一つもしくはそれを利用した攻撃。略称はCSRF(シーサーフ（"sea-surf"）と読まれる事もある)、またはXSRF。リクエスト強要、セッションライディング（Session Riding）とも呼ばれる。1990年代はイメタグ攻撃とも呼ばれていた。脆弱性をツリー型に分類するCWEではCSRFをデータ認証の不十分な検証(CWE-345)による脆弱性のひとつとして分類している(CWE-352)。なおCSRFの正式名称はクロスサイトスクリプティング（XSS)と似ているが、XSSは不適切な入力確認(CWE-20)によるインジェクション(CWE-74)のひとつとして分類されており、全く異なる種類の攻撃である。CSRF脆弱性とは以下のような攻撃(CSRF攻撃)を可能にする脆弱性を指す：攻撃者はブラウザなどのユーザ・クライアントを騙し、意図しないリクエスト（たとえばHTTPリクエスト）を Web サーバに送信させる。Webアプリケーションがユーザ・クライアントからのリクエストを十分検証しないで受け取るよう設計されている場合、このリクエストを正規のものとして扱ってしまい、被害が発生する。CSRF攻撃はURL、画像の読み込み、XMLHttpRequest などを利用して実行される。具体的被害としてはデータの漏えい、意図しないコードの実行、権限の取得、なりすまし、防御メカニズムの回避、アプリケーションデータの読み取りなどがありうる。権限の取得が可能な場合、その被害はユーザの持つ権限に依存する。ログインしていない状態でも起こりうる主な被害としてユーザ・クライアントに電子掲示板などへ書き込みをさせる行為があり、これを利用してユーザを装った犯罪予告（例：パソコン遠隔操作事件）や大量の書き込みをさせるDoS攻撃（例：「ぼくはまちちゃん」 騒動）といった事件が発生した。CSFR脆弱性を具体例を用いて説明する。今ある銀行のWebサイト（標的サイト）にログインしているユーザALICEが自身の口座からBOBという別のユーザの口座に100ドルを送金する際、ALICEのブラウザからというHTTPリクエストが銀行のWebサイトに向かって送信されるものとする。攻撃者MARIAはというURLを公開掲示板に張ったり、不特定多数にメールしたりする。銀行のユーザALICEがこのURLをクリックしてしまうと、ALICEのブラウザからというHTTPリクエストが銀行に向かって送信される。この際たまたまALICEが銀行にログインしていたら、銀行のサーバはこのリクエストを送金要求だと解釈してしまい、ALICEの口座からMARIAの口座に一万ドルが不正送金されてしまう。本来、銀行のサーバは、ALICEのブラウザから受け取ったHTTPリクエストが本当にALICE当人の意志で送られたものなのかをチェックし、チェックを通った時のみHTTPリクエストを受け付けるべきである。しかし上述した銀行サーバのWebサイトの実装にはこのようなチェック機構は備わっておらず、これがMARIAにCSRF攻撃を可能にしてしまった原因である。上述の攻撃に対する対策の一例として、送金のHTTPリクエストにのようにセッションIDを含め、これが正しいIDであるかを銀行サーバ側でチェックするというものがある（重要な注：説明を平易にする為この対策を記したが、この対策方法はセッションハイジャックの危険という別の問題をはらんでいるので使用すべきではない。よりよい対策方法は次章を参照）。このようにすると、MARIAは（少なくとも前述の方法では）CSRF攻撃を行うことができない。セッションIDはALICEがログインするたびにランダムに決まるものなので、MARIAにはセッションIDを予想してURLを公開掲示板などに記載するのは不可能だからである。CSRFの攻撃者は、攻撃用URLが銀行のものだとALICEに気づかれないようにするため、偽装工作をはかる事がある。例えば攻撃用URLを直接記載する代わりにと記載したり 、サイズ0x0の画像（のふりをした攻撃用URL）を貼り付けたりする事で偽装できる。なお、後者の偽装工作の場合、この画像が貼られたサイトにアクセスしてしまうと、ブラウザが自動的にこの「画像」を読み込んでしまうので、攻撃が成功する。ログインしていることが必要な手続きにおいては、ログアウトをしてセッションを破棄しておけば認証確認の段階で手続きが拒否されるので被害が抑えられる。必要な手続きを済ませたならログアウトすることが望ましい。フォームを受け付けるWebサイト管理者（情報機器の設定のためにウェブインタフェースを提供しているあらゆるメーカーを含む）は、以下のような対策を施さなければならない。よく知られた対策方法として、FormをHTTP GETする際に、暗号論的擬似乱数値（いわゆるnonce）を、Cookie値またはセッション、およびformのhidden値として発行し、HTTP POST時にその両者の値の同一性を検証するという方法がある（偽造を防ぐため、formのhidden値は暗号学的ハッシュ関数を通しておく）。外部サイトの作成者はこれらの値を偽造することができないため、不正な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」や「IT Mediaニュース」、「インプレスwatch」などでも取りあげられるなど、 mixi の外でも話題となった。
また、2009年12月上旬に開始したばかりのサービスであるAmebaなうでも同様の事態が起きた。横浜市ウェブサイトの意見投稿コーナーに、同市保土ヶ谷区の小学校への無差別殺人予告が投稿された事件で、犯人はクロスサイトリクエストフォージェリを利用することで無関係の他人に書込をさせていたことが判明している。被害にあったパソコンを所有していた大学生が逮捕・起訴され保護観察処分となったが、のちに神奈川県警が誤認逮捕を認めて謝罪した。

出典:wikipedia