Java Serial オブジェクトを読み取る Java プログラムを取得しました。それを受信すると、プログラムはビジネス ロジックを実行します。Java プログラムのソース コードを持っていないと仮定します。また、Serial オブジェクトの実装方法に関するドキュメントも持っていません。fake
プログラムを実行できるクライアントを作成することは可能ですか?
ありがとう。
偽のクライアントは、予期されたクラスの名前を知っている必要があります。これは、例外メッセージが見つからない場合に検出できます。そのserialVersionUID同上。そして、そのシリアル化可能なフィールドは、同じように発見することはできません。理論的には、シリアル化されたストリームからそれを発見することは可能ですが、任意のクラスが独自のwriteObject()またはwriteExternalizable()メソッドを持つことができるとすると、任意の複雑さを任意にすばやく取得できます。
だから私はカジュアルなリスクとしてこれであまり多くの睡眠を失うことはありません。
また、JARに署名し、関連するパッケージを封印することもできます。これにより、特定のリスクが排除されます。
OTOHアプリケーションのセキュリティが本当に必要な場合は、間違った場所を探しています。
私はあなたの考えに完全に従っていません。
オブジェクトを逆シリアル化することによって、アプリケーションに新しいコードを挿入することはできません。オブジェクトがプログラム内で / によって正常にデシリアライズされるためには、そのプログラムがクラスパス上にオブジェクトのクラスを持っている必要があります。そうでない場合、逆シリアル化は失敗します。
一方、プログラムが特定のセキュリティ上の欠陥を持つ特定のクラスをすでに使用していることをどういうわけか知っていて、その欠陥を悪用できるような方法でそのクラスのインスタンスを逆シリアル化するようにプログラムをだますことができた場合、懸念。(そして、詳細は思い出すことができませんが、このアプローチが特定の脆弱なクラスで使用されたことを漠然と思い出しています。)
肝心なのは、セキュリティを意識したアプリケーションは、信頼できないソースからのオブジェクトや、転送中に変更された可能性のあるオブジェクトを逆シリアル化しようとすべきではないということです。
Javaシリアライゼーションを想定しています。
理論的には、シリアル ストリームを見て、期待されるクラスとフィールドを確認できるはずです。その後、ジャスト イン タイムでクラスを構築できます (ObjectInputStream
ストリームを解析するために使用する場合は、毎回ストリームの読み取りを再開する必要がある場合があります (不明))。カスタムメソッド内のdefaultWriteObject
/の後に書き込まれたデータは、確実に解釈できません。putFields
writeObject
defaultWriteObject
実際には、人々 (Java ライブラリーの作成者を含む) は、少しやんちゃで/を見逃してしまうことがありputFields
ます。これは、ストリームが実際には正しい形式ではないことを意味します。下位互換性のために、今それを修正するのはおそらく少し遅れています。