鳩丸ぐろっさり (用語集)

bakera.jp > 鳩丸ぐろっさり (用語集) > CSRF

用語「CSRF」について

CSRF (しーえすあーるえふ)

話題 : セキュリティ

CSRF は Cross Site Request Forgeries の略です。"forgery" は偽造の意味で、サイトをまたがって捏造された攻撃リクエストを送信する、という程度の意味になります。

※ちなみに、CSRF は「シーサーフ」と発音するのだという説もありますが、少なくとも日本では「しーえすあーるえふ」と呼ぶ方が主流のようです。

たとえば、blog などは Web 上の管理画面で記事の削除ができるようになっています。削除を実行するには、削除を行うような HTTP のリクエストをサーバに送れば良いのですが、この画面は Cookie なり、Basic 認証なりでアクセス制御がされています。そのため、正規のユーザ以外が削除のリクエストを送っても何も起きません。ログイン済みの正規のユーザが「削除」のリクエストを送ったときだけ、削除が実行されます。

CSRF は、ログイン済みの正規のユーザに「削除」のリクエストを行わせる攻撃です。たとえば、攻撃者はサイト上に「削除」コマンドのリクエストとなるようなリンクを用意しておきます。一般のユーザがこのリンクをたどっても何も起きません。しかし、管理画面にログインしている状態のユーザがリンクをたどると、削除が実行されてしまうことになります。

対策

対策は大きく分けて二つあります。Referer をチェックするというもの、攻撃者が知り得ない値をフォームに含めるというものです。

Referer をチェックする

ひとつは、Refererをチェックする方法です。Referer を見て、それが管理画面のものでない場合には動作しないようにします。罠のサイトで URL を踏んでしまった場合にはそのサイトの Referer が送られてきますし、HTML メールで踏んでしまった場合は Referer が送られてきません。いずれにしても管理画面の Referer ではないため、そこをチェックします。

この方法の問題は、Referer を送出しないブラウザで管理画面が利用できなくなってしまうということです。また、怪しげなフィルタリングソフトは Referer を書き換えることがあり、そのような場合も利用できなくなります。

※Referer を送出しないケースを受け入れてしまうと、ローカルファイルからのアクセス、HTML メールからのアクセス、HTTPS から HTTP へのアクセスなどを無条件に受け入れてしまいますので対策になりません。

攻撃者が知り得ない値をフォームに含める

もう一つの方法は、攻撃者が知り得ない値をフォームの内容に含めておくというものです。その値が含まれていないリクエストでは動作しないようにします。たとえば、ユーザが管理画面にログインするたびにランダムな値を生成して、それを全てのフォームに含めておくようなことが考えられます。攻撃者は、リクエストにこの「ランダムな値」が含まれるようにしなくてはなりませんが、それは困難です。

セッション Cookie でセッション管理をしているような場合は、その Cookie の値自体が予測困難な値ですので、同じものをフォーム内の input type="hidden" にセットしておいてチェックするだけでも対策になります。

もちろんスクリプト等で Cookie が盗まれたり、セッション固定攻撃が行われたりすれば破られてしまいますが、その場合は CSRF どころかセッションハイジャックが成立してしまいますので論外です。XSSセッション固定攻撃の排除は CSRF 対策以前の大前提です。

また、パスワードを入力させることも対策になります。パスワード変更フォームで新パスワードだけでなく旧パスワードも入力させるケースがありますが、これには意味があるということです。

なお、CSRF は XOOPS や Movable Type などで問題になったため、「勝手にコンテンツを削除されてしまう」問題としてとらえられている節があります。それは間違いではないのですが、実はもっと危険なことができるケースもあります。

最近の日記

関わった本など