CSRF 攻撃の理解と CSRF 脆弱性のロックダウン
公開: 2022-11-21Web の脆弱性は蔓延しており、常に増加しています。 ユーザーのセキュリティとプライバシーを維持することは、これまで以上に重要になっています。 Web の脆弱性に対処しないと、評判が損なわれ、規制当局から多額の罰金が科せられる可能性があり、ユーザーの信頼も失うことになります。
Web サイトと Web アプリケーションは、マルウェア、スパム、およびその他の攻撃に対して脆弱です。この記事では、そのような攻撃ベクトルの 1 つ、クロスサイト リクエスト フォージェリ (CSRF) 攻撃に焦点を当てます。 CSRF 攻撃は、ユーザーの知らないうちに発生する可能性があるため、特に厄介です。 また、悪意のあるリクエストは本物のリクエストと非常によく似ているため、開発者や Web サイトの所有者がこれらを検出することは困難です。
この記事では、CSRF 攻撃、そのしくみ、および CSRF 攻撃に備えるための手順について説明します。
CSRF攻撃とは?
クロスサイト リクエスト フォージェリ攻撃 (CSRF 攻撃とも呼ばれます) は、認証されたユーザーを騙して、悪意のあるリクエストを無意識のうちに送信することで、意図しないアクションを実行させます。
通常、CSRF 攻撃には、攻撃者が応答を受信しないため、状態変更要求が含まれます。 このようなリクエストの例としては、レコードの削除、パスワードの変更、製品の購入、メッセージの送信などがあります。 これらはすべて、ユーザーの知らないうちに発生する可能性があります。
悪意のある攻撃者は通常、ソーシャル エンジニアリングを使用して、無防備なユーザーにチャットや電子メールでリンクを送信します。
ユーザーがリンクをクリックすると、攻撃者が設定したコマンドが実行されます。
たとえば、リンクをクリックすると、ユーザーのアカウントから資金を送金できます。 または、ユーザーの電子メール アドレスが変更され、アカウントへのアクセスを回復できなくなる可能性があります。
CSRF 攻撃はどのように機能しますか?
ログイン中にユーザーに状態変更要求を開始させることは、CSRF 攻撃の最初の最も重要なステップです。 CSRF 攻撃では、攻撃者は、認証されたユーザーに悪意のある Web リクエストを無意識のうちに Web サイトまたは Web アプリケーションに送信させることを目的としています。 これらのリクエストは、Cookie、URL パラメータ、およびユーザーには正常に見えるその他のデータ タイプで構成されます。
CSRF 攻撃が成功するには、次の条件が発生する必要があります。
- 認証されたユーザーは、セッション管理に Cookie を使用する Web アプリケーションにログインする必要があります。
- 攻撃者は、状態を変更する偽造リクエストを作成する必要があります。
- ターゲット サーバーによって処理される正規の要求には、予測できないパラメーターが含まれていてはなりません。 たとえば、リクエストは、状態変更リクエストを開始する前に、検証目的のパラメータとしてパスワードを想定すべきではありません。
CSRF 攻撃を完了する最も一般的な方法は、弱い SameSite Cookie ポリシーを持つアプリケーションで Cookie を使用することです。 Web ブラウザーには Cookie が自動的に、多くの場合匿名で組み込まれ、ユーザーがそのドメインに送信するすべての Web 要求でドメインが使用する Cookie を保存します。
SameSite Cookie ポリシーは、クロスサイト ブラウジング コンテキストでブラウザーが Cookie を処理する方法を定義します。 厳密に設定すると、Cookie はクロスサイト ブラウジング コンテキストで共有されず、CSRF 攻撃を防ぎます。 Cookie が none に設定されている場合、ブラウザはすべてのクロスサイト コンテキストで Cookie を添付します。 これにより、アプリケーションは CSRF 攻撃に対して脆弱になります。
ユーザーが無意識のうちに Web ブラウザーを介して悪意のある要求を送信すると、保存された Cookie により、サーバーはその要求を正当なものとして認識します。 次に、サーバーは、ユーザーのアカウントを変更するか、セッション状態を変更するか、要求されたデータを返すことによって、要求に応答します。
CSRF 攻撃手段の 2 つの例を詳しく見てみましょう。1 つは GET 要求によるもので、もう 1 つは POST 要求によるものです。
GET リクエストの CSRF
まず、金融銀行の Web アプリケーションで使用される GET 要求を考えてみましょう。この攻撃では、GET 要求とハイパーリンク配信が悪用されます。
送金のための GET リクエストが次のようになっているとします。
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1 上記の本物のリクエストでは、ユーザーは、購入した製品の支払いとして547895のアカウントに $1,000 を送金するようにリクエストします。
この要求は明示的、単純、かつ実用的ですが、アカウント所有者を CSRF 攻撃にさらすことになります。 これは、攻撃者が知らない可能性のある詳細をリクエストが必要としないためです。 したがって、攻撃を開始するには、攻撃者はこのリクエストのパラメーター (金額と口座番号) を変更して、実行可能な偽造リクエストを作成するだけで済みます。
悪意のあるリクエストは、銀行のユーザーが Cookie で管理されたセッションを継続している限り、どのユーザーに対しても有効です。
ハッカーのアカウント (ここでは、番号654585 ) に $500 を送金する偽造リクエストは次のようになります。 以下の例は、説明のために CSRF 攻撃に関連する手順を非常に単純化したバージョンであることに注意してください。
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1それが完了すると、攻撃者はオンライン バンキング アプリケーションにログインしている間にユーザーをだましてこの要求を送信させる方法を見つけ出さなければなりません。 これを行う方法の 1 つは、ユーザーの注意を引く無害なハイパーリンクを作成することです。 リンクは次のようになります。
<a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>. 攻撃者がターゲットの正しい電子メール アドレスを見つけた場合、攻撃者はこれを電子メールで多くの銀行顧客に送信できます。 ログイン中にリンクをクリックすると、ログインしたアカウントから攻撃者に 500 ドルを送信するリクエストがトリガーされます。
POST リクエストの CSRF
同じ金融機関が POST 要求のみを受け入れた場合、CSRF がどのように発生するかを見てみましょう。 この場合、GET 要求の例で使用されているハイパーリンク配信は機能しません。 したがって、CSRF 攻撃が成功するには、攻撃者が HTML フォームを作成する必要があります。 購入した製品に対して 1,000 ドルを送金するという本当の要求は、次のようになります。
POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895この POST リクエストでは、ユーザーの身元、送信する金額、送信するアカウントを特定するために Cookie が必要です。 攻撃者は、この要求を変更して CSRF 攻撃を実行できます。
攻撃者は、サーバーに転送を処理させるために、偽造された要求に本物の Cookie を追加するだけで済みます。 次のようなトリガー Web ページにユーザーを誘導する無害に見えるハイパーリンクを作成することで、これを行うことができます。
<html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>上記のフォームで、金額とアカウントのパラメーターを既に設定しています。 認証されたユーザーがページにアクセスすると、ブラウザはリクエストをサーバーに転送する前にセッション Cookie を追加します。 次に、サーバーは 500 ドルをハッカーのアカウントに転送します。
CSRF 攻撃を軽減する 3 つの方法
Web サイトまたは Web アプリケーションに対する潜在的な CSRF 攻撃を防止し、大幅に軽減する方法はいくつかあります。
- CSRF トークンの使用
- リファラーヘッダーの使用
- Kinsta などのセキュリティ重視のホスティング ソリューションの選択
CSRF トークンを使用して CSRF 攻撃を防ぐ方法
CSRF で保護された Web サイトは、各セッションに一意のトークンを割り当て、それをサーバー側およびクライアント ブラウザーと共有します。 ブラウザが機密性の高いリクエストを送信するたびに、サーバーは割り当てられた CSRF トークンが含まれていることを期待します。 間違ったトークンがある場合、サーバーはそれをドロップします。 CSRF トークンは、セキュリティ上の理由から、クライアントのブラウザーのセッション Cookie には保存されません。
CSRF トークンの潜在的な脆弱性
CSRF トークンは優れたセキュリティ手段ですが、この方法は攻撃を防ぐことはできません。 CSRF トークンに伴う脆弱性には次のようなものがあります。
- 検証バイパス— 一部のアプリケーションは、トークンが見つからない場合、検証手順をスキップします。 攻撃者がトークンを含むコードにアクセスできた場合、そのトークンを削除して CSRF 攻撃を成功させることができます。 したがって、サーバーへの有効なリクエストが次のようになっているとします。
POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433攻撃者は、トークンを削除して次のように送信するだけで、攻撃を実行できます。
POST /change_password POST body: password=pass123- プールされたトークン— 一部のアプリケーションは、特定のトークンをセッションに指定する代わりに、ユーザー セッションを検証するためにトークンのプールを維持します。 攻撃者は、プールに既にあるトークンの 1 つを取得するだけで、サイトのユーザーになりすますことができます。
攻撃者は、自分のアカウントを使用してアプリケーションにログインし、次のようなトークンを取得できます。
[application_url].com?csrf_token=93j9d8eckke20d433また、トークンはプールされているため、攻撃者は同じトークンをコピーして別のユーザー アカウントにログインすることができます。
- CSRF は Cookie にトークンをコピーできます— 一部のアプリケーションは、トークンに関連するパラメーターをユーザーの Cookie にコピーします。 攻撃者がそのような Cookie にアクセスできるようになると、簡単に別の Cookie を作成してブラウザーに配置し、CSRF 攻撃を実行できます。
そのため、攻撃者は自分のアカウントを使用してアプリケーションにログインし、Cookie ファイルを開いて以下を確認できます。
Csrf_token:93j9d8eckke20d433次に、この情報を使用して別の Cookie を作成し、攻撃を完了することができます。
- 無効なトークン— 一部のアプリケーションは、CSRF トークンをユーザー セッションに一致させません。 このような場合、攻撃者は実際にセッションにログインし、上記と同様の CSRF トークンを取得し、それを使用して被害者のセッションに対する CSRF 攻撃を調整できます。
Referrer ヘッダーで CSRF 攻撃を防ぐ方法
CSRF 攻撃を防ぐもう 1 つの戦略は、リファラー ヘッダーを使用することです。 HTTP では、リファラー ヘッダーはリクエストの発信元を示します。 これらは通常、分析、最適化、およびロギングを実行するために使用されます。
CSRF 攻撃を防ぐために、サーバー側でリファラー ヘッダーのチェックを有効にすることもできます。 サーバー側は、リクエストの送信元をチェックし、リクエストの送信元を決定します。 それらが一致する場合、リクエストは許可されます。 不一致がある場合、サーバーはリクエストをドロップします。
リファラー ヘッダーを使用すると、個々のユーザーを識別する必要がないため、トークンを使用するよりもはるかに簡単です。
リファラー ヘッダーの潜在的な脆弱性
CSRF トークンと同様に、リファラー ヘッダーにはいくつかの重大な脆弱性があります。
まず、リファラー ヘッダーは必須ではなく、一部のサイトではリファラー ヘッダーなしでリクエストが送信されます。 CSRF にヘッダーなしのリクエストを処理するポリシーがない場合、攻撃者はヘッダーなしのリクエストを使用して状態変更攻撃を実行できます。
さらに、この方法は、最近のリファラー ポリシーの導入により効果が低下しています。 この仕様により、他のドメインへの URL 漏洩が防止され、ユーザーはリファラー ヘッダー内の情報をより詳細に制御できます。 次に示すように、リファラー ヘッダー情報の一部を公開するか、HTML ページにメタデータ タグを追加して無効にするかを選択できます。
<meta name="referrer" content="no-referrer">上記のコードは、このページからのすべてのリクエストのリファラー ヘッダーを削除します。 そうすることで、リファラー ヘッダーに依存するアプリケーションがそのようなページからの CSRF 攻撃を防ぐことが難しくなります。
Kinsta が CSRF 攻撃から保護する方法
リファラー ヘッダーと CSRF トークンの使用に加えて、3 番目の簡単なオプションがあります。Kinsta のような安全なホスティング サービスを Web サイトや Web アプリケーションに選択すると、攻撃者とユーザーの間にはるかに強力で安全なバリアが提供されます。
自動バックアップ、二要素認証、SFTP over SSH プロトコルなどの重要なセキュリティ機能に加えて、Kinsta の Cloudflare 統合は、IP ベースおよびファイアウォール保護によるエンタープライズ レベルの保護を提供します。
具体的には、Kinsta には現在、悪意のある攻撃を防ぎ、CSRF 脆弱性を探す特定のものを含む、プラグインとテーマの深刻な認証されていない脆弱性に対処するのに役立つ約 60 のカスタム ファイアウォール ルールがあります。
概要
クロスサイト リクエスト フォージェリ (CSRF) は、認証されたユーザーを騙して、意図せずに状態変更リクエストを開始させる攻撃です。 それらは、有効な状態変更要求と偽造された状態変更要求を区別できないアプリケーションを対象としています。
CSRF は、セッション Cookie に依存してログに記録されたユーザーを識別し、SameSite Cookie ポリシーが弱いアプリケーションでのみ成功します。 また、パスワードなどの未知のパラメーターを含まない要求を受け入れるサーバーも必要です。 ハッカーは、GET または POST を使用して悪意のある攻撃を送信できます。
CSRF トークンを使用したり、リファラー ヘッダーの検証を強制したりすることで一部の CSRF 攻撃を防ぐことができますが、どちらの手段にも潜在的な脆弱性があり、注意しないと予防手段が役に立たなくなる可能性があります。
Kinsta のような安全なホスティング プラットフォームに移行すると、Web サイトや Web アプリを CSRF 攻撃から保護できます。 さらに、Kinsta と Cloudflare の統合により、特定の CSRF 攻撃が防止されます。