反映されたXSSは、URLエンコーディングのため、Burp Repeaterでのみ機能します
GETリクエストを使用して、げっぷリピーターを介してXSSを反映させることができます。次に、ブラウザーで「応答を表示」をクリックすると、XSSアラートを取得できます。しかし、ブラウザで手動でURLにアクセスすると、ペイロードが実行されません。
Burpリピーターでこのようなペイロードを使用していたときに、アラートを受け取ることができました。
"><html><body><script>alert("1")</script></body></html>
しかし、私が同じURLに行くと、
https://example.com/exp="><html><body><script>alert("1")</script></body></html>`
エンコードされます
https%3A%2F%2Fexample.com%2Fexp%3D%22%3E%3Chtml%3E%3Cbody%3E%3Cscript%3Ealert%28%221%22%29%3C%2Fscript%3E%3C%2Fbody%3E%3C%2Fhtml%3E
ゲップインターセプターでは、XSSは実行されません。これの回避策はありますか？
今日同様のシナリオに出くわしました。デバッグ時に、脆弱なWebページがWebページへの正確なURLパスを反映しており、反映されたXSSに対して脆弱であることがわかりました。最新のWebブラウザーは毎回URLパスをエンコードし、GET変数はサーバーでデコードされます。ただし、この場合、サーバー側のスクリプトは特定のGET変数ではなく、URLパス全体を反映していません。たとえば、以下は脆弱なはずですPHPコード。
<?php echo $_SERVER['REQUEST_URI']; ?>
ここで$_SERVER変数は、取得する入力がURLデコードまたはエンコードされているかどうかに関係なく、そのまま反映します。したがって、最新のブラウザはデフォルトでURLをエンコードするため、悪用することはほとんど不可能です。クライアントの侵入テストの実行中にこのXSSを見つけた場合は、レポートでこれを言及する必要がありますが、CVSSスコアは低くなっています。
私の知る限り、このXSSは、PortSwiggerによって上記で回答されたXSSフィルターとは何の関係もありません。
ここでは、次の2つの可能性があります。
1）RLエンコーディング-ほとんどのブラウザは、URL内の特殊文字を送信前にエンコードします。 Internet Explorerは、クエリ文字列の文字をURLエンコードしません。ただし、例ではペイロードがパスにあります。私が知っている限り、すべての最新のブラウザーはそれをURLエンコードするため、悪用することはできません。
2）ブラウザXSSフィルタ-ほとんどの最新のブラウザ（Firefoxではない）には、反映されたXSSをブロックしようとするXSSフィルタがあります。フィルターは水密ではなく、多くのペンテスターはテスト中にフィルターを無効にします。フィルターバイパスを使用する前に、まずブラウザーフィルターを無効にしてXSSを再現することをお勧めします。