POSTデータ(JSON)を受け取り、リクエストオブジェクトの一部をJSON応答で返すWebサービスがあります。
誰かが要求オブジェクトに任意のHTMLを追加する可能性があるため、ブラウザによって応答がHTMLとしてレンダリングされる場合、これはXSSに対してオープンです。
これを軽減する標準的な方法は何ですか?私が考えることができる現在のオプションは次のとおりです。
X-Requested-With: XMLHttpRequest
ヘッダーを含むリクエストのみを許可して、サービスへの非Ajaxリクエストに依存する攻撃を阻止するapplication/json
で応答を送信し、ブラウザがこれをHTMLとしてレンダリングすることを拒否することを望みます私はこれについて具体的な参考文献を見つけることができませんでした。
応答に安全でない文字をエンコードします(これを行うにはどうすればよいですか?\ uxxxxを使用して?)
はい。特に<
から\u003C
へ。
JSONエンコーダーには、これを行うためのオプションがすでに存在する場合があります(たとえば、PHPではJSON_HEX_TAG
)。それ以外の場合は、エンコード後に文字列を置き換えるのは簡単な作業です。 (<
が文字列リテラル以外のJSONで合法的に使用される場所がないので、これは安全です。)この時点で、先頭のチャフを含めて、クロスオリジンスクリプトが含まれないようにすることもできます。
正確さとしてapplication/json
として送信しますが、必ずしもすべての古いブラウザがそれを尊重するとは限りません。 X-Requested-With
ヘッダーに依存することは、キャッシングでうまく機能しないため、一般的に問題がありますが、それは問題にはなりません。
次の点に注意してください
潜在的なXSSの脆弱性は、正しいContent-Typeを使用することで回避できます。すべてのJSON応答はapplication/json
タイプを使用する必要があります。
nosniff
ヘッダーは、古いバージョンのInternet Explorerでコンテンツの盗聴を無効にするために使用されます。
常に外部プリミティブをJSON文字列のオブジェクトにします。
悪用可能:
[{"object": "inside an array"}]
悪用できない:
{"object": "not inside an array"}
また悪用できません:
{"result": [{"object": "inside an array"}]}
Content-Typeをapplication/jsonに設定し、X-Content-Type-Options:nosniffを設定します(最後のヘッダーは、指定されたcontent-typeを使用するようブラウザーに指示します-追加の推測はありません)。 Content-Disposition:添付ファイルヘッダーの追加を検討することもできます。これはXHRリクエストでは無視されますが、攻撃者がユーザーをだましてブラウザで直接開かせようとすると、ダウンロードダイアログがポップアップします。
http://erlend.oftedal.no/blog/?blogid=127 および http://erlend.oftedal.no/blog/?blogidもご覧ください。 = 134