2011-01-06 10 views
6

私は、GlassFish/JBossバックエンドで動作する可能性の高いJava EEアプリケーションを構築するための要件段階にあります(今は関係ありません)。私はを知っています要件時にアーキテクチャについて考えるべきではありませんが、コンポーネントがどのように一緒にスナップするかを想像し始めてはいけません:-)Javaクライアント.classファイル保護

ここでは、
(1)クライアントアプリケーションはSwingボックスになります
(2)クライアントは無料でダウンロードできますが、サブスクリプションモデル()を使用するため、サーバー側の認証/承認を伴うログインメカニズムが必要になります(0)
(3)はい、Javaはベストの問題解決の手fあるいは、この記事の範囲
外の理由は、(4)クライアント側の.classファイルは、最後の(4)の要件は、この記事の基礎であることを逆コンパイル

に対して保護する必要があります。

私はソースコードを実際に逆コンパイルして取得する人が心配しているわけではありません。最終的には、軽量なビジネスロジックによって駆動されるSwingコントロールです。

コードを逆コンパイルしてサーバーを悪用/攻撃し、再コンパイルして起動するシナリオが心配です。

私はあらゆる種類の難解なソリューションを構想しましたが、これがJava EE開発者の共通のソリューションに共通の問題であるかどうかはわかりませんでした。何かご意見は?

「コード難読化」技術には興味がありません!

ありがとうございました!

+0

私は実際には理解していません...悪意のあるクライアントが行うことができるものよりも、サーバー側で認証と承認が行われる場合は、 – Rekin

+0

"悪い人"が最後にスニファを置き、送信されているものを把握できるというネットワーク環境では、忘れないでください。 – Suirtimed

+0

@Suirtmed:これはWebブラウザのクライアントアプリケーションでも同じです。ソリューションは簡単です - 暗号化された通信(SSL)を使用してください。基本的には、コードの暗号化を正当化する理由が見つかりません。 – Rekin

答えて

5

私はここにあなたに悪いニュースを持って来ました。これをやめることはできません。

私はこれを深く掘り下げました。 JVMの最下位レベルでは、クラスローダーはクラスファイルである暗号化されていないバイトストリームを取得する必要があります。 JVMを独自のコードに置き換えることはできません。さらに、そこには、バイトストリームを表示(コピーなど)できるフックがあります。より高いレベルで何をしていても、JVMは常にこの点に達し、クラスファイルへのアクセスを許可します。クラスファイルを取得したら、それを逆コンパイルすることができます。難読化のテクニックやツールはそれを減速させたり難しくしたりしますが、それを止めることはできません。

私は強くお勧めします試して、真のセキュリティ方法を使用してサーバーを保護することをお勧めします。あなたがクライアントに与えるものに秘密のソースを埋め込まないでください。彼らは十分に決定されれば、何とかそれを得るでしょう。

+1

+1。まったく。あなたはおそらく、Skypeの通信アルゴリズムを壊すことを聞いたことがあります。暗黙のセキュリティはセキュリティではありません。 – Rekin

+0

それは良い投稿と真です。常に安全で堅牢なサーバーを構築して、電線から来るあらゆるコンテンツを扱うことができます。 – bestsss

3

これは一般的な「強力な弱い」暗号化の問題です。アルゴリズムの知識がメッセージ(ログイン)を妥協するのに十分であれば、暗号は弱いです。

代わりにOAuthのようなものを使用するのはどうですか?サーバーとの一回限りの認証プロセスを通じて、クライアントアプリケーションにトークンが与えられ、必要に応じてサーバーは任意のクライアントに対していつでも認証を取り消すことができます。

また、認証は認証の代用ではありません。あなたのシステムがそれが誰かを知っていると思っているからといって、彼らは彼らが望む何かをする権限を与えられるべきではありません。 JAASやSpring Securityで提供されているような適切なアクセス制御を展開し、それを認証にリンクする必要もあります。クライアントからのすべてのコールの最初のチェックは認証のためのもので、2番目はその特定のクライアントが最初にコールを行う権限を持っているかどうかです。

あなたのやることに関係なく、サーバーはユーザーに与えられた権限に基づいて呼び出しを許可する必要があります。

9

コードをデコンパイルして、サーバーの悪用/攻撃に使用すると想定する必要があります。

サーバーの動作のみを信頼します。

+3

追加するだけです:@ Zac:あなたの懸念事項は**攻撃者が害を引き起こすためにアプリケーションを必要としないため、サーバー上のユーザーをどのように認証するのでしょうか? – Jeremy

1

まともなサーバー認証を使用し、アプリケーションにユーザー名、パスワード、または暗号化キーを保存しないでください。そしてRekinのコメントとして、あなたのコードでサーバー保護を裏切ることはできません。

通信を暗号化する必要がある場合(要件のようには見えません)、SSLまたは公開鍵暗号を使用してください。

0

私はポイント数4

ための「箱から出して考えて」ソリューションを持っている私は、あなたが持っている...それが認証するためにオンラインになると、アプリケーションがネットワークアクセスを持っている

  1. を想定していますバンチ、または "jar"ファイルをクラスに含めます。唯一の違いは、クラスが対称キーを使用して暗号化されていることです。
  2. アプリケーションが起動すると、アプリケーションはオンラインになり、認証され、安全な接続(SSLなど)でキーを取得します。
  3. 次に、暗号化されたすべてのファイルをメモリにロードして復号化します。
  4. 次に、カスタムクラスローダーを作成し、ClassLoader.defineClassを使用してクラスローダーに読み込み解除クラスをロードします。
  5. あなたはいいですね。

これは物事を行う具体的な方法ではありません。しかし、あなたのコードを盗むのがやや難しくなります。しかし、他のポスターが言っているように、クライアント側のコードに秘密を隠すことはできません。

+0

上記の私の答えをご覧ください。私はこれを正確に調査しました。残念ながらそれはあなたを守るものではありません。カスタムクラスローダーは、ある時点でJVMに付属している具体的なクラスローダーに制御を渡す必要があります。フックは、解読後に常にそこにあります。 – rfeak

+0

@rfeak - 100%があなたに同意します。 – Paul

関連する問題