スキャナーが通常保存されているXSSを検出できないのはなぜですか？保存された（永続的な）xssの検出を自動化する方法はありますか？
保存されたxssの脆弱性を検出するためのツールを、できれば何らかのガイド付きで、できればオープンソースで必死に探しています。そのうちのいくつかは、保存されたXSSで期待される結果をもたらさないことが観察されています。
ZAPプロキシと xsser を試してみましたが、これらのツールの反映されたXSSに関するドキュメントしか見つかりませんでした。
保存されたXSSの場合、「挿入された」ページは脆弱なページと異なる場合があります。
私はここにある簡単な脆弱なアプリのツールをベンチマークしています https://hack.me/101061/persistent-xss.html
手動での悪用には数秒かかりましたが、フォームのURLを指定して脆弱なページをツールに見つけさせる「ガイド付き」モードでも、これまでは自動ツールを使用できませんでした。
引用された両方のツールがそれを行うことができると私は思うが、それは例/ブログ投稿に表示するにはあまりにも簡単であるか複雑すぎるかのいずれかです。誰かがそのようなユースケースを見せてくれれば本当にありがたいです。
あなたが探しているものに関するいくつかの問題と、それらが事実上存在しない理由を以下に示します。
- ツールは、スクリプトを挿入したリクエストに対する即時応答のHTMLソースで挿入されたスクリプトスニペットを検索することにより、反映されたXSSを見つけます。
- スクリプトが即時応答に反映されている場合、同じツールが保存されているXSSも検出します。
- ただし、XSSに対して脆弱であっても、即時応答がスクリプトを反映しない場合があります。たとえば、ユーザーが内部フォームを高特権ユーザーに送信すると、すぐには表示されません。この場合、フォームが永続的なXSSに対して脆弱である場合、特権の高いユーザーのブラウザで実行されます。
- 永続的なXSSは、主にPOSTリクエストで発生します。通常、ポストリクエストをスキャンすると、データベースが枯渇します。
自動化するためにできること：
現時点では、同じツールを使用できるかどうかはわかりません。ただし、回避策を提案したいと思います。
- Burp Professional試用版を使用する[試用版ライセンスを送信するには1〜2日かかります。]
- ユーザーオプション>その他ロギングセクション内チェックボックスをクリックして、すべての応答を記録します。
- アプリケーションを閲覧し、スパイダーし、スキャンしたいリクエストを選択し、スキャナータブに送信します。通常の脆弱性を特定しますが、永続的なXSSを見逃す可能性があります。
- スキャン後、すべてのユーザー特権レベルでアプリケーション全体を参照してスパイダーします。
ログファイルでスクリプトを確認します。 Burpを挿入したスクリプトは、通常、ランダムな文字の署名が付いているため、区別できます。たとえば、挿入されたスクリプトは次のようになります。
jklmn | stackexchangeでポストできないスクリプトを挿入| jklmn
したがって、応答ログファイルで挿入されたスクリプトを特定すると、リフレクションのページ、パラメーター、およびソースを特定できます。