技術者ブログ

はじめに

広く報道されているように（参考記事）、CSRFによるウソの殺人予告によって、無実の大学生が逮捕される事件が発生してしまいました。

筆者は2006年に「開発者のための正しいCSRF対策」という記事をインターネット上で公開し、またメーリングリスト上での議論などでCSRF脆弱性への対策について啓蒙してきたつもりですが、実際にはインターネット上の多くのウェブアプリケーションは未だCSRF対策がなされておらず、今回問題が起こった横浜市のホームページも氷山の一角に過ぎないだろうと考えています。

CSRF対策がなかなか広まらなかった理由のひとつは、大きな、あるいは目立った被害がこれまであまり見られなかった事かと思います。mixiでのはまちちゃんによる「こんにちはこんにちは」事件などもありましたが、あくまでいたずらレベルに過ぎず、小規模なウェブサイトにおいてそれほど積極的に対策しようという雰囲気には繋がりませんでした。

しかし今回、あまりにもインパクトの強い事件が発生し、特にそれが自治体のホームページであったという点から、今後、「全てのウェブアプリケーションにCSRF対策を！」という流れが起こるのではないかと考えています。

ScutumによるCSRF対策のメリット

この記事では、私たちが提供しているSaaS型のWAFサービス、Scutum(スキュータム)の導入によって、比較的簡単にウェブアプリケーション全体にCSRF対策を導入できるという点について紹介させて頂こうと思います。

もしあなたの手元にCSRF対策が行われていないウェブアプリケーションがある場合、まず考えられるのは開発元の会社に対してCSRF対策を依頼するということでしょう。

しかし、たとえばWebサイトの保守契約が締結されていないとか、該当するアプリケーションがオープンソースであり、しかもカスタマイズをしてしまっていて、修正を依頼すること自体が難しい場合などはどうすればいいでしょうか。CSRF対策では、多くの場合、「コードを書く」ことが必要となります。つまり、プログラマーが手を動かす必要があります。もしプログラマーがいない場合には、Scutumの導入によるCSRF対策がオススメです。

Scutumではオーソドックスなウェブアプリケーションであれば導入するだけで全体にCSRF対策を施すことが可能なので、プログラマーがいない環境に対してでもCSRF対策を実施できます。最短で1週間で導入が可能です。ぜひお問い合わせください。

CSRF対策機能は有料オプション

Scutumでは、現在、CSRF対策は有料オプション機能となっており、お客様が希望された場合にのみ導入する、という形になっています。その理由は、導入に際し、お客様のウェブアプリケーションに合わせたカスタマイズが必要となるからです。

この価格は、お客様のウェブアプリケーションの規模や内容によって異なります。掲示板のようなシンプルなアプリケーションの場合には、非常に安価になるケースが殆どです。

ScutumはどのようにCSRF対策をおこなうか

お客様がCSRF対策を希望された場合には、ScutumはHTTPレスポンスを書き換え、フォームタグの終端である</form>の前にCSRF対策トークンを埋め込みます。

また、同時にHTTPレスポンスヘッダにおいてSet-Cookieフィールドを使用し、CSRF対策用のセッションIDを発行します。トークンの値とセッションIDはScutum上で結びつけられており、別のユーザ（別のセッションID）のトークンと区別されます。また、リファラについてもチェックを行い、別のホスト（いわゆる、CSRFの罠のページ）から飛ばされてきた場合などは検知するようになっています。

誤検知によって正常な機能を妨げることを極力避けるため、CSRF攻撃かどうかを判断するポリシーはデフォルトではやや緩めになっており、以下のどちらかの条件が満たされれば、アクセスは許可されます。

• セッションIDとトークンの組み合わせが正しい
• リファラが同一ホストのものである

全てのHTTPリクエストに対してCSRFかどうかのチェックを行ってしまうと、例えばトップページへのアクセスのような、シンプルなGETリクエストについても誤ってCSRFであると判断してしまうことになります。そのため、例えば「POSTリクエストのみ、CSRFかどうかチェックする」というようなポリシーを、ウェブアプリケーションに合わせて決めることになります。掲示板アプリケーションのような比較的オーソドックスなウェブアプリケーションの場合には、「POSTリクエストのみチェック」というポリシーが適合するケースが多くなります。

Scutumによるトークンの挿入によってウェブアプリケーション本来の機能に問題が出ないかどうかをお客様に確認して頂き、その後、本番導入という流れになります。

Cookieによるセッション管理を行うため、Cookieが無効のユーザからのアクセスについては、仮にそれが正しいユーザである場合でも、ブロックしてしまうケースが発生します（ただし前述のようにリファラが正しければ許可するため、多くの場合は問題になりません）。

Scutumが苦手なケース

フォームの実行の際にJavaScriptを多用するような、いわゆるAjax的なアプリケーションの場合、Scutumが行うトークン方式のチェックとの相性が悪い場合があります。このような場合には通常のケースよりも多くのカスタマイズ作業が必要になったり、あるいは残念ながら導入が難しいという結論になる場合もあります。

おわりに

開発者、プログラマーがいない環境でのCSRF対策を検討されている場合には、SaaS型ですぐに導入可能なScutumは最適なソリューションであると考えています。既に導入実績も豊富にありますので、ぜひ導入をご検討ください。

ご連絡はこちらからどうぞ。