CSRFとXSSの違いは？

XSSとは？

XSSまたはCross Site Scriptingと呼ばれるこの手法は、非常に一般的なサイバー脅威です。成功すると、攻撃者は利用者がアクセスできるウェブページに改ざんされたクライアント側スクリプトを仕込むことが可能になります。これらのスクリプトは主にJavaScriptに基づいており、信頼されるとされるウェブサイトに挿入されます. 

ウェブサイトと利用者間で認証済みのセッションが確立している必要はありません。攻撃の手法により、XSSには3種類が存在します. 

最初のDOM型XSSは、利用者が入力した内容が保護の不十分な環境でJavaScriptにより変更される場合に発生します。例えば、利用者がフォームの値を取得し、JavaScriptでシステムのDOM内に表示する際、攻撃者がその入力を何らかの方法で取得できれば、実行されるスクリプトを操作可能となります.

次に、リフレクト型XSSがあります。これは、ウェブサーバがHTTPリクエストを受け取り、データ保護なしに同じ情報を出力する場合です。要求された情報全体が結果に反映されるため、リフレクトXSSと呼ばれます.

最後に、ストアドXSSがあります。これは、利用者が生成したデータが一般的なストレージに保存された後、ウェブページにアップロードされる際に発生します.

これらすべてのXSS攻撃は、対象アプリに潜在的な危害を及ぼす可能性があります.

‍

XSSの動作例

XSS攻撃が発生する可能性は、次の2つの状況に依存します: 

• 未検証の入力がウェブアプリにデータを提供する場合
• 動的コンテンツの一部であるデータが、事前の検証や認証なしに利用者へ送信される場合

いずれの場合も、改ざんされた内容が対象ブラウザに届き、JavaScriptの一部となります。ただし、含まれるコードがJavaScriptだけであるとは限らず、攻撃時にブラウザが実行しているコードの種類に応じ、Flash、HTML、その他のコードが使われることもあります.

悪意あるコードが実行されると、あらゆるデータを取得できる恐れがあります。クッキー、ログイン情報、セッションデータ、取引情報などが奪われる可能性があるため、XSS攻撃の影響は計り知れません.

XSSの例

XSSの動作をよりよく理解するため、即時XSSの例を見てみましょう。404エラーページをご存知でしょうか？ これは非常に一般的な現象で、攻撃者はこのエラーを利用してXSS攻撃を仕掛けます。例えば、利用者がUnsafe.comの存在しないページにアクセスしようとする場合を考えます.

そのページはおそらくhttp: //unsafe.com/non_existent_fileに存在し、アクセスすると結果はNot Found:/non_existent_fileとなります.

熟練の攻撃者は、エラーページに改ざんされたコードを挿入してXSS攻撃を仕掛けます.

http://unsafe.com/<script>bad_payload_scrpit</script>

被害者がUnsafe.comの存在しないページを見ると、悪意あるJavaScriptコードが含まれ、そのコードが実行されると攻撃者はセッションの詳細情報を全て取得する可能性があります.

CSRFとは？

クライアント情報の漏洩など多数の問題を引き起こすこの手法、CSRFまたはクロスサイトリクエストフォージェリは、ウェブサイトやページでよく見受けられます。ここでは、攻撃者が直接攻撃するのではなく、認証済みの利用者を利用して攻撃を行います。例えば、攻撃者がGoogleのサーバーを狙う場合、直接サーバーを乗っ取ろうとはせず、認証済みの利用者の助力を借りて悪質な内容を送信し、狙ったサーバーを操作します.

これを実現するため、対象のアプリやウェブサイトに既存の脆弱性を利用し、さらにソーシャルエンジニアリングで認証済みの利用者を騙します。CSRF攻撃に必要な条件は以下の通りです:

• 利用可能なのは認証済みの利用者のみであること。
• 攻撃者は利用者認証を突破して初めて狙ったウェブサイトにアクセスできること。

‍

CSRFの動作例

CSRF攻撃の流れはシンプルです。攻撃者は悪質なHTTPリクエストを狙ったウェブサイトへ送信し、認証済みの利用者がそのサイトにアクセスすると、自動的に悪意あるリクエストが処理され、攻撃者は利用者の情報を閲覧・利用できるようになります.

CSRFの例

GETリクエストで送金を受け付ける銀行のウェブサイトを例にとります。コードは次のようになります:

GET http: //banking.com/transfer.do?acct=John&amount=1000 HTTP/1.1

次に、攻撃者が利用者Joshを誘導し、$5,000をMikeという口座に送金させようとしていると仮定します。攻撃者は受取人情報や送金額を容易に改変できます.

GET http: //banking.com/transfer.do?acct=Mike&amount=5000

‍

XSSとCSRFの違い

これら2つの脆弱性の基本が理解できたところで、それぞれの違いについて見ていきます:

• XSSは双方向の攻撃ですが、CSRFは一方向のみです。XSSでは攻撃者がコードを実行し、応答を受け取り目的地へ送信できるのに対し、CSRFでは悪質なHTTPリクエストを送るだけです.
• XSSはJavaScriptベースですが、CSRFはHTTPベースです.
• XSS攻撃の成功はセッションの有効化に依存せず、利用者がサイトにアクセスするたびに改ざんされたペイロードが届けられます。一方、CSRFは有効なセッションが必要です.
• CSRF攻撃の影響は限定的で、最悪の場合、改ざんされたウェブサイトへのアクセスや悪質なリンクのクリックに留まります。対してXSSは影響範囲が広く、攻撃者はあらゆる行動が可能です.
• XSSとCSRFの大きな違いは、問題のあるコードの保管場所にあります。XSS攻撃ではターゲットサイト内にコードが保存されますが、CSRF攻撃では第三者サイトに保存されます.

‍

CSRFトークンでXSS攻撃を防げるか？

XSS予防の手法を検討すると、CSRFトークンが用いられることが多いことが分かります。CSRFトークンは、サーバ側アプリが自動生成する固有の任意の値で、CSRF攻撃を防ぐ目的で利用されます。これらは関連するHTTPリクエストと結びつき、CSRF攻撃の可能性を判断するのに役立ちます.

CSRF攻撃だけでなく、一部のXSS攻撃もCSRFトークンで防ぐことが可能です.

最も一般的な例はリフレクトXSSです。従来のリフレクトXSS攻撃を見てみましょう.

https: //example .com/status?incomingmessage=<script>/*+Infected+stuff+here….+*/<script>

これはリフレクトXSSに脆弱な機能です。ここにCSRFトークンを導入してみます.

https: //example.com/status?csrf-token=CIwPZNlR4XbisJF39I8yWX9n4WNoWwXZ
incoming message=<script>/*+Infected+stuff+here….+*/<script>

このCIwPZNlR4XbisJF39I8yWX9n4WNoWwXZというCSRFトークンを導入することで、サーバはCSRFトークン付きのリクエストのみを受け入れ、XSS攻撃の可能性を低減できます。これにより、攻撃者がクロスサイトリクエストを偽造または操作するのを防ぎ、XSS攻撃を阻止します.

しかし、XSS攻撃を完全に防ぐ解決策とは言い難いです。例えば:

• CSRFトークンが導入されていない機能にリフレクトXSSが存在する場合、その脆弱性を防ぐことはできません. 
• サイト内のどこかにXSSの脆弱性があると、たとえその機能がCSRFトークンで保護されていても、利用者が影響を受ける可能性があります.
• ストアドXSS攻撃にはCSRFトークンは効果がありません. 

比較表 

文章だけでは分かりにくいかもしれません。そこで、XSS攻撃とCSRF攻撃を表形式で簡潔に比較してみます.