Java コードの逆シリアル化に関する問題を特定できるようにしたいと考えています。何を探すべきですか？たとえば、一部の Java コードが「Java カレンダーのバグ」を悪用しようとしているかどうかを判断するにはどうすればよいでしょうか。私は Java プログラマーではありませんが、シリアライゼーションと OOP の背後にある概念は理解しています。いくつかの安全性チェック (コンパイラ警告ツールのようなもの) を実装しようとしています。
編集:コメントに基づいて、質問を少し変更したいと思います:分析されたすべてのコードは「信頼できない」と考えています。潜在的な危険性を評価する方法はありますか? つまり、逆シリアル化のバグに関して、コード A は B よりも危険であると言えますか? 何を探すべきですか？
まず、セキュリティの脅威を判断するためにコンテキストを理解する必要があります。(「信頼」について話すとき、私は少し近道をしています。意図的に悪意を持って話しているのです。)
シリアル化されたデータが同じ信頼で作成、保持、および読み取られた場合、実際の問題はありません (標準的なバグ以外)。機密情報を書き込む場合、シリアル化されたデータも機密であることに注意してください (明らかなように見えますが、そこにはかなりの量の間接性があります)。
シリアル化されたデータが何らかの理由で信頼できない場合は、もう少し検討する必要があります。再作成されたオブジェクトの内部構造は「異常」である可能性があります。データに一貫性がない可能性があります。別々にする必要がある変更可能なオブジェクトを共有している可能性があります。デシリアライゼーションは、無限ループ、または宇宙の熱死の前にたまたま完了できない非無限ループを引き起こす可能性があります。そしてもちろん、データは嘘かもしれません。
信頼性の低いコードで使用されるライブラリ コードを作成している場合は、さらに興味深い結果が得られます。
「カレンダー バグ」(および類似のバグ) の場合は、悪意のあるデータと悪意のあるコードを含む任意のストリームを逆シリアル化することです。Java セキュア コーディング ガイドラインでは、カスタム メソッド内で (「Java2 セキュリティ モデル」を使用して) セキュリティ チェックを行うことを提案していreadObjectます。これは、コードとデータが持つ以上の信頼でデシリアライゼーションを呼び出すべきではないことを意味します。
デシリアライズ可能なオブジェクトの側から見ると、事態はより複雑になります。、、、またはデフォルトのデシリアライゼーションObjectInputStreamによって提供されるオブジェクトは、悪意のあるコードによってキャプチャされた参照を持つか、非最終クラスの場合、悪意を持ってサブクラス化される可能性があります。オブジェクトは、部分的に初期化されている場合、逆シリアル化中にも使用できます。逆シリアル化は、逆シリアル化されたクラスの「実際の」コンストラクターを呼び出しません ( /は一種の疑似コンストラクターであり、s を設定することはできません)。それは悪夢のようなものなので、機密性の高いクラスをシリアライズ可能にしたくないでしょう。readObjectreadUnshareddefaultReadObjectreadFieldsreadObjectreadObjectNoDatafinal
シリアライゼーションとデシリアライゼーションの実装には、多くの脆弱性が存在します。自分で実装しない限り、これについて心配する必要はありません。
Hmm... your question is a bit general. Did you take a look at this article? It's about Java's serialization algorithm, but from Google's cache because the main page seems to be down at the moment.
Javaオブジェクトをシリアル化して別のアプリケーションに転送する場合は、アプリケーション間で共有されるキーを使用してオブジェクトに署名することを検討してみませんか？中間者攻撃から身を守るには十分なはずです。
検証問題の核心に戻ると、検証は汎用言語では非常に困難です。このトピックに関する科学出版物を探す必要があります。最も一般的に適用される手法はサンドボックス化だと思います。2番目のアプローチは、言語を制限し、危険なコマンドの実行を禁止することです。たとえば、YahooCajaライブラリはこの手法を使用します。
Java の既知のセキュリティ ホールを悪用するコードを無効にする最善の方法は、バグを修正した Java バージョンにアップグレードすることだと私は考えていました。そして、次善の方法 (シリアライゼーション関連のバグに対処するため) は、未知/未検証/安全でないソースからのすべてのシリアライズされたデータを疑わしいものとして扱うことです。
Java コードのセキュリティ バグを分析して問題を特定するのは簡単ではありません。使用されている Java メカニズムや悪用される可能性のある Java メカニズムを深く理解する必要があります。特に、ゼロデイ セキュリティ ホールのエクスプロイトを探している場合は、(一般的に) 試みられたエクスプロイトを見つけようとするのはさらに困難です。他にも潜在的なベクトルがあることに注意してください。
(Java に未知のセキュリティ ホールを見つける簡単な方法があれば、Sun やその他のセキュリティ研究者が既にそれらを使用していたことは間違いありません。)