Coders Conquer Security: Share & Learnシリーズ - クロスサイトリクエストフォージェリ

Webサイトやアプリケーションの運営者を直接狙う攻撃とは異なり、多くのクロスサイトリクエストフォージェリ（CSRF）攻撃の目的は、ユーザーから直接金銭、商品、または認証情報を盗むことにあります。だからといって、サイト運営者がCSRFのコード脆弱性を無視してよいわけではありません。純粋な金銭的被害が発生した場合、最終的に盗まれた資金の補填は、脆弱なコードを抱えるホスティングサイト側の責任となる可能性があるからです。また、標的となったユーザーが認証情報を盗まれたり、知らないうちにパスワードを変更されたりした場合、犯人はその盗んだIDを使って悪事を働くことが可能になります。特に被害者が特権アクセス権を持っている場合はなおさらです。

CSRF攻撃は非常に複雑で、成功させるには複数の条件が重なる必要があります。言い換えれば、攻撃者が目的を達成するためには、多くの要素が攻撃者に有利に働く必要があります。それにもかかわらず、CSRFが非常に人気のある攻撃手法である理由は、攻撃が成功すればハッカーに直接送金できたり、サイト内を自由に動き回れる状態を作り出せたりするからです。すべてがハッカーの思い通りに進めば、標的となったユーザーは自分が攻撃の被害に遭ったことさえ気づかないかもしれません。

幸いなことに、CSRF攻撃を成功させるには多くの条件が揃う必要があるため、攻撃を未然に防ぐための優れた防御手法がいくつか存在します。

そこで、CSRF攻撃の3つの重要な側面について解説します。

• 仕組み
• なぜこれほど危険なのか
• 攻撃を完全に阻止するための防御策

CSRF攻撃はどのように行われるのか？

CSRF攻撃は、標的のユーザーから直接金銭や商品、認証情報を盗み出せるため、実行には多大な労力を要するにもかかわらず人気があります。また、さまざまなプラットフォームで試みられるため、長年にわたり多様な名称や呼び名で呼ばれてきました。CSRF攻撃は、XSRF、Sea Surf、Session Riding、Cross-Site Reference Forgery、あるいはHostile Linkingなどと呼ばれることがあります。Microsoftのドキュメントの多くでは「ワンクリック攻撃」と表現されています。しかし、これらはすべてCSRF攻撃であり、それらを打ち破るための手法は同一です。

CSRF攻撃は、ユーザーがサイトにログインして業務や作業を行っている最中に発生する可能性があります。重要なのは、ユーザーがWebサイトやアプリケーションにログインし、アクティブに認証されている状態であることです。攻撃は通常、別のWebサイトや電子メールから開始されます。攻撃者はソーシャルエンジニアリングの手法を使い、メール内のリンクをクリックさせて、攻撃スクリプトが仕込まれた不正なWebサイトへ誘導することがよくあります。

不正なWebサイトには、アクティブなブラウザに対してコマンドを実行させるスクリプトが含まれています。通常は、ユーザーのパスワード変更や、攻撃者が管理する口座への送金といった悪意のある操作が行われます。ユーザーが認証されている限り、サイト側はそのコマンドが正規のユーザーによって発行されたものだと判断します。当然のことでしょう。ユーザーはすでに認証を済ませ、サイトへのアクセスに必要なパスワードを入力済みだからです。ユーザーがジオフェンス内にいたり、オフィスで端末に向かっていたりする場合もあるでしょう。パスワードの変更や送金の要求があれば、それが本人によるものだと信じることに何ら不思議はありません。

攻撃の要素を分解してみると、なぜこの攻撃を成功させることが攻撃者にとってこれほど難しいのかがわかります。まず、ユーザーが攻撃対象のサイトに対してアクティブに認証されている必要があります。ユーザーがブラウザセッションを終了したり、ログアウトしたりした後に攻撃スクリプトを含むメールが届いても、攻撃は失敗します。

また、攻撃者は標的のサイトがどのようなスクリプトを受け入れるかを把握するために、多大な偵察を行う必要があります。攻撃者は被害者の画面を見ることができず、Webサイトからのフィードバックはすべて被害者に送られ、攻撃者には届きません。攻撃が成功した証拠（突然口座に金銭が振り込まれるなど）を確認できない限り、攻撃者は成功したかどうかさえすぐにはわかりません。

「攻撃時にユーザーがログインしていること」と「標的サイトが受け入れるスクリプトを把握していること」という、困難ではあるが不可能ではない条件を満たせば、CSRF攻撃を実行するコード自体は非常に単純なものになり得ます。ただし、その内容はサイトによって異なります。

例えば、銀行や金融アプリケーションが送金にGETリクエストを使用しているとします。

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

このコードは、NancySmith12というユーザーに100ドルを送金するリクエストを送信します。

しかし、標的のユーザーが同僚を装ったメールを受け取った場合、クリック操作にCSRF攻撃スクリプトを埋め込むことができます。

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">四半期報告書をさっと確認してもらえますか？<a></a></a>

もし標的のユーザーがこのソーシャルエンジニアリングのリンクに騙され、金融アプリケーションのブラウザセッションを開いたままクリックしてしまった場合、ブラウザはアプリケーションに対してShadyLady15の口座へ10万ドルを送金するよう要求してしまいます。

スクリプトは、ユーザーには見えない透明な画像の中に隠すことも可能です。それでもブラウザはリクエストを実行してしまいます。以下はその例です。

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

結果は同じです。ShadyLady15は、誰にも攻撃を検知されることなく10万ドルを手に入れます。

なぜCSRFはこれほど危険なのでしょうか？

CSRF攻撃が今日これほど普及している理由は、ランサムウェア攻撃が後を絶たない理由と同じです。攻撃者と被害者の資金との間のハードルが非常に低いからです。ランサムウェア攻撃では、システムが暗号化され、データの復号と引き換えに金銭を要求されます。CSRF攻撃の場合、手順はさらに簡略化されます。攻撃が成功すれば、被害者は気づかないうちに自分の資金を攻撃者に送金してしまうのです。

被害者の資金や企業の財務に対する直接的な攻撃だけでなく、CSRF攻撃が成功すれば、正規ユーザーになりすましてネットワークを侵害することも可能です。もし攻撃者がCSRFエクスプロイトを使用して管理者のパスワードを変更できたとしたらどうなるでしょうか。彼らは即座にそのパスワードを使用してデータの窃取を開始したり、ネットワーク防御に穴を開けたり、バックドアを設置したりすることができるでしょう。

多大な労力とある程度の運が必要とはいえ、CSRF攻撃の成功は、ハッカーにとって最終的な目的が何であれ、宝くじに当たるようなものです。ネットワークを攻撃する場合、他のほとんどの攻撃では、SIEMやサイバーセキュリティ担当者の監視をかいくぐるために、数ヶ月にわたる慎重な偵察が必要となります。対照的に、CSRF攻撃ならサイバーキルチェーンの多くのステップをスキップできるため、最終目標に近いところから攻撃を開始できるのです。

CSRF攻撃を阻止するには？

ほとんどの脆弱性とは異なり、CSRF攻撃の根本的な原因はコードそのものにあるわけではありません。攻撃者がブラウザを操作し、ユーザーが意図しない、あるいは気づかないようなリクエストを強制的に実行させるエクスプロイトに問題があります。しかし、これらは対策可能です。

最善の方法の一つは、新しいセッションが生成されるたびに、開発者がユーザーのIDにCSRFトークンを追加することです。これはユニークでランダムな文字列で構成し、ユーザーからは見えないようにする必要があります。次に、新しいリクエストが送信されるたびにサーバー側でチェックされるフォームに、CSRFトークンリクエストを隠しフィールドとして追加します。ユーザーのブラウザを通じてリクエストを送信する攻撃者は、隠しトークンフィールドの存在すら知らず、その内容を知ることもできないため、すべてのリクエストは失敗に終わります。

さらに簡単な方法として、プログラミングの手間をほとんどかけずに、パスワード変更リクエストや送金指示などの機密性の高い操作にCAPTCHA認証を追加する方法があります。リクエスト者がロボット（この場合はCSRFスクリプト）ではないことを確認するボタンをクリックさせるだけの単純なものでも効果的です。攻撃者はこのチャレンジに対する応答をスクリプト化できません。また、送金リクエストなどの操作をしていないのに突然CAPTCHAが表示されれば、ユーザーは異変に気づくことができます。あるいは、組織がセキュリティのために業務効率の低下を許容できるのであれば、スマートフォンなどのサードパーティ製トークンを使用したワンタイムパスワード生成を利用することも可能です。

最後に、完璧ではありませんが、Microsoft EdgeやGoogle Chromeなどの多くのブラウザには、同一オリジンポリシーによる制限が組み込まれており、ローカルユーザー以外からのリクエストをブロックできます。ユーザーに最新バージョンのブラウザを使用させることで、開発チームに負担をかけることなく、CSRFに対するセキュリティ層をもう一つ構築することができます。

CSRFを完全に封じ込める

高い利益が見込めるため、CSRF攻撃が完全になくなることはないでしょう。しかし、なぜこの攻撃がこれほどしつこく続くのか、そしてネットワークから完全に排除する方法を理解していただけたはずです。

詳細については、この脆弱性の進化を記録し続けるライブドキュメントである「OWASP Cross-Site Request Forgery Prevention Cheat Sheet」をご覧ください。セキュリティ知識をさらに深めたい場合は、Secure Code Warriorのブログで、この脅威やその他の多くの脅威を撃退する方法を学ぶことができます。

新しい防御知識を試す準備はできましたか？今すぐSecure Code Warriorプラットフォームの無料デモをお試しください。