web-dev-qa-db-ja.com

適切なJavaScript文字列エスケープを使用して、XSSがJSON応答を活用することは可能ですか

JSON応答は、Arrayコンストラクターをオーバーライドすることにより、または敵対的な値がJavaScriptの文字列エスケープされていない場合に悪用される可能性があります。

これらのベクトルの両方が通常の方法でアドレスされると仮定しましょう。 Googleは、すべてのJSONに次のような接頭辞を付けることで、JSON応答の直接ソースをトラップすることで有名です。

throw 1; < don't be evil' >

次に、残りのJSONが続きます。したがって、悪魔博士は、ここで説明されているような悪用を使用して http://sla.ckers.org/forum/read.php?2,25788 Cookieを取得することはできません（ログインしていると仮定）彼のサイトに以下を置くことによって：

<script src="http://yourbank.com/accountStatus.json">

文字列エスケープ規則については、二重引用符を使用している場合は、それぞれにバックスラッシュを追加し、各バックスラッシュに別のバックスラッシュなどを追加する必要があります。

しかし、私の質問は、あなたがこれをすべてやっているとしたらどうでしょうか？

Burpsuite（自動セキュリティツール）は、JSON応答でHTMLエスケープせずに返される埋め込みXSS試行を検出し、XSS脆弱性として報告します。私のアプリケーションにはこの種の脆弱性が含まれているという報告がありますが、確信はありません。私はそれを試しましたが、エクスプロイトを機能させることはできません。

ですから、これは正しいとは思いませんが、StackOverflowコミュニティに意見を求めてください。

特定のケースが1つあります。IE MIMEタイプのスニッフィングは、悪用につながる可能性があると考えています。結局、IE 7 "画像コメントに埋め込まれたスクリプトタグは、Content-Typeヘッダーに関係なく実行されました。また、このような明らかに愚かな振る舞いを最初に置いておきましょう。

確かにJSONは、ネイティブのJavaScriptパーサー（FirefoxのWindow.JSON）または古いデフォルトのjQueryの動作に従ってeval（）によって解析されます。どちらの場合でも、次の式によりアラートが実行されます。

{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}

私は正しいですか、間違っていますか？

javascriptjquerysecurityjsonxss
37
Chris Mountford

記録については、私は答えを受け入れましたが、私が尋ねている正確な文字通りの質問については正しかったので、JSON値内にHTMLエスケープされていないが正しくJSONエスケープされたHTMLが存在するため、脆弱性はありませんでした。クライアント側でエスケープせずにその値がDOMに挿入された場合、バグがある可能性がありますが、Burpsuiteには、ネットワークトラフィックを調べるだけでそれが起こるかどうかを知る機会がほとんどありません。

これらの状況でセキュリティの脆弱性を判断する一般的なケースでは、良いデザインとは思えないかもしれませんが、JSON値の応答コンテンツは正当にユーザー入力をまったく含まず、エスケープされていないDOMに安全に挿入されるように、既にHTMLがレンダリングされている。別のコメントで述べたように、それを回避することは（セキュリティではない）バグです。

0
Chris Mountford

この潜在的なxssの脆弱性は、正しい_Content-Type_を使用することで回避できます。 RFC-4627 に基づいて、すべてのJSON応答は_application/json_タイプを使用する必要があります。次のコードはxssに対して脆弱ではありません、先にテストしてください：

_<?php
header('Content-type: application/json'); 
header("x-content-type-options: nosniff");
print $_GET['json'];
?>
_

nosniffヘッダーは、古いバージョンのInternet Explorerでコンテンツスニッフィングを無効にするために使用されます。別のバリアントは次のとおりです。

_<?php
header("Content-Type: application/json");
header("x-content-type-options: nosniff");
print('{"someKey":"<body onload=alert(\'alert(/ThisIsNotXSS/)\')>"}');
?>
_

上記のコードをブラウザーで表示すると、ユーザーはJSONファイルのダウンロードを求められましたChrome、FireFox、Internet Explorerの最新バージョンではJavaScriptが実行されませんでした。これはRFC違反になります。

JavaScriptを使用して上記のJSONをeval()するか、ページに応答を書き込むと、 DOM Based XSS になります。 DOMベースのXSSは、このデータを操作する前にJSONをサニタイズすることにより、クライアントにパッチされます。

26
rook

Burpsuite（自動セキュリティツール）は、JSON応答でHTMLエスケープされずに返される埋め込みXSS試行を検出し、XSS脆弱性として報告します。

OWASP XSS Cheat Sheetのルール3.1 に記載されている脆弱性を防止しようとしている可能性があります。

脆弱なコードの次の例を示します。

_<script>
    var initData = <%= data.to_json %>;
</script>
_

二重引用符、スラッシュ、改行が適切にエスケープされていても、HTMLに埋め込まれている場合はJSONから抜け出すことができます。

_<script>
    var initData = {"foo":"</script><script>alert('XSS')</script>"};
</script>
_

jsFiddle 。

to_json()関数は、各スラッシュの前にバックスラッシュを付けることにより、この問題を防ぐことができます。 JSONがHTML属性で使用されている場合、JSON文字列全体をHTMLエスケープする必要があります。 _href="javascript:"_属性で使用する場合は、URLエスケープする必要があります。

7
Alexey Lebedev

範囲をIE（すべてのバージョン）に制限する場合、PHPまたはASP.NETに基づいてサイトを実行していると仮定し、IE anti-xssフィルター、あなたは間違っています。ユーザーは脆弱です。'Content-type：application/json 'を設定しても役に立ちません。

これは（おっしゃるように）IEのコンテンツ検出動作によるものです。これは、応答本文のHTMLタグをスニッフィングしてURI分析を含めることを超えています。

このブログ投稿はこれを非常によく説明しています：

http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html

0
anon