クロスサイト リクエスト フォージェリ (CSRF) とは何ですか?

公開: 2023-04-12

クロスサイト リクエスト フォージェリ (CSRF または XSRF) の脆弱性は、重大度の評価が高くなったり重大になったりすることはめったにありません。 ただし、それでも多くの害を及ぼす可能性があります。 これらは、クロスサイト スクリプティング (XSS) の脆弱性に次いで、近年 2 番目に一般的な WordPress の脆弱性となっています。 CSRF 脆弱性とは何か、および攻撃者が一般的にどのように脆弱性を悪用するかを知っていれば、Web サイトをより適切に保護する方法を理解できます。

同一生成元ポリシーを回避する

CSRF の脆弱性により、攻撃者は同一生成元ポリシーと呼ばれる標準のブラウザー機能を回避できます。 すべての Web ブラウザーは、この規則に従って、CSRF が有効にする種類の干渉を防ぎます。 通常、Web ページを読み込んでいる場合、ブラウザは許可された例外を除いて、1 つのドメインまたはサブドメインとのみ対話します。 また、問題があることを警告せずに、HTTP または HTTPS (両方ではない) のいずれかのプロトコルでのみコンテンツを受け入れます。 悪意のある個人が同一生成元ポリシーをバイパスすると、別のサイトと予期せずやり取りして、望ましくないアクションを実行するリンクをクリックするように仕向ける可能性もあります。

WordPress サイトが CSRF の脆弱性によって悪用された場合、あなたとあなたの訪問者はフィッシング、クリックジャッキング、さらに悪いことにさらされる可能性があります. 幸いなことに、タイムリーな更新、強力な認証、およびパスワードなしのログイン エクスペリエンスのためのパスキーにより、WordPress サイトが強化され、CSRF 試行を含む多くのエクスプロイトが無効になります。

視覚的には、別のサイトと望ましくない方法でやり取りしているという手がかりはほとんど、またはまったくありません。 クリックジャッキングはこのように機能します。 WordPress サイトが CSRF の脆弱性によって悪用された場合、あなたとあなたの訪問者はフィッシング、クリックジャッキング、さらに悪いことにさらされる可能性があります.

このガイドでは、クロスサイト リクエスト フォージェリの詳細を掘り下げます。 CSRF 脆弱性の特定の例を見て、それらがどのように機能するかを理解します。 次に、CSRF の脆弱性がサイトに現れるのを防ぐためにできることを示します。 また、これらの攻撃やその他の種類の攻撃に対してサイトを強化することで、成功した CSRF エクスプロイトがもたらす損害を無効にする、または制限する方法もいくつか提案します。

見てみましょう。

クロスサイト リクエスト フォージェリ (CSRF) 攻撃が WordPress サイトに与える影響

CSRF 攻撃が成功すると、被害者は意図せずに、ログイン資格情報の更新などの有害なアクションを許可します。 だまされて、攻撃者にユーザー アカウントを乗っ取られる可能性があります。 さらに悪いことに、CSRF エクスプロイトの被害者は、攻撃者が彼らに代わって金融送金を開始できるようにする可能性があります。

WordPress サイトのプラグインに CSRF 脆弱性が含まれている場合、攻撃者が一部のユーザー アカウントを乗っ取る可能性があります。 これは最悪のシナリオの 1 つです。 盗まれたアカウントが WordPress で管理者の役割を持っていたり、ユーザーが他のサイトでパスワードを再利用したりした場合、損害は広範囲に及ぶ可能性があります。

クロスサイト リクエスト フォージェリ

CSRF 攻撃はどのように機能しますか?

ハッカーが CSRF 攻撃を行うには、3 つの異なる条件が存在する必要があります。 それらを一般的なレベルで理解すれば、いくつかの Web セキュリティの基礎を十分に理解することができます。

1. Cookie ベースのセッション処理

他のステートレス アプリケーションと同様に、WordPress はセッション Cookie に依存してユーザーを識別します。 セキュリティが低いまたは侵害された状態では、攻撃者は偽のセッション Cookie を作成したり、ログインしているユーザーを操作して不要なアクションを実行したりできる可能性があります。 WordPress は、ログインしているユーザーからの、またはそのように見える偽造および操作されたリクエストを受け入れます。

CSRF エクスプロイトは、多くの場合、Cookie ベースのセッション処理をターゲットにしていますが、それだけがターゲットではありません。 CSRF 攻撃は、ユーザー資格情報をリクエストに自動的に追加するアプリケーションに対して効果的です。 このため、証明書ベースの認証と HTTP 基本認証も CSRF の脆弱性の影響を受けやすくなっています。

2. 関連するアクションをターゲットにすることができます

標的となるアプリケーション内には、だまされて被害者が実行できる何らかのアクションが必要です。 これは、ユーザー権限の変更などの特権アクションである可能性があります。 ユーザーのパスワードの更新など、ユーザー固有のデータに関連している可能性があります。 これらは、WordPress を含むすべての Web アプリケーションで共通のアクションです。 ユーザー アカウントを盗んだり、盗難、詐欺、その他の悪意のある活動に関与する方法を深く掘り下げたりするための道を開く可能性があるため、ハッカーの標的として価値があります。

3. 予測不可能なリクエストパラメータはありません

対象となるアクションを実行するリクエストは、既知または予測可能である必要があります。 標的となるリクエストに、攻撃者が判断または推測できない値のパラメータを含める必要がない場合、操作に対して脆弱になります。

たとえば、有効なパスワード変更要求に既存のパスワードを含める必要がある場合、攻撃者がパスワードを知らない限り、その要求は安全です。 CSRF トークンと SameSite Cookie は、開発者がそれらを使用してコードを保護する場合、攻撃者にとってさらなる障害となります。 しかし、開発者がこれらのセキュリティ メソッドを正しく実装していないか、まったく実装していない場合があります。 (これが、パスワードを使用しない強力なユーザー認証が重要な理由です。)

CSRF 脆弱性を悪用してユーザー アカウントの電子メールを変更する — 例

より詳細な例を次に示します。 実際には機能しませんが、効果的な CSRF エクスプロイトの主な概念を示しています。

メールの変更リクエストを検討してください。 ユーザーがこのアクションを実行すると、次のような HTTP 要求を受信する Web サーバーに送信します。

 POST /test HTTP/1.1 Host: yourwebsite.com Content-Type: application/x-www-form-urlencoded Content-Length: 60 Cookie: session=yvthgjrudhgeQkAPzeQ5gHgTvlyxHfsAfE;[email protected]

機能する理由

これは、次の場合に CSRF に必要な条件を満たしています。

  • 標的のサイト/アプリケーションは、セッション Cookie を使用して、どのユーザーがリクエストを発行したかを識別します。ユーザー セッションを追跡するための他のトークンやメカニズムはありません。 これが、開発者が CSRF トークンや SameSite Cookie を使用する必要がある理由です。
  • ユーザーの電子メール アドレスを変更することは、攻撃者の利益に関連するアクションです。 それは確かです！ ユーザーの電子メール アドレスを自分が制御できるものに変更できる場合は、そのユーザーのアカウントを完全に制御できます。
  • 攻撃者は、ユーザーの電子メール アドレスを変更するために必要な要求パラメーターを知っており、有効な値を生成できます。 これらのパラメーターは秘密ではなく、多くの人がオンライン アカウントに使用している電子メール アドレスを特定することは難しくありません。 セッション Cookie はよりトリッキーです。

攻撃者がセッション Cookie を盗む方法

攻撃者の主なハードルは、特定のユーザーのアカウントにアクセスするパラメーターの実際の値を決定することです。 彼らは、ターゲット サイトのユーザーを対象とした Web ページを作成することによって、それを行う可能性があります。 この欺瞞的なサイトには、無料ギフトのリクエストなど、正当な目的を持っているように見えるリンクやボタンが含まれている場合があります。 実際には、これらのリンクやボタンをクリックすると、無料で甘いものを手に入れるのは攻撃者だけです。

これらの不正なリンクをクリックすると、対象となる CSRF の脆弱なサイトに対してアドレス変更要求が行われます。 そのサイトにログインしている場合、リクエストは有効です。 あなたのアカウントが盗まれました — キーを渡されました。

ログインしたままの WordPress サイトのユーザーは、別のサイトにいる場合でも保持されるアクティブなセッション Cookie をブラウザーに持っています。 ブラウザは、偽造されたリクエスト内にそのセッション Cookie を自動的に含めます。 WordPress は、これを完全に有効なアドレス変更要求と見なす場合があります — それが別のサイトからのものであり、ユーザーがそれを作成していることに気付かない場合でも.

SameSite Cookie 属性のような他のセキュリティ対策が実施されていないと仮定すると、脆弱なターゲット サイトは、偽造されたリクエストを有効なリクエストと同じように処理します。 標的の Web サイトがアドレス変更の確認手順を強制しない場合、または攻撃者がそれを回避する方法を持っている場合、攻撃者はユーザーのアドレスを攻撃者が選択した任意のアドレスに変更することに成功します。

CSRF 攻撃が脆弱な Web サイトに配信される仕組み

CSRF 攻撃と Reflected Cross-Site Scripting (Reflected XSS) 攻撃の配信メカニズムは似ています。

ほとんどの場合、攻撃者は悪意のあるコードを自分が管理する偽のサイトに配置します。 これは、彼らがすでに侵害した正当なサイトである可能性があります。そのため、Google は偽のサイト リストを保持しています。 あなたがこのリストに載っている場合、すべてのブラウザはユーザーに警告します! これが、iThemes Security が毎日チェックして、サイトがハッカーのツールになっていないことを確認する理由です。

潜在的な被害者を偽の Web サイトにアクセスさせることは、単純に基本的なソーシャル メディアと電子メール マーケティングの問題です。 悪意のあるコードが、アクティブなエリアの人気のあるサイトに配置されるだけの場合もあります。

攻撃者は、被害者をおびき寄せるために Web サイトさえ必要としない場合があります。 一部の単純な CSRF エクスプロイトは、GET メソッドを使用します。 これは、リンクをクリックするか、アドレス バーに URL を入力したときにブラウザーが行うことです。 リンク内の URL または提供された URL を使用して GET 要求を行います。 CSRF 攻撃は、脆弱な Web サイトへの単一の GET 要求で完全に実行される場合があります。 このような状況では、攻撃者は偽の Web サイトを使用する必要がない場合があります。 彼らは被害者に悪意のある URL を直接送り込むだけです。

クロスサイト リクエスト フォージェリ (CSRF) 攻撃からサイトを保護する

CSRF 脆弱性は、プラグインや場合によってはテーマで頻繁に表面化します。 ハッカーがそれらを標的にした場合、身を守ることは難しくありません。 信頼できる高品質のプラグインとテーマを使用し、使用していないプラグインとテーマを削除し、すべてのソフトウェアを最新の状態に保ちます。 また、十分に検討されたユーザー セキュリティ ポリシーを実装し、パスワードレス化を検討する必要があります。 サイトで CSRF の脆弱性 (またはその他の脆弱性) が悪用されてユーザー アカウントにアクセスされた場合、パスキーを使用している場合、攻撃者にとってはあまり役に立ちません。 存在しないものを盗むことは誰にもできません。

更新を管理し、脆弱なプラグインやテーマについて警告するだけでなく、iThemes Security Pro を使用すると、ユーザーおよび役割ベースのセキュリティ ルールを簡単に設定および管理できます。 最小権限の原則に基づいて権限を委任します。 CAPTCHA を使用して、ログイン、パスワードの回復、お問い合わせフォームを保護します。 ユーザーに必要以上の機能を与えないでください。 権限の高いユーザーには、より強力な認証方法を使用するように要求します。 そして、パスワードなしで WordPress にログインするための最も便利で簡単な方法、つまりパスキーを確実に採用してください!

WordPress を安全に保護するための最高の WordPress セキュリティ プラグイン

WordPress は現在、すべての Web サイトの 40% 以上で使用されているため、悪意のあるハッカーにとって格好の標的となっています。 iThemes Security Pro プラグインは、WordPress のセキュリティから当て推量を取り除き、WordPress Web サイトを簡単に保護および保護できるようにします。 これは、WordPress サイトを常に監視して保護するフルタイムのセキュリティ専門家がスタッフにいるようなものです。

iThemes Security Pro を入手