2016-11-05 22 views
0

私はオンライン情報から少し混乱しています。AJAX GETメソッドによるCSRFトークン保護

バックエンドでSpringセキュリティを使用してCSRF保護を使用しています。

Ajax GETメソッドを使用してHTTPヘッダー内のトークンを渡している間に、私のフロントエンドからCSRFトークンを送信するのは安全ですか?

私はGETメソッドを使用すべきではありませんが、HTTPヘッダーに渡すときにGET Ajaxを使用しても問題ないと言います。

第二に、

私がGET使用してはならない場合は、どのように私はRESTサービス& CSRF保護を使用していますか?私はGETメソッドまたはCSRF保護を放棄すべきですか?

答えて

2

GET要求はサーバー上の状態を変更すべきではないため、通常は「読み取り専用」にする必要があるため、通常はGET要求に対してCSRF保護は必要ありません。

GET要求には通常本体が含まれておらず、したがってトークンが要求パラメータとして送信されるため、漏洩に関する問題は主にブラウザの使用に関連します。したがって、CSRFトークンは、ショルダーサーフィン、ブックマークとして保存、ブラウザ履歴への表示、またはサーバーへのログ記録(AJAX要求にもロギングが適用されます)に表示されます。

あなたはAJAXリクエストについて話しているので、この漏れのほとんどは当てはまりませんが、ヘッダーに設定するとURLに表示される場合に役立ちますが、ログにもヘッダーが含まれる可能性があります。 AJAXリクエストがカスタムヘッダーを設定し、他のクロスドメイン

  • 以上することはできませんので

    しかし、実際に(またはトークンなし)カスタムヘッダを使用しては、多くの場合、

  • 受け入れ言語
  • 受け入れCSRF攻撃を防ぐために使用されます
  • コンテンツ言語
  • 最終-イベントID
  • のContent-Type

したがって、X-Requested-With: XMLHttpRequestのようなカスタムヘッダーを使用します。 jQueryによって設定され、サーバー上のこのヘッダーを検証することでCSRF攻撃を防ぐことができます。

GETおよびPOST要求に同じトークンを持ち、同じ起点にある別のWebアプリケーションのXSS脆弱性を介してGET要求への同じ起点アクセスを持つことについてトークンがあることについては、interesing articleが1つありますGET要求から漏洩し、POSTのために使用される。解決策は、GETにCSRFトークンを使用しないか、GETとPOSTに異なるトークンを使用することです。

あなたの質問に関しては、GETに副作用がない場合、CSRFトークンは本当に必要ではありませんが、傷つけることはありません。一方、GETリクエストによってサーバー上で何かが変更された場合は、実行する内容に応じて別の動詞(POSTなど)を使用し、POSTリクエストをCSRFトークンまたはカスタムヘッダーで保護することを検討する必要があります。

関連する問題