web-dev-qa-db-ja.com

XSS:コンテンツタイプ:application / json

背景情報
-アプリケーションは特定のURLへのリクエストにcontent-type: application/jsonで応答します

  • JSON応答には、要求からのパラメーターが含まれています
  • 引用符をスラッシュでエスケープします
  • 応答の評価を行いません
  • X-Requested-With: XMLHttpRequestのないリクエストに応答します(つまり、URLをパラメーター付きでURLに直接貼り付ける場合)

質問:

アプリケーションでXSSを成功させる方法はありますか?

明確でない場合は、質問を自由に編集してください

5
Sachin Kumar

DOMベースのXSS は引き続き可能です。この場合、JavaScriptがサニタイズされていない出力をページに書き込んでいる可能性があります。

この設計には他にもセキュリティ上の問題があります。

あなたのAPIX-Requested-With: XMLHttpRequestヘッダーのないリクエストに応答しないことを確認します。これは、CSRFだけでなく json data theft にも対処する必要があるためです。 jsonデータの盗難とcsrfの両方で、リクエストはXHRで行われていないため、X-Requested-With: XMLHttpRequestをチェックすることは有効な防御策になることに注意してください。 HTTPリファラーの確認 を使用して、これらの両方の攻撃を緩和することもできます。

このJSON APIのすべてまたは一部にアクセスするために認証が必要な場合は、HTTPSを使用する必要があります。そうしないと、 owasp a9 に違反します。

4
rook

私がいくつかの仮定を行うことができれば(下記を参照)、これは最新のブラウザーでは問題ないようです。 XSSの脆弱性は知りません。

仮定:

  1. (URLパラメーターからの)信頼できないデータは、引用符で囲まれたJSON値のコンテキストにのみ挿入され、他の場所には挿入されません。引用符で囲まれていない値としては挿入されません。キーには挿入されません。

  2. JSONデータを要求すると、サーバーは副作用やその他のアクションを実行しません。 (これは、CSRF攻撃について心配する必要がないことを意味します。)

  3. このJSONデータ構造のどこにも機密データはありません。 (@Rookが説明するように、XSSには関係ありませんが、JSONデータの盗難には関係があります。)

  4. アプリケーションには、クライアント側のXSS脆弱性(別名DOMベースのXSS)はありません。

3
D.W.

考慮すべきことは、IE content-typeであり、ブラウザがテキストの最初の数行をスニッフィングし、それがhtmlのように見えると判断した場合は無視されます。これをすべて実行します。したがって、たとえば、jsonがいくつかあるが、その応答でHTMLタグを取得できる場合、ブラウザはこれを表示して、「HTMLである必要があると思います」と言います。その時点でペイロードが実行されます。 content-typeはtext/htmlではありませんでした。

2
tyweed