デシリアライゼーションXMLまたはJSON

Question

からIは、オブジェクトが、標準的な「直列化」インターフェース（this参照）とシリアル化されたときに逆シリアル化が脆弱であることができる知っています。しかし、オブジェクトがXMLまたはJSONにシリアル化されているときにこの脆弱性が適用されますか？それがどうでしょう？ それがどうして起こるか分かりませんので、いくつか例を挙げておきたいと思います。 ありがとうございます。かなり具体的にあなたがオブジェクトをデシリアライズし、頻繁に使用されるパラメータに使用するシリアライズライブラリに依存し、それは、単一の答えを提供するのは難しい

Answer 1

。 「それは可能である」と同様に

、はい、それが可能です。ここでは例えば、XStreamのためのサンプル悪用しています：

http://blog.diniscruz.com/2013/12/xstream-remote-code-execution-exploit.html

Answer 2

トピックの周りの一般的なチャットは、次のとおりです。

悪いデータに対して良好な守備は1がいっぱいに書くことができます直列化技術を使用することです仕様。完全な仕様では、オブジェクトの構造や内容だけでなく、すべての値フィールドの有効範囲を指定でき、指定されたすべてのリスト/配列の長さを指定できます。

これを行う多くはありません。 ASN.1、XSD（XML）、およびAFAIK JSONスキーマにはすべて値とサイズの制約があります。興味深いことに、ASN.1スキーマとXSDスキーマの間に形式的に定義された変換があります。

あなたが実際に使用してこれらを使って何を行うかどうかのツールに至るまでそれはそれからです。私が見たASN.1ツールのほとんどは、これを非常にうまく行い、スキーマに準拠していないオブジェクトをシリアライズしようとしているかどうかを教えてくれます。考え方は、悪いデータは読み込みとして拒否されるため（たとえあなたがメモリ内に無効なオブジェクトを取得することはありません）、あなたがしたい場合であっても誤って悪意のあるデータをあなた自身が送信/書き込むことは決してありません。

いくつかのXSDツールでは制約がチェックを行います。私はxsd2code ++と思う。マイクロソフトのAFAIK xsd.exeは動作しません。

私はJSONの土地に精通していませんが、私が知る限り、オブジェクト全体を読み込み、それをスキーマ（「遅すぎる」と感じます）と比較する傾向があります。いくつかの自動生成されたコードでデータを読み取ってチェックします。オブジェクトを直列化するときは、プログラマが結果をスキーマと比較する必要があります。

対照的に、Googleプロトコルバッファーなどの技術では、制約チェックをまったく行うことはできません。 GPBを使ってできることは、.protoファイルをコメントして、開発者がそれを読むことを望むことです。

C＃/ Javaでシリアル化可能なクラスを直接記述するコードの最初のアプローチでは、コードを自分で書く場合に限り、制約チェックを行うことができます。

便利な古い技術私が今まで使ってきたすべてのserialisationsの

、これまでで最も厳しいがされているASN.1で（まともなASN.1ツールを使用して）。それは古いもので、非常に遠距離通信です。（ITUの1980年代後半、睡眠に問題がある場合は、その基準の1つを読んでください）。しかし、その年齢にもかかわらず、それはまだ最新のものであり、絶え間なく進化しています。

たとえば、元々は驚くほど近代的なワイヤフォーマットがいくつか生まれました。 XMLとJSONはい、そうです; XMLやJSONのデータ形式（ASNと同様）にシリアル化するコード（C++、Java、C＃）にコンパイルされたASN.1スキーマを持つことができます。1のBER、uPERなどのより伝統的なバイナリフォーマット）をサポートしています。

厳しい制約とデータフォーマットの柔軟性は驚くほど役に立ちます。ラジオから超小型ビットコードのuPERメッセージを受信し、それを読んだときに制約をチェックしてから、JSON/XMLとして他の場所に渡しても、手作業でコードを書く必要はありません。

複雑なシステム統合の問題については、私はそれを打ち負かすものは何も見つかりませんでした。

Useful old technology