実行されないコンテンツは引き続きXSSと見なされますか？
ドメインのいくつかのURLにXSSに対して脆弱であるとフラグを付けたOWASP Zapレポートを処理していますが、ブラウザーによって実行可能なコンテキストでこの脆弱性が出力されることはありません。たとえば、レポートは
path/contacts.php?search=John%3Balert%281%29
デコード：path/contacts.php？search = John; alert（1）
脆弱なURLとして。
アプリケーションは、この特定のコンテンツをユーザーへの応答に反映します。
var search = "John;alert(1)";
これが、アプリケーションでXSS攻撃としてアラートをトリガーするものだと思います。
ここでのXSSは、攻撃者がこのコンテキストで必要な任意のコードを導入し、それをユーザーのブラウザーに反映させることができるということですが、このコードは実行されません。
脆弱性を手動でテストすると、アプリケーションは試行された攻撃で文字を変換してから（PHPのhtmlentities関数を使用して）応答を出力します。
?search=John";alert(1);
次のように返されます：
var search = "John";alert(1);";
だから問題は、これはまだアクティブなXSSの脆弱性として認められますか？
注：入力を適切に検証する機会がまだあることに注意しましたパラメータですが、私の懸念はここでのセキュリティの影響です
これは、自動スキャンツールでは非常に一般的です。それらは非常に賢いだけであり、偽陽性が常に発生する可能性があります（その点では偽陰性も同様です）。その結果、フラグが立てられた脆弱性は手動で検証する必要があります。これが、たとえば、バグ報奨金プログラムが常に「自動スキャナーからの結果は考慮されない」などの通知がある理由です-スキャナーを実行して脆弱性を報告するのは簡単ですが、セキュリティチームはおそらくそれを既に行っているため、99％の確率で時間の無駄です。しかし、それは次の質問につながります：
この特定のスクリプトはこの入力を適切に処理していますか？
それは答えるのがずっと難しい質問です。最も明白な回避策（二重引用符の挿入）についてはすでに確認しましたが、さらに多くのオプションがあります。私の頭の一番上に来る2つは 文字エンコーディングのマングル とバックスラッシュのテストです。前者は少し長めのショットなので、後者に焦点を当てます。
- 入力の最後にバックスラッシュを挿入してみてください_
?search=whatever\_ - アプリケーションがバックスラッシュをエスケープしない場合、JavaScriptは_
var search = "whatever\";_になります。 - これはJavaScriptを壊します。運が良ければ、2番目のパラメーターを介してXSSを注入することもできます。
最後のステップでは例を使用できます。完全なjavascriptが次のようなものだったとします。
_var a="[search input]";var b="[name input]";
_明確にするために、帯域幅を節約するためにコードが最小化されました。これは重要です。また、どちらもバックスラッシュをエスケープしません。したがって、次のようなペイロードをまとめることができます。
?search=\&name=;alert(1)//
あなたはこのjavascriptで終わるでしょう：
_var a="\";var b=";alert(1)//";
_これは有効なXSSペイロードです。バックスラッシュは_var a = "_ステートメントの終了二重引用符をエスケープするため、2番目の変数の開始二重引用符は終了二重引用符になります。結果として、2番目の入力の入力は、通常のJavaScriptとして実行されます。最後のセミダブルコロンとコメント文字で終了するだけで、最後の二重引用符を取り除くことができます。
これでおそらくこれを機能させるための運はありません。彼らがバックスラッシュも適切に処理するなら、あなたは運がありません。これらの行が別々の行に分割されている場合も、運がありません（ほとんどのバージョンのjavascriptでは、行継続文字が必要ですが、非標準のブラウザー動作が時々発生します）。ただし、バックスラッシュをエスケープするのを忘れて、同じ行に2つの入力がある場合は、XSSの脆弱性があります。
まとめ
本当にこれは主な要点を強調していますが、これらが非常に扱いにくい理由です。必要なエクスプロイトの種類は、データが挿入されるコンテキストによって大きく異なり、自動化されたスキャナーがすべてをテストすることは事実上不可能です。したがって、侵入テスターとして、すべてのオプションに精通している必要があります。幸いにも、これはXSSが非常に一般的である理由でもあります-プログラマーは、XSSの脆弱性から保護するために注意しなければならないすべての方法を理解することも同様に悪いです。
はい、これは誤検知のように見えます。明らかに、あなたがやっているように、手動テストで再確認する必要があります。これがページ上でペイロードが反映される唯一の場所であることを確認できますか？私はこのZAPバグを提起しました： https://github.com/zaproxy/zaproxy/issues/5958
John";alert(1);でテストすると構文的に正しくないになります。だから脆弱性があっても何も起こりません。ブラウザはJavaScriptのエラーを報告するだけです。つまり、シンボル_"_はJavaScriptを無効にします。
クライアントコードの動作をテストするには、validJavaScriptを使用する必要があります。
リクエストで次のJavaScriptコードalert(1);を使用します。
_path/contacts.php?search=alert%281%29
_このコードがブラウザで実行される場合、これは脆弱性があることを意味します。実行されない場合、これは何も意味せず（脆弱性がないことを証明しません）、コードのさらなる分析が必要になります。