web-dev-qa-db-ja.com

Burpで実行されたJSONを介してXSSを反映しましたが、現実的な条件でそれを行う方法は？

Burpプロキシでシナリオをテストしています。

  1. 私はWebサイトにいます_https://website.com/web_

  2. アイテムを削除するオプションがあります。クリックすると、特定のPOSTリクエストが送信されます（XMLHttpRequest、ページの更新は行われません）。ここで_<script>_タグ：

    _POST /web/deleteItem HTTP/1.1
Host: website.com

returnParameter=<script>alert('xss')</script>
_

  3. deleteItemメソッドは以下を返します。

    _HTTP/1.1 200 OK
Date: Tue, 31 Jan 2017 22:18:54 GMT
X-XSS-Protection: 1; mode=block
Content-Type: application/json;charset=UTF-8
...

{"status":"SUCCESS","result":"<script>alert('xss')</script>"}
_

  4. ステップ1のWebサイトには、JSONを解析して画面に結果値を表示するJavaScript関数があります

  5. alertは_https://website.com/web_に表示されているため、反映されたXSSは正常に実行されました。

しかし、ユーザーをWebサイトに誘導してXSSを実行する必要があるため、このシナリオは現実的ではありません。

簡単なHTML POSTフォームを作成し、パラメータを_https://website.com/web/deleteItem_に送信することでこれを試しました。フィッシングを使用し、ユーザーがフォームを送信するとします。

アクションは実際に実行されましたが、[〜＃〜] json [〜＃〜]応答しか受け取りませんでした。ステップ＃1のページがなかったため、alert('XSS')を実行する必要がある_https://website.com/web_にユーザーがいないため、実際にはXSSとして何も表示されませんでした。ユーザーをページ＃1に送信して、このJSONをXSSで何らかの方法で送信できるかどうかはわかりません。

このシナリオを現実的な条件で実行する方法はありますか？

xssajaxjsonblack-box
3
fing

提案された反射型XSSの脆弱性は、次のコンテンツタイプにより、最新のブラウザでは完全かつ完全に悪用されることはありません。

Content-Type: application/json;charset=UTF-8

Content-typeはHTMLである必要があります。そうでない場合は、不足しているcontent typeでうまくいきます。 content-type application/jsonまたはplain/textを使用することは、どちらもXSSに対する強力な緩和策です。

コンテンツスニッフィング は、コンテンツタイプが定義されていても、古いブラウザでJavaScriptを実行するために使用できます。攻撃者として、ターゲットブラウザーがまだコンテンツスニッフィングを使用している場合、ブラウザーはドライブバイリモートコード実行などのより深刻なバグに対しても脆弱です。

@Jeroenが指摘したように、これは安全でない入力検証問題であり、反射型XSSに対して脆弱ではないかもしれませんが、2次コードインジェクションや永続的なXSSなどの他の問題を引き起こす可能性があります。

4
rook