web-dev-qa-db-ja.com

JavaScriptに反映されたXSSペイロードを挿入した後にアクセスが拒否されました

Webサイトのページで入力のマルチリフレクションを取得しています。入力のリフレクションの1つがたまたま_<script>_タグ内にあります。先ほど触れたスクリプトタグには、visualwebsiteoptimizer.comという別のドメインを参照するsrcがあり、URL:リダイレクトメソッドを使用して、xssをテストしているドメインを参照しています。

_<script src="https://dev.visualwebsiteoptimizer.com/deploy/js_visitor_settings.php?v=1&amp;a=25349&;url=https://www.targetdomain.com/en-us/search-results.aspx/search=helloworld_

通常のテキストクエリを挿入すると、'-alert(1)-'であるペイロードを挿入するとすぐに、出力は(クエリによって異なります)になります。Webサイトから403アクセスが拒否されました。通常のテキスト入力は問題なく、ページをレンダリングしますが、ペイロードを挿入すると403になります。

誰が何が起こっているのか教えてもらえますか? XSSを取得していますが、WAFが原因でポップしていませんか?

1
j_h_o_m_o

おそらくチェーン内のサイトの1つがXSS保護を実行しているのは、フィルタリングではなく、危険と思われるものをブラックリストに登録し、403を自動的に返すことです。

例として、私がかつての10年の経験で見たすべてのXSSまたはSQLiベクトルに対して着信要求をチェックする10ページの.htaccessファイルを介してすべてのXSSおよびSQLi保護を実行するWeb開発者を知っていました。 alertscriptSELECTなど...攻撃のキーワードの場合、.htaccessファイルにブラックリストに登録され、サーバーは自動的に400を返します。脆弱性の有無にかかわらず、アクセス拒否応答。

XSSを軽減するための良い戦略ですか?私はそうは思いません。しかし、それは間違いなく人々が使用する戦略であり、それが現在の試みがブロックされている理由である可能性が最も高いです。 WAFは、誰かがそのようなフィルターを実装する1つの可能な方法です。もちろん、彼らがそれをどのように行うかに関係なく、最終結果は同じです。ブラックリストが検出してフィルタリングしない攻撃ベクトルが見つかるまで行き詰まります。

2
Conor Mancone