クロスサイトリクエストフォージェリ(CSRF)とは

3年以上前に更新されました。情報が古い可能性があります。
更新日 : 2019年08月06日

WEBアプリケーションの有名な脆弱性の1つに、CSRF(クロスサイトリクエストフォージェリ)があります。

一言で言うと、悪質なサイトなどを経由して、別のアプリケーションへの意図しないリクエストをクライアントに送信させ、それをアプリケーションが適切なものとして処理してしまうことです。

一言だけでは難しく、イメージも湧きづらいため、詳細に解説していきます。

CSRFとは

CSRFは登場人物が3つ存在します。一般的な内容で説明するとややこしいので、まずは不適切な処理を実行できてしまうWEBアプリケーションを例にとって考えます。
ここではショップサイト(ECサイト)で考えてみましょう。

ECサイトを例にとってCSRFを考える

ECサイトを例にとって考えるため、いくつかの前提情報を決めておきます。
今回は極端な例を使い説明していきます。

前提情報

ECサイトでは、基本機能として以下のようなものがあるとします。

ログイン機能
クライアントがログインし、本人と確認してからショッピングができる
セッションを利用して実現
カートへ商品の追加機能
ログインした セッション情報を利用して、商品をカートに追加する
カートにある商品を購入する機能
ログインされているクライアントのセッション情報やユーザー情報から、購入処理を行う
https://shopping.example.com/cart/buyというURLで、以下のような情報を送ると、購入処理が行われる
address=住所情報

最低限この3つの機能があると考えます。
商品の追加や商品購入は本来はログイン済みのクライアントのみが行なえます。

今回はCSRFを利用してこれらの商品購入などを別の人が行えてしまう状況を作ります。

CSRFの流れ

以下の画像を順番に解説していきます。

まずはCSRFを仕掛ける攻撃側は、ブラウザ上で実行されるスクリプト(JavaScript)を作成し、そのスクリプトを悪意のあるWEBサイトに配置します。ブラウザ上で実行されるため、実行するのはクライアントです。このブラウザは、ECサイトのセッションIDをCookieなどで保持しています。

ポイントとなるのは、

クライアントPC上でスクリプトが実行される
悪意のあるWEBサイトにアクセスした時点でユーザーは気づかないうちにスクリプトが実行されます。
クライアントPCはECサイトのセッションIDを持っている
つまりクライアントPC上からECサイトにアクセスすると、ログイン済みとなっています。

この2点です。

ではクライアントPC上で実行される悪意のあるコードを実行すると、どのようなことが行われるでしょうか。

スクリプトには、ECサイトの購入URLにバックエンド(ユーザーの見えないところ)からアクセスする処理が記載されています。さらに、そのURLにアクセスする際に送るべき住所情報は、悪意のあるサイトを作成した人への配送先になっています。

ではこの悪意のあるWEBサイトに、ECサイトのアカウントを持っているユーザーがアクセスするとどのようなことが起こるでしょうか。順番に解説します。

ユーザーが悪意のあるWEBサイトにアクセス
悪意のあるWEBサイトではスクリプトを実行するようにクライアントPCに命令
ユーザーのクライアントPCでスクリプトが実行される
スクリプトは、ECサイトの購入URLへアクセスさせる。その際に送る住所情報は悪人向け
スクリプトの実行元であるクライアントPCでは、ECサイトのセッションIDをCookieで持っているため、ECサイトへアクセスするとセッションIDも同時に送られる
ECサイトは購入URLへアクセスが来ると、セッションIDを確認し、ユーザーのカートから購入処理を実行。配送先は悪人向け
ユーザーが気づかないうちにカートに入った商品が、見ず知らずの住所あてに発送される

これが一連の流れです。ログイン済みのクライアントPCからECサイトにアクセスする時点で、ECサイトは本人だと誤認してしまいます。ユーザー自身が購入をしようとしてなくても悪意のあるWEBサイトからバックエンドで購入URLへアクセスされてしまいます。

クロスサイトリクエストフォージェリのクロスサイトリクエストというのは、このように正規のECサイト元から購入URLにアクセスするのではなく、全く別のサイト(クロスサイト)からリクエストを受け付けてしまって、それを正しい処理としてECサイトが処理してしまうということです。

ちなみにフォージェリ(forgery)の意味は「偽造」です。

CSRFでの問題は、正規のサイトから来たリクエストではないのに、正しい処理としてサーバーが認識してしまうことです。

逆に言えば、正規のサイトからのリクエストであることを確認できれば、CSRFの対策ができるということです。

CSRF対策の方法

CSRFをされないために、CSRF対策を行う必要があります。

CSRF対策は、上記の正規のサイトからのリクエストであることを確認することで実現可能です。

今回のECサイトの例では、正規のサイトはECサイト自身になります。つまりECサイトから作成されたフォームからのリクエストであることが確認できれば、悪意のあるサイトからのリクエストだった場合は処理を除外すれば、CSRF対策として有効ということになります。

ワンタイムトークンを利用した対策

作成されたフォームが、ECサイトが作成したということを証明するために、ワンタイムトークンというものを利用します。簡単に言うと一時的なパスワードです。

実際の処理の流れは下記のようになります。

ECサイト自身がフォームを作成するとき、そのフォームデータにECサイトが作成した一時的なパスワード情報を隠して埋め込んでおきます。

ユーザーが入力するべきフォームデータを送信するときにその一時的なパスワードもECサイトに送信されます。

ECサイトは、ECサイト自身が作成したパスワードが、送られてきたフォームデータにきちんと入っているかを確認すれば、処理を継続するかを判断できます。

悪意のあるサイトはそのパスワード情報をリクエスト送信時に埋め込むことができないため、このような対策方法になっています。

まとめ

CSRF自体の流れとその対策について説明しました。

ワンタイムトークンなどの生成などを行う手間はありますが、最近のフレームワークにはデフォルトで実装済みであることが多く、適切な使い方をすれば、CSRF対策は自動で行なえます。