永続性XSSがWebアプリケーションファイアウォールで検出できないのはなぜですか？
この [〜＃〜] owasp [〜＃〜] の記事では、「データ検証を使用すると、反映されたXSSのみを検出して防止でき、永続的なXSSを検出できず、DOMベースのXSSのみが制限されます。攻撃の一部がリクエストのパラメータで送信された場合の度合い。」なぜですか？
悪意のあるスクリプトがアプリケーションに格納されると、GET/POSTリクエストは悪意のあるものには見えなくなりますが、スクリプトは被害者側で実行されます。ただし、永続的なXSSを実行するために、攻撃者は悪意のあるリクエストをサーバーに送信する必要があります。これはWAFによって検知され、実行を停止する必要があります。
特定の入力フィールドの有効な入力と無効な入力を完全に区別できるようにきついをアプリケーションに合わせて調整すると、入力フィールドを使用して永続的なXSSを挿入します。
ただし、通常、WAFは特定のアプリケーションに厳密に適合しているわけではなく、この場合、いくつかのヒューリスティックを使用して一般的な攻撃を検出します。それとは別に、永続的なXSSは異なるオリジンを持つことができ、入力フィールドを使用したり、Webインターフェースを使用したりしてアプリケーションに追加する必要さえありません。たとえば、Amazon Kindleストアに保存されたXSSの脆弱性があり、XSSは本の説明のメタデータ内のスクリプト Amazon.com Stored XSS via Book Metadata によって引き起こされました。
WAFは確かに永続的なXSS攻撃をキャッチできるので、この点は理想的に表現されていないと思います。
しかし、少なくとも2つの問題があります。
- 永続的なXSS攻撃は、Webリクエストだけで発生するのではなく、電子メールなどの他のさまざまな手段で発生する可能性があります。この脆弱性は、データがデータストレージ（dbなど）から読み取られて印刷された場合にのみ発生します。 WAFがdbとサーバーの間の接続をリッスンしない場合（これは、私の知る限り、あまり一般的ではありません）、これを検出できません。
- コンテキストがありません。 WAFは、受信した要求と生成された出力を確認する場合があります。したがって、ユーザー入力がエコーされるコンテキストと、それが安全かどうかを通知できます。永続的なXSSの場合、このコンテキストが欠落しているため、たとえば
');alert('1が安全な入力であるかどうか（または入力がどのように処理され、エンコーディングによって安全にされているか）は明確ではありません。