- PR -

class、JSPの解析防止について

1|2 次のページへ»
投稿者投稿内容
oki
ベテラン
会議室デビュー日: 2004/12/18
投稿数: 55
投稿日時: 2005-06-16 17:51
お世話になります。

servlet、jspで開発したものを試用版として
配布するための検討を行っておりますが
servlet、jspを配布してしまうと容易に解析が可能なので
セキュリティ的に問題があります。

逆コンパイル防止対策やファイル暗号化など調べておりますが
これといった対策が見つかりません。

ご教授お願い致します。


[ メッセージ編集済み 編集者: mt2mt 編集日時 2005-06-16 17:54 ]

[ メッセージ編集済み 編集者: mt2mt 編集日時 2005-06-16 17:55 ]
未記入
常連さん
会議室デビュー日: 2005/05/24
投稿数: 48
投稿日時: 2005-06-16 17:56
どもども
難読化ツールでProGuardというものがあります。参考になりますか？

http://proguard.sourceforge.net/
raystar
ぬし
会議室デビュー日: 2003/01/16
投稿数: 251
お住まい・勤務地: Tokyo/Japan
投稿日時: 2005-06-16 18:45
class ファイルは難読化できるとおもいますが、
JSPはできないんじゃないですかね。。。（あったら知りたいです）

ちなみに難読化したclassファイルも逆コンパイル可能です。
「難読化」ですので、読みにくいコードに変換されるからです。
読みにくいだけですので、追っていけば解析することは可能です。

また、難読化後のclassファイルの実行パフォーマンスは元のclassファイルより、
落ちるのではないでしょうか。

例えば、ServletやBeanなどを全部jarにひっくるめて、
WEB-INF/lib の中に入れてしまえば、
他のJarにまぎれてしまうので、解析しようとした人から見ると
「ん？ドコよんでんの？」ってことになるかもしれません。笑

以上ご参考まで。
raystar
ぬし
会議室デビュー日: 2003/01/16
投稿数: 251
お住まい・勤務地: Tokyo/Japan
投稿日時: 2005-06-16 19:06
ごめんなさい。追加です。
大事なことを書き忘れていました。

基本的にjava以外で作られたモジュールもリバースなどで
解析されることがあるかもしれません。

そこで重要なのがライセンスや使用許諾です。
パッケージとしてJ2EEの warや ear を販売するために、
「逆コンパイルはいけませんよ」などの記述が必ず必要です。

ただし、フリーウェアのコンポーネント(jarなど)を使っているときには
注意が必要です。

GPLのjarファイルとリンクしていると、大変なことになります。

詳しくは ASF, GPL, LGPL などのキーワードでぐぐっていただければわかります。

ちょっと伝えたかったので書きました。

板汚しすみません。
未記入
常連さん
会議室デビュー日: 2005/05/24
投稿数: 48
投稿日時: 2005-06-16 23:43
どもども

まあ思っている事はraystarさんと殆ど同じです。
法律面でセキュアにするのであれば使用許諾書などが有効と思いますよ。
ただ技術的にとなると･･･

引用:
また、難読化後のclassファイルの実行パフォーマンスは元のclassファイルより、落ちるのではないでしょうか。


すいません色々考察してみましたが根拠が不明でした。
よければ教えて下さい。
未記入
常連さん
会議室デビュー日: 2005/05/24
投稿数: 48
投稿日時: 2005-06-17 00:03
どもども
技術面の事記載しわすれましたよ

引用:
class ファイルは難読化できるとおもいますが、
JSPはできないんじゃないですかね。。。（あったら知りたいです）


JSPを事前コンパイル + 難読化 では駄目ですかね？

引用:
ちなみに難読化したclassファイルも逆コンパイル可能です。
「難読化」ですので、読みにくいコードに変換されるからです。
読みにくいだけですので、追っていけば解析することは可能です。


まあ難読化ツールですので限界はありますがパッケージ構成やクラス構成によっては解析にはかなり根気がいりますよ

引用:
また、難読化後のclassファイルの実行パフォーマンスは元のclassファイルより、落ちるのではないでしょうか。


むしろ多くの場合早くなると思いますが･･･
また多くの場合クラスサイズも小さくなります

引用:
例えば、ServletやBeanなどを全部jarにひっくるめて、


mt2mtさんのようにセキュリティを強く意識されているのであれば開発した物一式をJARとする事は妥当だと思います。

引用:
WEB-INF/lib の中に入れてしまえば、
他のJarにまぎれてしまうので、解析しようとした人から見ると
「ん？ドコよんでんの？」ってことになるかもしれません。笑


ProGuardでは依存関係についてもどこまで難読化を行う/行わないなどの設定が可能です。

他によいソフトウェアはないですかね？
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2005-06-17 00:24
引用:

また、難読化後のclassファイルの実行パフォーマンスは元のclassファイルより、
落ちるのではないでしょうか。

難読化後のクラスファイルはメソッド名がgetXXXXX()からa()などに変更になります。
メソッド名はクラスファイルのコンスタントプールに保持されますが、
プールのバイト数が減る分、パフォーマンスはむしろ上がると思います。
(とは言っても、理論上の話で「上がるか」「下がるか」だけの話です。）

あと、JSPの難読化は内部で定義したメソッド郡などでしか駄目でしょうね。
ワークディレクトリの中のクラスに対して行っても、
クラス名の命名規則とJSPのディレクトリを一致させているので
クラス名が変われば実行のパスが変わってしまいますね。

難読化を行うにも基底クラスから作り込めばいいですが、
サーブレットのように基底クラスがある程度決まっていると、
思ったほど難読化されません。
独自の業務ロジッククラス位しか役に立たないと思います。

他の方法としてはクラスを暗号化して、
復元を行うクラスローダでクラスをロードするって方法もありますね。
用意した認証サーバで認証を行わないと、
そのクラスローダが起動しないようにするとか・・・

ただ、ここまで手の込んだことをやるよりも、
素直に使用許諾書で済ませたほうがいいと思います。

引用:

servlet、jspを配布してしまうと容易に解析が可能なので
セキュリティ的に問題があります。

解析されることによって、セキュリティの問題が解決する場合もあります。
セキュリティホールを、「動作・仕様は一切非公開」って方法で塞ぐよりも、
公開して、おかしな部分を指摘してもらった方がいいですよね。
別に配置したファイルをそのサーブレットにアクセスするユーザから
直接見えるわけではないので問題ないと思います。
（もしかして管理者パスワードがオンコーディングとか、
もうすでにSQLインジェクションの脆弱性がわかっているが隠したいとか・・・
そういう意図があるなら別ですが。）

長くなってすいませんでした。。。
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2005-06-17 00:25
「セキュリティ的に問題」とは具体的にどのような懸念でしょうか？
多くの商用製品は例外のスタックトレースなどから判断するに難読化は行っていないように感じます。
また、「コードのリバースエンジニアリングが容易だったことがセキュリティホールにつながった」みたいな話もあまり聞いたことありません。
また、難読を行うと問題が発生した際の例外のスタックトレースやスレッドダンプの確認も困難になりますね。あまりお勧めできません・・・。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）