Webの攻撃手法に「クロスサイト・リクエストフォージェリ(CSRF)」というものがあります。
これはWebの仕様を利用した攻撃手法です。
東京ディズニーランドならTDL。
Every Little ThingならELT。
クロスサイト・リクエストフォージェリならCSRFです。
メールフォームやBBS、TwitterなどのWebサービスなど、フォームに入力した内容を送信するプログラムの場合はCSRF攻撃が可能ですので、プログラム側で防御策を実装しておく必要があります。
このページではクロスサイト・リクエストフォージェリ(CSRF)の仕組みと、その対策法を解説していきます。
フォーム内容が送信される仕組み
Webページ上で入力した内容を送信する時は、同一ドメイン内からだけでなく他のドメインからでも送信することができてしまいます。
これはWebの仕様です。
ですので例えば「そのページにアクセスしただけ(表示しただけ)で、他人のサイトのお問い合わせフォームにデータを送信する」というような罠のページを作っておき、(Aさんが作ったとします)
その罠ページへ誰か(Bさん)を誘導すれば、(誘導の方法は色々あります)
Aさんが用意した内容をBさんに送信させることができるのです。
つまり、他人になりすまして送信できるということです。
メールフォームでの送信だけでなく、BBSになりすまし投稿ができてしまったら大問題です。犯行予告などを勝手にされてしまいます。
しかも、被害者(Bさん)は自分がなりすまし投稿の被害にあったことに気づくことすらできません。
このように、他のサイトからフォーム内容を送信する攻撃手法をクロスサイト・リクエストフォージェリ(CSRF)といいます。
クロスサイト・リクエストフォージェリ(CSRF)を防ぐためには
上記のようにクロスサイト・リクエストフォージェリ(CSRF)攻撃というのは、「フォーム内容を他のドメインへも送信できる」というWebの仕組みが原因となっています。
これはWebの仕様ですから、変えることはできません。
送信側が変えられない以上は、メールフォームやBBSなどフォーム内容を受信するプログラム側で「送信されてきた内容が正規ユーザーからのものかどうか?」を検証する仕組みを持つ必要があるのです。
その際に使われるのが「リファラ(送信元URL)でのチェック」や「トークンでのチェック」です。
リファラ(送信元URL)でのチェックの問題点
フォーム内容を送信する時は、リファラ(送信元URL)が付いた形で送信されるのが普通です。
ですので、そのフォーム内容を受信するプログラム側でリファラ(送信元URL)をチェックし、もし他のドメインからの送信だった場合は拒否する設定をすれば、クロスサイト・リクエストフォージェリ(CSRF)攻撃を防げることになります。
が、しかし。
実は、リファラというのは偽装して送信することが簡単にできます。
わざわざリファラを偽装して送信してくるような人がどれほどいるかは不明ですが、リファラチェック機能だけではCSRF攻撃を完全に防ぐことは不可能ということになります。
トークンによるチェックについて
自分のサイト内(フォームのページ)だけで発行される「トークン」と呼ばれる認証チケットのようなものを発行し、フォーム内容が送信される際にはそのトークンもセットで送信されるようにしたとします。
そして、受信するプログラム側でトークンが自分のサイト内(同一ドメインのページ)で発行されたものかどうかをチェックすれば、他のドメインからの送信を防ぐことができます。
これだけを聞くと「さっきのリファラによるチェックとほとんど同じじゃないか」と思われるかもしれません。
確かに、このトークンもリファラの時と同じように偽装して送信することができます。
しかし、トークンがリファラと決定的に異なるのは「一人一人固有のものであり、さらに一定時間ごとに変更される」という点です。
一人一人違う認証チケットなので、他人になりすまして送信することが不可能となります。
上記のリファラチェックはドメインを利用したチェック方法なので一定の周期で変更することは難しいですが、トークンなら可能です。
つまり、リファラチェックをさらに強化したものがトークンチェックだと言えるでしょう。