- 前書き
- CSRFの特徴
- CSRFの歴史
- CSRF攻撃の制限
- CSRF攻撃の防止
- STPテクノロジー
- Cookie-to-headerトークン
- クッキーの二重送信
- SameSitecookie属性
- クライアント側のセーフガード
前書き
クーポンhttps://m.fenfaw.cn/CSRFのフルネームは、クロスサイトリクエストフォージェリです。クロスサイトリクエストフォージェリは、ワンクリック攻撃またはセッションハイジャックとも呼ばれます。これは、主にサイト内の許可されたユーザーの信頼を利用した、Webサイトの悪用です。ユーザー攻撃者はだまされて、望まないWebリクエストを送信しました。悪意のあるWebサイトは、さまざまな方法でそのようなコマンドを送信できます。たとえば、特別な画像タグ、非表示のフォーム、JavaScript XMLHttpRequestsはすべて、ユーザーの操作や知識がなくても機能します。
CSRF攻撃が発生すると、クライアントやサーバーのデータが誤って漏洩したり、セッションステータスが変更されたり、ユーザー情報が変更されたりする可能性があります。
CSRFの特徴
CSRFの悪意のある攻撃では、攻撃者の目的は、攻撃者が無意識のうちにアクセス許可のあるWebサイトに悪意のあるWeb要求を送信するようにすることです。リクエストは、リクエストを処理するWebサーバーによって通常表示されるURLパラメータ、Cookie、およびその他のデータを含むように注意深く設計されています。ユーザーのWebブラウザに保存されているCookieを介して認証されたユーザーは、ユーザーを信頼するサイトに無意識のうちにHTTPリクエストを送信し、不要な操作を行う可能性があります。
なぜそのような攻撃があるのですか？Webブラウザーの場合、特定のドメインで使用されるCookieが、そのドメインに送信されるWeb要求に自動的かつ目に見えない形で含まれるためです。CSRF攻撃はこの属性を利用します。これは、ブラウザによって行われたWeb要求には、被害者がWebサイトにログオンしたときに作成されたCookie（セッションCookieやその他のCookieを含む）が自動的に含まれるためです。ユーザーが誤ってブラウザを介してリクエストを送信するようにだまされた場合、これらの自動的に含まれるCookieにより、偽造がターゲットサーバーの認証を通過できるようになり、悪意のある攻撃が発生します。
このような攻撃URLを生成するために、悪意のある攻撃者は、ターゲットページのアカウントパスワードを変更するなど、実行可能なWebリクエストを作成する必要があります。攻撃者は、攻撃者の制御下にあるページにリンクを埋め込むことができます。たとえば、被害者に送信される電子メールのhtml画像タグに埋め込むことができ、被害者が電子メールを開くと画像が自動的に読み込まれます。被害者がリンクをクリックすると、ブラウザにはWebサイトで使用されているすべてのCookieが自動的に含まれ、Webサーバーにリクエストが送信されます。Webサーバーは悪意のある要求を実行します。
CSRFの歴史
2001年には早くも、攻撃を実行するためにそれを使用し始めた人もいます。ただし、攻撃はユーザー自身のIPアドレスを使用するため、これはユーザーからの通常の要求のように見えるため、攻撃の直接的な証拠はほとんどありません。現在知られているよく知られているCSRF攻撃は次のとおりです。
2006年、Netflixは多くのCSRFの脆弱性を破壊しました。攻撃者は、受信者のアカウントの受信アドレスを変更して、攻撃者自身のために商品を購入する可能性があります。
YouTubeも2008年にCSRFの攻撃を受けました。これにより、攻撃者はすべてのユーザーのほぼすべての操作を実行できます。
McAfee SecureもCSRFの攻撃を受けており、攻撃者が会社のシステムを変更できるようになっています。
2018年には、一部のルーターもCSRFの攻撃を受け、ルーターのDNS設定を変更できるようになりました。
CSRF攻撃の制限
CSRF攻撃を実現するには、特定の条件が必要です。実際、CSRF攻撃はそれほど単純なことではなく、次の条件を満たす必要があります。
- ターゲットWebサービスは、リクエストのリファラーヘッダーをチェックしません。同種のリクエストのみが許可されている場合、CSRFは使用できません。
- 攻撃者は、ターゲットサイトでフォーム送信ファイルを見つけるか、特定のアクション（送金、被害者の電子メールアドレスまたはパスワードの変更など）を実行する攻撃的なURLを見つける必要があります。
- 攻撃者は、すべてのフォームまたはURL入力の正しい値を決定する必要があります。攻撃者が推測できない秘密の認証値またはIDである必要がある場合、攻撃は失敗する可能性があります（攻撃者が非常に幸運であると推測しない限り） ）。
- 被害者がターゲットサイトにログインすると、攻撃者は被害者に悪意のあるコードを含むWebページに入るように誘導する必要があります。
- 攻撃者はリクエストを送信することはできますが、攻撃リクエストに応じてターゲットサイトからユーザーに返送されたコンテンツを確認することはできません。操作が継続している場合、後続のCSRF攻撃は完了しません。
CSRF攻撃の防止
WebブラウザはさまざまなHTTP要求をさまざまな方法で処理するため、CSRF攻撃に対する防御はHTTP要求方法に関連しています。
HTTP GETでは、CSRF攻撃の使用は非常に簡単です。たとえば、攻撃URLがIMGタグに取り込まれ、自動的に読み込まれます。ただし、HTTP仕様によれば、GETメソッドを使用してデータを変更することはできません。GETを使用してデータを更新するアプリケーションは、HTTP POSTに切り替えるか、アンチCSRF保護を使用する必要があります。
CSRFのHTTPPOSTの脆弱性は、ユースケースによって異なります。
最も単純な形式のPOSTでは、データはクエリ文字列（field1 = value1＆field2 = value2）としてエンコードされ、単純なHTML形式を使用してCSRF攻撃を簡単に実装できます。 、つまり対策が必要です。CSRF対策。
データが他の形式（JSON、XML）で送信される場合、標準的な方法はXMLHttpRequestを使用してPOSTリクエストを作成し、同一生成元ポリシー（SOP）とクロスドメインリソース共有（CORS）を使用してCSRF攻撃を防止することです。
他のHTTPメソッド（PUT、DELETEなど）は、同一生成元ポリシー（SOP）とクロスドメインリソース共有（CORS）のみを使用して、CSRF XMLHttpRequestリクエストを防止できます。ただし、Access-Control-Allow-Originを使用する場合：*ヘッダーは明確ですこれらの対策は、無効になっているWebサイトには影響しません。
以下では、CSRFを防ぐためのいくつかの手法について詳しく説明します。
STPテクノロジー
STPのフルネームはSynchronizerトークンパターンです。つまり、すべてのHTMLフォームには、非表示のトークンフィールドが含まれています。ランダム性が保証されている限り、トークンはさまざまな方法で生成できます。攻撃者はこのトークンの値を予測できないため、CSRF攻撃を実行できません。たとえば、次のコード：
<input type="hidden" name="csrfmiddlewaretoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />
STPはHTMLのみに依存しているため最も互換性がありますが、トークンを使用した各リクエストはプログラムの複雑さを増します。トークンは一意で予測できないため、イベントの適切なシーケンスも強制され、ユーザビリティの問題が発生します。 （たとえば、ユーザーが複数のタブを開きます）。すべてのリクエストCSRFトークンの代わりに、すべてのセッションCSRFトークンを使用することで緩和できます。
Cookie-to-headerトークン
Webアプリケーションが主にJavaScriptを使用して対話する場合は、この方法の使用を検討してください。
初めてWebサービスにアクセスするとき、ランダムなトークンがCookieに設定され、クロスドメイン要求でCookieにアクセスすることはできません。
Set-Cookie: csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; Domain=.wikipedia.org; SameSite=Lax; Secure
クライアント側でjavascriptを実行する場合は、Cookieからトークン値を読み取り、各トランザクションリクエストで送信されるカスタムHTTPヘッダーにコピーします。
X-Csrftoken：i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
サーバーは、トークンの存在と整合性を検証します。悪意のあるファイルまたは電子メールから実行されているJavaScriptは、Cookie値を正常に読み取ってカスタムヘッダーにコピーできないためです。csrfトークンCookieが悪意のあるリクエストとともに自動的に送信された場合でも、サーバーには有効なX-Csrf-Tokenヘッダーが必要です。
このテクノロジーは、DjangoやAngularJSなどの多くのフレームワークによって実装されています。これは、トークンがユーザーセッション全体で同じままであり、AJAXアプリケーションで適切に機能するためです。
このテクノロジーを使用するには、同一生成元ポリシーを確保する必要があることに注意してください。
クッキーの二重送信
このメソッドはcookie-to-headerメソッドに似ていますが、JavaScriptを使用しません。サイトはCSRFトークンをCookieとして設定するか、各HTMLフォームの非表示フィールドとして挿入できます。フォームを送信した後、サイトはCookieトークンがフォームトークンと一致するかどうかを確認できます。同一生成元ポリシーは、攻撃者がターゲットドメインでCookieを読み取ったり設定したりすることを防ぐため、慎重に設計された形式で有効なトークンを配置することはできません。
シンクロナイザーモードと比較すると、このテクノロジーの利点は、サーバーにトークンを保存する必要がないことです。
SameSitecookie属性
サーバーがCookieを設定するときに、追加の「SameSite」属性を含めることができます。これは、ブラウザーがCookieをクロスサイトリクエストに添付するかどうかを示します。この属性が「strict」に設定されている場合、Cookieは同じオリジンからのリクエストでのみ送信されるため、CSRFは無効になります。ただし、これにはブラウザが属性を認識して正しく実装する必要があり、Cookieに「Secure」ロゴが必要です。
クライアント側のセーフガード
ブラウザ自体は、クロスサイトリクエストにデフォルトの拒否ポリシーを提供することでCSRFをブロックできます。Mozilla FirefoxのRequestPolicy、FirefoxのuMatrix、Google Chrome / Chromiumなど。ただし、これは多くのWebサイトの通常の操作に深刻な干渉を与える可能性があります。
CsFire拡張機能（Firefoxにも適用可能）などの一部のブラウザー拡張機能は、クロスサイトリクエストから認証情報を削除することにより、通常のブラウジングへの影響を減らすことができます。
この記事はhttp://www.flydean.com/csrf/に含まれています
最も人気のある解釈、最も深遠な乾物、最も簡潔なチュートリアル、そしてあなたが知らない多くのヒントがあなたが発見するのを待っています！
私の公式アカウントに注意を払うことを歓迎します：「それらのものをプログラムする」、テクノロジーを知っている、あなたをもっとよく知っている！