3

FindBugs は、EI_EXPOSE_REPと呼ばれるバグを発生させ、次の説明を示します。

EI: 変更可能なオブジェクトへの参照を返すことにより、内部表現を公開する可能性があります

オブジェクトのフィールドの 1 つに格納されている変更可能なオブジェクト値への参照を返すと、オブジェクトの内部表現が公開されます。インスタンスが信頼されていないコードによってアクセスされ、ミュータブル オブジェクトへのチェックされていない変更がセキュリティやその他の重要なプロパティを損なう可能性がある場合は、別のことを行う必要があります。オブジェクトの新しいコピーを返すことは、多くの状況でより良いアプローチです。

SO ( 1、2、および3 ) に関するいくつかの質問は、そのようなバグを回避する方法にすでに対処しており、不変オブジェクトの変更を防ぐことが開発のベスト プラクティスであることは理解していますが、そのようなバグが MALICIOUS_CODE カテゴリに属する​​理由は明確ではありません。 .

この背後にある本当の脅威は何ですか?

悪意のあるコードの問題である場合、攻撃者はほとんどすべてのことを実行でき、可変性は最大の問題にはなりません。それが脆弱性である場合、信頼できないコードが実行された場合にのみ悪用される可能性があり、これが当てはまるユースケースは見当たりません。

これについての見通しはありますか？

ありがとう ！

4

2 に答える 2

2

重要なのは、実装を開くときはいつでも、コードが意図的またはその他の方法で損傷を与える危険性があるということです。たとえば、明らかに悪意のあるライブラリ ユーザーは、jar を分解して詳細を知ることができます。ポイントは、露出のリスクを最小限に抑えることです。これを排除することはできません。

ライブラリにアクセスする外部コードの簡単な例:

アクセス レベルを保持するオブジェクトのような単純なものを考えてみましょう。変更可能であれば、ライブラリのユーザーが独自のアクセス レベルを設定できる可能性があります。この些細なことは、合理的なライブラリによって公開されることはめったにありませんが、内部表現が悪用される可能性がある場合の明確な例です。

肝心なのは、公開されたミュータブルな状態は、コードの推論を困難にし、保護を困難にするということです。あなたのコードや他の人が、あなた自身のコード/ライブラリが使用するものを誤って、または故意に変更する可能性があります。それを考慮せずにライブラリの動作を変更すると、微妙な (またはあまり目立たない) バグが発生する可能性があります。

于 2013-01-02T15:48:28.083 に答える
1

状態を隠し、強力な静的インターフェースを提供するオブジェクトを持つ機能は、Java モバイル コード セキュリティの中核です。プログラマーがこれを台無しにして脆弱性を引き起こす方法はいくつかあります。

値オブジェクトについては、 を検討してStringください。私たちは、変化しないというあらゆる例を信頼していますString。特定のファイル名を検証[チェック]したくありません。たとえば、実際に使用するときに変更したくありません(java.io.Fileこの意味ではうまく機能しないことに注意してください)。また、変更可能な内部には悪意のあるequalsメソッド (たとえば) が含まれている可能性があります。これは、囲んでいるクラスによって呼び出されequalsますが、他の囲んでいるクラス インスタンスの内部オブジェクトへの参照を悪意を持って取得します。

多くの場合、参照型はオブジェクト機能です。通常、それらは、付与された (コンストラクターを介して渡された) オブジェクトの機能を弱めます。たとえば、アクセスできるインスタンスを介して特定のディレクトリにのみファイルを書き込むことができますが、ファイルシステム全体に書き込む機能を持つフィールドがあります。

次に、Java 2 セキュリティ モデルがありますが、これは決して良いことではありません。内部オブジェクトには、特権コンテキストで呼び出されるメソッドが含まれる場合がありますが、これは通常は問題になりません。ここで、悪意のある当事者が (信頼されたタイプの) オブジェクトに配置して、そのコンテキストではすべきではないことを実行します。

もちろん、ランダムにサブクラス化されたクラスには注意してください。get将来のバージョンでメソッドを取得する可能性があります。

そうは言っても、私の意見では、Findbugs からのこの警告は役に立ちません。このコードは、オブジェクトを非表示にすることを意図していなかった可能性があります。

(内部オブジェクトを公開する問題の詳細な説明については、Michael Feathers Working Effectively with Legacy Codeの第 13 章 (および 14) を参照してください。)

于 2013-01-03T01:05:41.883 に答える