.jarをシールする理由は何ですか?それをどのように確認しますか?


9

密封されたjarファイルを作成しましたが、密封されていないjarファイルを使用した場合と比較して違いはありません。

  • 瓶が密封されていることを確認するためにどのようなテストを実行できますか?
  • シールされていないものを使用することを好む理由は何ですか?
  • 封印すると、プロジェクトのユーザーに問題が発生しますか?

3
タイトルと主な質問を投稿で書き直しました(この時点ではほとんどマイナーな言い回しが調整されています)。今は少し良くなっているはずです。

1
JARファイル内のシールパッケージを読みましたか?これは、個々のパッケージとjarファイル全体の両方に適用されます。

回答:


10

jarファイルで使用されるパッケージに存在するクラスを定義することにより、jarがシールされていることをテストできます。瓶が密封されている場合、すべてのパッケージは通常密封されていますが、パッケージごとに密封することもできます。次に、作成するクラスは、そのパッケージ内のクラスの保護されたメンバーまたはデフォルトのメンバーにアクセスしようとします。

たとえば、jarにcom.example.Widgetパッケージcom.exampleがシールWidgetされたクラスがあり、保護された/デフォルトのメンバーがある場合、com.example.Testそれらのメンバーへのアクセスを試みるクラスを作成します。これは失敗するはずです。

シーリングの理由は、テスト方法の説明にあります。コードを自己完結型にして、jarのユーザーはパブリックメンバーのみを使用する必要があります。パッケージは、プログラムで使用されるjar(およびIDEのbinフォルダー)全体で一意である必要はありません。jarと同じパッケージでクラスを定義し、問題を引き起こす可能性のあるprotected / defaultメンバーにアクセスできます。多くの場合、デフォルトの可視性はfriend、同じプログラマーが両方のクラスで作業して内部を理解するため、同じパッケージ内の他のクラスが安全であるだけのアクションを実行できるようにすることにより、C ++のキーワードに類似して使用されます。おそらく、デフォルトの可視性メソッドは、クライアントコードがアクセスしないことを理解して、パフォーマンスの名前の一部の境界チェックを無視します。たとえば、StringJavaのクラスには、これらのタイプのメソッドがいくつかあります。これは、大量のコードがそれに依存するため、文字列の処理を超高速にする必要があるためです。BigDecimalはその上に構築されBigInteger、デフォルトのアクセスを使用して、クラスの他のユーザーが使用してはならないいくつかの操作を最適化します。

TL; DR:同じパッケージ内のクラスは、パフォーマンスまたは単純化のために、お互いの非パブリックメンバーにアクセスする場合があります。このアクセスでは、不変条件と前提条件がチェックされない場合があります。クラスパスの複数の場所にある同じパッケージのクラスを配置できます。パッケージまたはjarをシールすると、クライアントコードがこれらのメソッドにアクセスできなくなります。

これは、jarのユーザーに問題を引き起こしません。jar内のリソース(クラスファイルなど)にアクセスするクラスローディングメカニズムは、密封されたjarおよびパッケージを完全にサポートします。

関連資料:JARファイル内のパッケージのシーリング


ウィジェットを完全に拡張できるようにしたい場合、保護されたメンバーがアクセスできなくなるため、jarファイルをシールしないでください。またはそれのために密封されていない別の瓶を作成することがありますか?言い換えれば、3D JMonkeyEngineのように、彼らは私が思うjarファイルを密封しません(そして、配布するときにも密封しないように注意する必要がありますが、密封されている場合、プロジェクトが機能していないことがわかります。保護されたメンバーへのアクセス)。
Aquarius Power

また、保護されたメンバーが同じプロジェクトのクラスからアクセスできないようにしたかったのです。この場合、別の小さなプロジェクトを作成し、メインプロジェクトでその密封されたjarファイルを使用する必要があると思いますか?または別の方法があるでしょうか?
Aquarius Power

も読んで、私たちの場合に、SecurityExceptionについて密封されたパッケージの「クラスを上書き」してみてください。
Aquarius Power

1
リンクされた記事から:「JARファイル内のパッケージはオプションで封印できます。つまり、そのパッケージで定義されたすべてのクラスは同じJARファイルにアーカイブする必要があります。」これは単にクラスのパッケージ仕様を制限することに関するものであり、私の回答で説明しているように、同じパッケージ内の他のクラスからアクセス可能なデフォルト/保護されたメンバーに影響を与えます。これは継承と直交します。つまり、密封されたjarのクラスを拡張でき、保護されたメンバーにその方法でアクセスできます。

封印されたパッケージのクラスを拡張しない場合は、それを作成しfinalます。jarの内部ではなく外部に拡張したい場合は、この質問の範囲外であるデフォルトの可視性クラス、インターフェース、ファクトリーメソッドなどを検討する必要があります。

2

2番目の質問に答えるために、Jarをセキュリティ対策として封印します。これにより、実行時にコードベースに追加のクラスが追加されるコードインジェクションのフォームが防止されます。

ユーザー入力に基づいてオブジェクトが作成されるコードには、ある程度の反映があります。これらのオブジェクトを作成するコードでは、固定パッケージ名のクラスのみをインスタンス化できます。

ユーザーが作成できるようにしたいクラスを含むjarをシールすることにより、ユーザーが危険な可能性のある新しいクラスを作成して、実行時にソフトウェアでインスタンス化できるようにすることはできません。クラスが正しいパッケージにない限り、コードはそれをロードせず、Jarをシールすると、ユーザーがアクセスできるようにしたいクラスだけがアクセス可能になります。

私たちの瓶が封印されていなかった場合、ユーザーはインスタンス化できる新しいクラスを追加する可能性があります。これはセキュリティ上のリスクになります。

TL; DR:Jarsを封印することで、1種類の悪意のあるコードインジェクションを防ぐことができます。


したがって、基本的には、新しくインスタンス化されたクラスへのアクセスをハードコード(文字列定数)して、正しいパッケージにあることを許可する必要がありますか?また、それがjratプロファイリングを妨げるかもしれません。
アクエリアスパワー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.