問題タブ [spring-remoting]

Websphere 8.5.5 にデプロイされたリモート インターフェイスがあり、これをスプリング ブート アプリケーションで検索したいと考えています。RMI私も使用した共通のインターフェースとしてスプリングブートで同様のインターフェースを作成しましSimpleRemoteStatelessSessionProxyFactoryBeanたが、返されたプロキシはあり、ポインターをnullスローしていましたnullproxy.invokeMethod()

今、このエラーをスローしています:

IBM WebSphere インスタンス (バージョン 8.5.xx) 上のアプリケーションに共有ライブラリが追加された場合にのみ、次のエラーが発生します。目標は、いくつかのアプリケーション間の多くの共有ライブラリ (jar) をサーバー上の共有ライブラリに移動して、アプリケーションの戦争サイズを縮小することです。私が見たところ、war ファイルのサイズが縮小されているかどうかは関係ありません。この共有ライブラリが追加されるたびに、以下のエラーが表示されます。

以下は、モデル クラスが小さいスケールでどのように見えるかの同様の例です。私は主に、それが実際に Serializable を実装していることに注意したかった (デフォルトの serialVersionUID を使用):

デバッグのアイデアは、少なくとも大歓迎です。また、共有ライブラリがサーバー上のアプリケーションに追加されていない場合、このリモート メソッドの呼び出しは正常に機能しますが、共有ライブラリが追加されている場合は機能しないようです。また、サーバー上の共有ライブラリには、見つからないクラスを含む jar がありません。見つからないクラスの jar が WEB-INF/lib フォルダーにあり、サーバーにインストールされることを確認しました。

Spring の HTTPInvoker メカニズムを使用してデータを交換する Spring ベースのクライアント/サーバー アプリケーションのセキュリティを評価したいと考えています。HTTPInvoker で使用される Java シリアライゼーションに関するいくつかの脆弱性が過去に対処されたことを知っています。最も顕著なものの 1 つはjava.lang.reflect.Proxy、悪意のある方法で a が使用された場合に任意のコードが実行される可能性です。http://wouter.coekaerts を参照してください。詳細な説明については、be/2011/spring-vulnerabilitiesを参照してください。

修正には、プロキシ クラスの逆シリアル化を無効にする新しい設定が含まれていました。 を参照してくださいRemoteInvocationSerializingExporter#acceptProxyClasses。私の理解では、プロキシ クラスは Java の (デ) シリアル化に重大なリスクをもたらし、多くのエクスプロイトはプロキシ クラスに依存しています。

このシナリオで攻撃者が HTTPInvoker とその基盤となる Java シリアライゼーション メカニズムの脆弱性を悪用するために必要なプロキシ クラスの最も重要な代替手段は何ですか? 私のレーダーにあるはずのプロキシクラスを使用するのと同じくらい深刻な脆弱性はありますか?

ヒントをいただければ幸いです。ありがとう。