私のプロジェクトの1つでCSRFトークンを使用してCSRF保護を実装しようとしています。私はこれに慣れず、リクエストにCSRFトークンを送信することについて読んでいました.GETよりもCSRFトークンをHTTP POSTとして送信することが推奨されています。私の質問は：URL内のCSRFトークンの開示とPOST要求のトークンを含む
HTTP URLがGETリクエストでCSRFトークンを公開し、潜在的な攻撃者がこのCSRFトークンを使用してCSRFリクエストを作成し、Javascriptを使用して攻撃する可能性がある場合、なぜCSRFトークンフォームの隠しフィールドとして格納されていますか？私のサイトにXSSの脆弱性がある場合、攻撃者は隠しフィールドからトークンを取得し、そのトークンと共に要求を送信できます。
ありがとうございます！
この問題の答えは、Same-Orign Policyからです。簡単に言えば：悪意のあるWebサイト上のJavaScriptは、別のサイトのフォームの内容を読み取ることができません。 StackOverflow.comがgmail.comであなたの電子メールを読むことができるようになり、ありがたいことにこれは不可能です。
GET経由で送信されるCSRFトークンは、HTTPリファラーがサードパーティのドメインにデータをリークする可能性があるため、有害なものとみなされます。これを有効にするには、攻撃者は画像またはクリック可能なリンクを埋め込む必要があります。
CSRF Prevention Cheat Sheetもご覧ください。
はい、私のサイトにXSSの脆弱性があり、攻撃者がそのトークンを読むためにJavaScriptを注入すると、データ（CSRFトークン）が漏洩する可能性があります。右 ？ –
@Vikas Mangalもちろん、XSSは完全なSOPバイパスであるためです。 XSSのCSRF保護戦略を回避する能力については、より詳細に説明されているので、CSRF予防チートシートを参照してください。 – rook
get要求にcsrf保護が必要なのはなぜですか？ – PeeHaa
私はそれを必要としませんが、将来は単純なアンカータグとして公開されているURLにトークンを送信したいかもしれません。 –
なぜそれをしますか？それは何のポイントですか？関連：http://stackoverflow.com/questions/3477333/what-is-the-difference-between-post-and-get – PeeHaa