2017-12-10 5 views
1

おはよう、Android App Obfuscation(ウェブサーバー - Pinging |取得するデータ(MySQL))

私はAndroidアプリに関連して質問があります。私は自分のデータベースにプレーヤーの統計情報を追加したいと思います。問題は、私は自分のソースコードでパスワードを与える必要があり、それは問題です!人々は自分のアプリケーションを逆コンパイルすることができ、データベースに接続して物事を変えることができます。

私は自分のプラグインを難読化したい。だから私はProGuardsを使うことに決めました。ここで2番目の問題があります:ProguardはStringsを難読化していません。また、もし私がStringer/ZKMを買うならば。これを解消するために多くの解読者がいます。 アプリを保護する方法がわかりません。

私は自分自身を暗号化できましたが、一度は復号化され、もう何も安全ではありません。

さらに、PHPポストも安全ではありません。人々はまだそれを操作することができます。

私はそれを修正するために何ができますか?

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

敬具

+0

できません。あなたのMySQLパスワードは常に入手可能です。あなたのアプリとデータベースの間にレイヤーを作成します。いくつかのタイプのレストサービスはstats jsonを返します。または、データベースユーザーを作成し、読み取り専用の 'stats'テーブルのみを与え、このユーザーをappで使用します。 – Bedla

+0

@Bedlaどのように他の開発者がそれをやっている?私が読み取り専用を行う場合、私はサーバーに統計を追加することができません。そして、私が望むのであれば、他の開発者がレイヤーを操作できると思います。 – ExampleGuy12

+1

一般的なアプローチは、サーバーにサービスを追加することです。ユーザーの登録中に、具体的なユーザーに関連付けられた認可トークンを生成し、それを返し、それをアプリケーションストレージおよびデータベースに保存します。永続化と統計取得中に、要求ごとにこの認証トークンを送信し、サーバー側では、現在の許可トークン(ユーザー)に関連付けられたリソースにのみアクセスを許可します。 – Bedla

答えて

1

アプリのユーザーは、IDのいくつかの並べ替え(おそらく電子メールとパスワードを?)持っているあなたのアプリからユーザーを識別するためにすることを使用し、そのユーザーのトークン(通常はGUID)をフェッチと仮定すると、 。トークンとその有効性ステータスをDBに記録しておくと、ユーザーが自分の統計情報を投稿または取得しようとしたときにチェックすることができます。トークンが一定期間だけ有効であるように指定できるため、トークンが期限切れになった後にユーザーが再度パスワードを入力する必要があります。セキュリティを高めるために、あなたはそれぞれの特定の要求のために新しいトークンを必要とする可能性がある(つまり、それが関連懸念であることを起こる場合は、リプレイ攻撃から守る必要がありますか?)

今、あなたはアプリでトークンを維持し、投稿することができますユーザーがあなたのDBと通信したいときはいつでも、統計と一緒にそれを保存します。これは、POST経由で行うことができます。 Phpページ(またはGET URL経由でデータを取得する)この方法では、リクエストが正しく識別されたユーザーから送信されていることがかなり確実になります(少なくとも、HTTPSを使用している場合は、これをやりなおす必要があります)。これを行うためのあなたのサービスは、明らかに、特定の(そして特定された!)ユーザーの統計を格納し取り出すために最低限必要なロジックを提供するだけです。

さらにPHPのポストも安全ではありません。人々はまだそれを操作 にできるようにしている。は」

は、私はあなたがここに欲しいものを想定し、偽の投稿からユーザーを停止することですあなたのアプリの外からの統計。

要するに、あなたが求めているのは、ユーザーがAPIにアクセスする方法であり、同時にそのAPIへのアクセスを拒否しているので、これを安全に行う方法はありません。矛盾。それが面倒のあまり、ほとんどの人はそう気にするために迂回するようにするセキュリティ関連のロジックを不明瞭:

は、ここでは、何ができるかです。

これは、アプリにキー値を含めることで(やはりGUIDはこのトリックを行う必要があります)、このキーのハッシュ+各リクエストとともに渡されるユーザーのトークンを必要とします。あなたは

  • によってキー
  • は別々のリクエストにキーをフェッチし、すべての今、それを更新しアクセスするためのアプリケーションをコンパイルするために、ユーザが必要となるアプリにハードコーディングキーを、この操作を行う可能性があり、次に。これは、ユーザーがコードを逆コンパイルすることで見つけることができないことを意味しますが、アプリが行うのと同じように、コードを取得するための要求を再生することによって実現できます。
  • 上記の2つの組み合わせ。

あなたが追加できるもう一つの障害ブロックは、リクエストを送信しているユーザーエージェントのチェックを含めることです。ユーザエージェントがあなたのアプリケーションのものと一致する場合にのみリクエストが受け入れられるようにするならば、それはブラウザや他のアプリケーションからのリクエストをフィルタリングする必要があります。独自のヘッダーを追加してこれをさらに制限する可能性を検討することもできます。

これは実際には、偽のリクエストを作成してデータベースに到達させるためにユーザーが飛び越えなければならない「フープ」をいくつか作成することです。あなたがそれらのために作るより多くの面倒になるほど、彼らはおそらくそれほど気にならないでしょう。残念なことに、これはまた、アプリを作成して(そしておそらくは維持している)、開発者としてあなたにとってもっと面倒なことを意味し、動機付けられた攻撃者はおそらく入ることができるでしょう。

このような現象が発生し、リソースがある場合は、ユーザーをより明示的に識別するためのより良い方法を探すことができます(匿名のままにできない場合、人々はひどく振る舞いにくい)。異常の要求と統計をスキャンすることもできます。完全に非現実的な統計が掲載されている場合は、単に投稿ユーザーをブロックすることができます。

結局のところ、これは潜在的な攻撃者のために作成する必要があると感じるトラブルの量と、そうするために放棄したい仕事とリソースの量のバランスをとっています。

関連する問題