セキュリティが強化されている理由と、JSONまたはXMLの理由

Question

Java EEでWebサービスを実装し、その応答がJSONになるようにしたいと考えています。 JSONはXMLと比較してセキュリティが確保されていないのと同じように、私が読んだブログのどこでも言及されているため、JSONのセキュリティ上の問題があることを知りたいだけです。 JSONには、使いやすく、より高速ないくつかの利点があります。

JSONが実際にセキュリティ保護されているかどうかは誰にでもわかります。もしそうなら、それはなぜですか。例を挙げて説明してください。

• クレーム非公開データのための唯一の保護eval

JSON is not as safe as people think it is

について2006

• 懸念 -

  JSON vs XML：

  トピックのカップル古い記事があります。利用可能なvi JSONはユニークなURLを使用します。

• CSRF (Cross Site Request Fogery) - 2007
• ArrayハックハイジャックのブラウザによるJavaScriptのハイパーリンク解析。

Answer 1

これはナンセンスです。 jsonとxmlの両方は、構造化データの表現方法です。それらのどれも「より安全」または「より安全でない」とみなすことはできませんでした。

Answer 2

安全なバージョンはありません。しかし、考慮すべき他の機能があります。

Example 1

Example 2

あなたがjava、phpまたはperlで動作するかどうかは関係ありません。彼らはすべてjsonとxmlを解析できます。 jsonは軽量ですが、xmlでさらに処理できます。 xmlの機能が本当に必要な場合を除き、jsonから始めてください。

Answer 3

JSONとXMLの間に違いはありません。 JSONに関して人々によって参照される「不安定」は、JSONがJavascriptで解析できる方法とは関係ありません。

JSONはjavascriptでオブジェクトをコーディングするための構文に基づいているため、javascriptでJSON結果を評価すると有効なオブジェクトが返されます。

これはJSONをさまざまなjavascriptインジェクション攻撃に開く可能性があります。

解決方法：javascriptでJSONを解析するためにeval（）を使用したり、JSONパーサーを使用したり、エスケープされていないユーザーがレスポンスに生成したコンテンツを許可するセキュリティ問題を修正したりしないでください。

Answer 4

両方のフォーマットがデータを表現しているため、セキュリティに違いはありません。私はJSONを何年も使っており、セキュリティ上の問題は一度もありませんでした。

Answer 5

いずれか一方のセキュリティ上の利点はありません。両方のフォーマットは、データを送信するための単純なプロトコルを提供することを目的としており、デフォルトで暗号化を使用しません（自分で何かを追加することもできます）。 JSONは、アセンブルする文字数が少なくて済むため、一般的に高速と見なされます。 JSONがJavaScript Object Notationであり、すべてのJavaScriptオブジェクトをJSON表現に変換することができるので、JavaScriptでも使いやすいです。

多くの（特に新しい）開発者は、読みやすさのためにXMLを使用することをお勧めします。それは人間がそれを読むことがずっと容易であるような仕方で構成されています。これはもちろん、JSONよりもはるかに大きくなるものですが、決して安全性が低いわけではありません。

これらの転送プロトコルの結果として発生する可能性がある脆弱性は、不適切な解析の結果です。オープンネットワーク上のサービスのパーサーは、コードインジェクションなどの攻撃につながる可能性があるが、JSONやXMLとは何の関係もないため、データが有効であると仮定することはできません。

Answer 6

この投稿は、2つのデータ共有形式で見つかったセキュリティの問題を比較しています。さらに、XXEやDTDの検証などの一般的な脆弱性に対する攻撃の仕組みについて説明したコードスニペットもあります。次に、XMLとJSONの両方を安全に使用できるように、これらのセキュリティ問題を修復/強化する方法を示します。セキュリティの面では

https://blog.securityevaluators.com/xml-vs-json-security-risks-22e5320cf529

、そのデフォルトの設定のXMLパーサはXXEインジェクション攻撃とDTD検証攻撃に開いているので、使用する場合、XMLデータ交換が硬化する必要があります。

：できるだけ早くJSONPが同一生成元ポリシーの制限（CSRF攻撃）をバイパスするために利用されるようので、それが脆弱になり

JSONが、一方で、それ自体がデフォルトの状態では安全ですが、それはデータのクロスオリジン交換を可能にする。

著者はここで比較まとめたもの：セキュリティに関しては

を、信頼できないインターネットに接続された要求を処理することは、XMLやJSONパーサーの最も基本的な機能の一つです。残念なことに、一般的なXMLパーサは、デフォルト設定ではこの目的には適していません。外部エンティティの拡張を無効にするための強化と外部DTDの検証だけが安全です。逆に、JSON解析ではなく、現代の技術を使用する限り、JSON解析はほとんど常に安全です。 Web開発者がこれらのセキュリティリスクを認識し、それらを守るための措置を講じる限り、どちらのオプションも現在のWeb環境では完全に実行可能です。

Answer 7

JSONとXMLの両方が、サーバークライアント通信の媒体として機能します。だから、なぜセキュリティ懸念は1つではなく他のものではないのですか？

基本的な違いは、名前としてのJSON（JavaScript Object Notation）はJavaScriptに非常に近いことであり、JavaScriptメソッドや機能の設計ではJavaScriptがJSON文字列を紅茶のように扱い、解釈しようとしますこれは攻撃者がJavaScriptインタープリタを欺いて脆弱性を引き起こす文字列に埋め込まれた悪質なJavaScriptを実行することを回避するための回避策を提供する一方で、XMLはオブジェクトに解析されて攻撃することを難しくする解析段階を経なければなりません。 このようなJavaScriptの機能は、eval（）メソッドとタグです。

これらはどのようにセキュリティの脆弱性を作りますか？ウェブは同一生成元ポリシーを以下のが

、歴史的にそこに抜け穴はそれを迂回することが判明し、悪質なサイトは、同一生成元ポリシーの意図を破る、認証されたユーザのウェブサイトにクロスサイトリクエストを送信するためにそれらを使用しています。

例： 同じオリジンポリシーが設定されているにもかかわらず、ウェブで<img> <script>などの一部のタグでクロスオリジンGETリクエストを作成できました。

は、私たちは、あなたがウェブサイトwww.authenticatedwebsite.com上にあるが、www.authenticatedwebsite.comから、あなたの個人データにアクセスするためのwww.malicious.com使用このスクリプトタグの挙動から、そのHTML <script src="www.authenticatedwebsite.com/get-user-order-history" />

攻撃でタグを持っているwww.malicious.comを開くために魅了しましょう。

src urlを呼び出しているスクリプトタグは、JavaScriptレスポンスを悪意のあるサイトサーバーに送信するなどの操作を行うためにjavacriptオブジェクトに格納します。

ここではJSONの役割があり、XMLはここでより安全であることが証明されています。 JavaScriptはJSONをよく理解しているので、一部のJavaScriptインタプリタは有効なJavaScriptとしてnaked JSON文字列を解釈して実行します。

まだ変数に割り当てられていないJSON文字列を実行するにはどうすればよいですか？

これはもう1つの派手なハックで実現できます。 返されたJSON文字列が配列を表す場合。 JavaScriptはArrayクラスのコンストラクタを実行しようとします。これで、JavaScriptのArrayのコンストラクタをオーバーライドすることができます。そのため、あなたの個人データへの悪質なWebサイトへのアクセスを与える、

Array = function(){ yourObject = this }; 

これは、基本的にはJavaScriptがコンストラクタを呼び出したときに、現在の解釈配列がyourObjectに割り当てられているようにJavaScriptのArrayコンストラクタを、上書きされます。あなたのような何かを行うことができます。

この攻撃は、より洗練されたハッキン​​グを使用して、JSON文字列の変形で使用できます。

上記は有効なシナリオですが、JSONはGET APIのリターン形式として危険な可能性があります。これは実際には一部のブラウザの一部のバージョンでのみ可能ですが、わかっている限り、有名なブラウザのすべての最新バージョンでは軽減されていますが、ユーザーベースをブラウザのバージョンに分けることができるため、GET API非公開のJSON形式で個人情報を提供します。

JSONレスポンス文字列の前にwhile（true）を追加することで、JavaScriptインタープリタが実際の文字列に到達することはありません。しかし、それはあなたのクライアント側で解析のオーバーヘッドを作成します。

JSONが引き起こす可能性のある別の問題は、です。ブラウザクライアント側でeval()メソッドを使用してJSONを解析しています。 eval()はスクリプトを実行する機能を持っていますので、あなたのJSON文字列にeval()が実行され、危険なアクションを実行するいくつかの隠しスクリプトが含まれている場合は、スクリプトに何を入力するかを攻撃者が尋ねます。しかし、他の人が触れたように、この攻撃は、クライアントコードのどこでもJSONパーサーとしてeval()メソッドを厳密に放棄することで簡単に防止できます。この脆弱性のプラグインは、ユーザーが生成したコンテンツを格納するWebサイトにとって非常に重要です。