6

私のクラスのプライベートメンバー/関数でさえ、を使用してリフレクションによってアクセスできますsetAccessible(true)。外部コードからのこの種のアクセスを防ぐ方法はありますか?

ここで、スタックオーバーフローで、SecurityManagerアプレットでのリフレクションの防止に使用できるものを読みました(ただし、どのように機能するかはわかりません)が、Androidにも同様のメカニズムがありますか? たぶん、注釈または巧妙なプログラミングですか?

4

3 に答える 3

14

一歩下がって、あなたが観察しているのは、Sun の JVM で最初に具現化された Java 実行モデルと Android の実行モデルとの間のセキュリティ哲学の違いです。

オリジナルの Java VM 設計は、相互に疑わしい複数のアプリケーション (Java 用語では「アプレット」) が単一の VM で実行される単一のアドレス空間に同時に存在するシステムを対象としていました。設計者は、あるアプリが別のアプリをいじることができないようにするために、あるオブジェクトが別のクラスの別のオブジェクトのプライベート フィールドに触れることを禁止する VM 内セキュリティ モデルを定義するために多大な労力を費やしました。

とはいえ、Java ライブラリには、セキュリティ モデルからのさまざまな「エスケープ ハッチ」が存在することになりました。お気づきのように、それらの1つはsetAccessible()反射オブジェクトにあります。

Android のモデルは異なります。Android は、プロセスをセキュリティ境界およびアプリケーション分離の単位として使用します。従来の JVM で行われていたように、プロセスにプロセスを挿入しようとするのではありません。これは、アプリケーションが「自分自身からそれを保存する」のに役立つという点を除いて、Java セキュリティ モデル全体を意味のないものにします。つまり、あるオブジェクトが別のオブジェクトの非公開部分に突っ込まないようにするのは良い設計であり、デフォルトの Java セキュリティ モデルはまさにそれを提供します。

コードを変更する人の問題は別として、Android では、アプリの作成者として、アプリのプロセス内で最終的に実行されるすべてのコードを制御します。を呼び出すコードを含めることを選択した場合setAccessible()私には関係ないことだ。プロセスのレイヤーでそのまま実行されている Android セキュリティ モデルは、本質的にそれを起こさせないため、あなたは自分自身を撃つかもしれませんが、他のアプリの足を撃つことはないでしょう。同様に、ネイティブ コードを使用すると、Java オブジェクト モデルから完全に抜け出すことができます。これにより、プロセスが完全に混乱する可能性がありますが、Java よりも生産的な方法でいくつかのことを表現することもできます。これはトレードオフですが、アプリケーション開発者ごとのトレードオフであり、携帯電話やデバイスで起こっている他のことに特に影響を与えるものではありません。

これがあなたの質問に直接答えるものではないことはわかっていますが、有用なコンテキストを提供してくれることを願っています.

于 2012-11-03T19:14:54.760 に答える
1

外部コードからのこの種のアクセスを防ぐ方法はありますか?

あまり。

Androidにも同様のメカニズムがありますか?

存在する場合でも(そしてそのようなものが存在することに気づいていませんが)、コードを逆コンパイルし(ソースがまだない場合)、保護を解除してコードを再コンパイルすることで、誰でもそれを削除できます。

ProGuardを適切に使用すると、本番APKビルドのプライベートクラスとメソッドがわかりにくくなることに注意してください。これに加えて、ドキュメントが不足しているため、誰もがこれらのプライベートクラスやメソッドにアクセスするのが面倒になります。

于 2012-11-03T17:17:19.690 に答える
0

悪意を持ってプロジェクトにリフレクションを使用しているユーザーから本当に 100% 保護できるとは思えません。コードを難読化するなどして、ユーザーがそれを行うのをより困難にすることができますが、難読化されたコードを反映することは可能です。

私は間違っているかもしれませんが、あなたが提案している目的で SecurityManager を使用できるとは思いません。

于 2012-11-03T18:57:36.703 に答える