今回は、XSSのような「大物の脆弱性」と比較すると、一見地味に見えてしまう「CSRF」の意外な危険性について解説します。
CSRFが脆弱性診断の現場で検出される頻度や、見つかった際に行うべき対応、そもそもCSRFの脆弱性をアプリケーションに作り込まないための予防策、また、脆弱性を放置するとGoogle Chromeなどの主要ブラウザでWebサイトを閲覧できなくなることなどを説明します。
CSRFとは
Webアプリケーションの脆弱性のひとつであるCSRFは、「Cross Site Request Forgery（クロスサイトリクエストフォージェリ）」の略称です。読み方は「シーサーフ」です。英語で「Cross」は「X」と表記することがあるため、CSRFを「XSRF」と表記することもあります。
「クロスサイト」は「Webサイトをまたぐ」という意味で、「リクエスト」はユーザがWebアプリケーションなどに処理を要求すること、「フォージェリ」には「偽造品」などの意味があります。CSRFは、攻撃者が罠として用意した偽造サイトを用いて、ユーザが意図していないリクエストを強制的に行わせるサイバー攻撃です。
CSRFとXSSの違い
クロスサイトリクエストフォージェリと似た名前の脆弱性に「クロスサイトスクリプティング（XSS：Cross Site Scripting）」があります。どちらもサイトを横断（Cross Site）してサイバー攻撃が行われる点が共通していますが、それ以外は何ら同じところはない別物で、発見される頻度や攻撃による影響、対策方法は異なります。
脆弱性診断の現場でCSRFはどのぐらい発見されるか
あなたがいまご覧になっているサイト「SQAT.jp」を運営する株式会社ブロードバンドセキュリティでは、日々、さまざまなお客様のシステムに対して脆弱性診断を行っています。
ブロードバンドセキュリティが2020年上半期に総数4,596のシステムに対して行った脆弱性診断の結果、CSRFを含む「セッション管理関連の脆弱性」は17％のシステムで検出され、その中にCSRFは12％含まれていました。つまりCSRFの脆弱性が存在したシステムは17％×12％、全体の約2％になります。ここで2％という数字をどうとらえたらよいのか、このあと、CSRFの攻撃例やリスクを紹介しながら考えていきます。
CSRFによる攻撃と被害例
CSRFの脆弱性を悪用した攻撃事例としては、掲示板等に本人が全く意図していない書き込みをさせた例（「遠隔操作ウイルス事件」や「はまちちゃん事件」が有名）があります。
もしCSRFが脆弱性診断で見つかったら、すぐに対応が必要な場合もあります。特に、個人情報の登録や変更などに関わるログイン後のページで発見された場合は、すぐに修正を行わなければなりません。
意図しない掲示板の書き込み以外にも、CSRFの脆弱性を悪用すれば、たとえば「サイトAにログインして会員登録を行っているつもりが、実際には攻撃者が罠として用意したサイトBにログインしており、そこで個人情報を抜き取られる」ような攻撃が行われる危険性もあります。もしそうなれば、サイト運営者としての責任が厳しく問われることは間違いありません。
対策を怠ると他サイトへの遷移ができなくなる可能性も
また、主要なWebブラウザは、XSSやCSRFなどからの保護のために、脆弱性のあるWebサイトをブラウザに表示させない仕様を整えつつあります。たとえばGoogle Chromeは、Chrome 80以降、サイトを越えてCookie情報をやり取りするためのSameSite属性に対して制限を加え、CSRFを防御可能な設定値のみを許容する方向へと段階的に進んでいます*1 。CSRFを防御可能な設定値については他の主要ブラウザも同様の方向に進んでおり、Webアプリケーション開発においてCSRF対策は（他の対策とともに）取らないわけにはいかないものの一つとなりつつあります。
セキュリティ企業が見るCSRFのリスクとは
なお、わたしたちセキュリティ診断サービス会社にとってCSRFとは、一定頻度で検出されるものの、CSRF単体ではそれほどリスクは大きくない脆弱性です。事実、CSRFだけを使った攻撃事例はあまり多くないのです。
CSRFで注意すべきは、他のサイバー攻撃手法と組み合わされることでリスクや被害が大きくなることです。
たとえば「セッションフィクセーション」と呼ばれるセッションIDを強制・固定化する攻撃と、CSRFの脆弱性を悪用した攻撃を組み合わせることで、「セッションハイジャック」と呼ばれるサイバー攻撃が成立すれば、セッションの乗っ取りが行われ、オンラインバンキングでの不正送金などにつながる可能性があります。
CSRFのリスクは低い？ 高い？
CSRFだけを考えてしまうとリスクはそれほど高くないため、対応は後回しにされがちです。しかし実際のサイバー攻撃はそう単純ではなく、いくつもの方法が複合されて行われます。「見つかったらすぐに対応が必要な脆弱性のひとつ」とわたしたちが考える理由がそこにあります。
CSRFは、単体では攻撃者にとってそれほど使い勝手の良い脆弱性ではありません。しかし、CSRFはいわば、自身では主役は張れないものの、サイバー攻撃の主役を引き立てるために機能する、名脇役のような脆弱性と言えるかもしれません。
CSRFの対策とトークンによる保護
CSRFの脆弱性を悪用した攻撃で最も警戒すべきはログインしたユーザをターゲットとした攻撃になります。この場合、ログインしたユーザからの正しいリクエストであることを証明するために、「トークン」と呼ばれる推測困難な文字列を使って確認を行うことや再度の認証を行うこと*2などで攻撃を防ぐことができます。
事実、PHP、Java、ASP.NET等の開発言語で提供されている、Webアプリケーションフレームワーク（Laravel、Spring等）は、CSRFの脆弱性を悪用した攻撃を防ぐために、ユニークなトークンを発行する仕組みを持つようになっています。しかし、それでもなおCSRFの脆弱性が見つかることがあるのです。これはどうしてでしょう。
なぜCSRF攻撃対策のトークンは発行されないのか
開発フレームワークがトークンを発行する機能を持っているのにWebアプリケーションでCSRFの脆弱性が発見される理由は、単純そのもので「そもそもトークンを発行するための1行がかかれていない」*3から、ということが多いのです。「機能があるから大丈夫だろう」という思い込みが思わぬリスクを招きます。
前半で、ブロードバンドセキュリティが行った脆弱性診断の結果、約2％でCSRFの脆弱性が検出されたとお伝えしましたが、リスクを知り、適切な対策を確実に実装することで、この数字をもっと少なくすることができるでしょう。
まとめ
- CSRFとは、「シーサーフ」と呼ばれる、攻撃者が罠として用意したサイトを用いて、ユーザが意図しないリクエストを強制的に行わせることを可能にする脆弱性です。
- CSRFとXSSは、どちらもサイトを横断してサイバー攻撃を行う点だけは共通していますが、発見頻度やリスク、対策方法は異なります。
- もし、個人情報の登録などに関わるログイン後のページでCSRFの脆弱性が発見された場合、すぐに修正する必要があります。
- Google Chromeほかの主要ブラウザでは近年、CSRFの対策に有効とされる制限を開始しています。対応しない場合にはWebサイトがブラウザに表示されなくなる可能性もあります。
- CSRFは他のさまざまなサイバー攻撃と組み合わされて利用されることが多いので、たとえCSRF単体のリスクが低くても確実に対策を行うことが重要です。
