3

サーバー上の PHP ファイルへのアクセスを制限したいと考えています。この PHP ファイルは、HTTP GET 要求からデータを取得し、それをファイルに追加します。単純。しかし、私が開発したスマートフォン アプリ内から HTTP リクエストが生成されない限り、この PHP ファイルを実行したくありません。

各ユーザーを個別に認証したくありません。私は自分のアプリだけが PHP ファイルにリクエストを送信できるようにしたいと考えています。私は、同様の形式のリクエスト (http://www.mydomain.com/check.php?string=blahblahblah) をブラウザーに入力して同じ影響を与える人を望んでいません。

HTTP_USER_AGENT やその他の変数をチェックすることを考えましたが、それらも簡単になりすます可能性があるのではないかと心配しています。探しているキーをアプリに埋め込むことはできますが、そのキーも侵害される可能性があります。

次のステップは、サーバーにチャレンジを送信してもらい、それに適切に応答させることです。または、PKI を調べることもできます。しかし、ちょっとした破壊行為を防ぐためだけに、本当に価値のあるものを保護しようとしているわけではないことを考えると、これを行うための比較的簡単な方法は何でしょうか。

ここで車輪を再発明しようとしていますか？これを行うための簡単で実証済みの方法はすでにありますか?

4

7 に答える 7

4

FWIW、これは私が考えることができる最も安全な方法であり、パフォーマンスに深刻な影響を与えることはありません.RESTful（っぽい）方法です.

  • アプリとサーバーには、モバイル アプリの連続する各バージョンに固有の、ハードコードされた同一のソルト文字列があります。この文字列は非公開にする必要があります。
  • ユーザーがデバイスにアプリをインストールすると、アプリはサーバーに接続し、アプリのバージョンとデバイスのIMEIを通知します。これは、使用しているモバイル プラットフォームの API を使用して取得できる必要があります。
  • サーバーは、アプリに送り返されてデバイスに保存されるアプリのそのインスタンスの一意のキーを生成し、IMEI とインストールされているバージョンと共にサーバー側のデータベースに保存します。
  • 日常の操作中 (つまり、質問で概説されている要求を行うとき)、アプリは次の手順に従います。
    • 次の情報を取得します。
      1. デバイス IMEI
      2. アプリキー
      3. アプリ版
      4. ハードコーディングされたソルト文字列
      5. ソルトを追加するためにランダムに生成された文字列 (現在のタイムスタンプをマイクロ秒単位で導出したものは、妥当な量のエントロピーに常に適しています)。
    • これらすべての情報を連結し、できればそれらの間にハードコーディングされたパディングを使用して、結果の文字列のハッシュを生成します。
    • 次の情報を実際のリクエスト データと一緒にサーバーに送信します (セキュリティを強化するために Cookie を使用する場合があります)。
      1. 生成されたハッシュ
      2. アプリキー
      3. 追加のソルトとして使用されるランダムに生成された文字列
  • サーバーはアプリ キーを使用して、そのインスタンスのデバイス IMEI とアプリ バージョンをデータベースから取得し、その情報をバージョン ID のハードコードされたソルト文字列とデバイスから送信された追加のソルト文字列と共に使用して、ハッシュ。サーバーで生成されたハッシュがモバイル デバイスで生成されたハッシュと一致する場合、要求は許可されますが、拒否されません。
  • このプロセスのすべての通信は HTTPS 経由で行われます。

このシステムを突破してリクエストのスプーフィングに成功するには、攻撃者は次のことを知る必要があります。

  1. デバイス IMEI
  2. アプリキー
  3. アプリ版
  4. ハードコードされた塩
  5. ハッシュの生成に使用するメカニズム (入力文字列の正確な形式とハッシュ アルゴリズム)。

モバイル デバイスを使用している場合、明らかに 1 ～ 3 は簡単に抽出できますが、4 と 5 はアプリをリバース エンジニアリングせずに見つけることはできません (知識と忍耐力のある人にとって、これを防ぐためにできることは文字通り何もありません)。やれ）。

中間者攻撃は基本的に不可能です。SSL を突破し (控えめに言っても簡単ではありません)、アプリをリバース エンジニアリングして 4 と 5 を取得した後でも、1-3 は取得できません。ハッシュに対するブルート フォース アタック。これは十分に複雑で、平均して数億年かかることになります (この数字に到達する方法については、このページを参照してください)。特に 3 つのうちの 1 つが可変長である場合は、アプリのバージョン文字列は簡単に指定できます。

于 2012-07-13T09:49:54.710 に答える
3

アプリと php ファイルの両方でソルトを定義し、そのソルトを現在の時刻と組み合わせてハッシュします。それがなりすましになることはまずありません。

$hash = sha1(time() . 'bladieblasalt');

if($_GET['hash'] == sha1(time() . 'samehash'))
{
    echo 'valid';
}
于 2012-07-13T08:53:42.490 に答える
2

ユーザーごとではなく、アプリごとのみが必要な場合は、アプリケーションに組み込まれているシークレットに依存する必要があります。アプリケーションを逆アセンブルした人は最終的にそれを見つけることができるので、難読化が役立つかもしれませんが、決定的な人々をあなたのページから遠ざけることはできません.

とはいえ、公開鍵暗号を使用してもほとんど意味がありません。スプーファーが興味を持っているのはアプリ側であるため、彼らはすでにキー ペアのより価値のある半分にアクセスできます。したがって、共有シークレットを使用したアプローチを使用することもできます。

本当に確認したいのは、転送されたデータの信頼性です。したがって、単純にそのデータのコア (つまり、本当に重要なすべてのフィールド) を取得し、それらを共有シークレットと連結し、結果をハッシュして、メッセージ ダイジェストとして転送します。サーバーは同じ計算を実行し、計算されたダイジェストが転送されたダイジェストと一致することを確認します。存在する場合、そのメッセージの送信者は共有秘密を知っている必要があります。

誰かが有効なメッセージを記録し、それを後で繰り返すなど、リプレイ アタックの可能性はまだあります。サーバー側で正確な重複を検出し、メッセージの署名部分にタイムスタンプを含めることで遅延再生を防ぐことができます。サーバーがクライアントとサーバーのタイムスタンプの大きな違いを許容する場合、重複した情報を同じ時間保持する必要があります。小さな違いしか受け入れない場合は、より小さな重複キャッシュで動作しますが、サーバーが要求が古すぎるとして拒否する可能性が高くなるため、デバイスの構成が正しくないユーザーはイライラする可能性があります。

もう 1 つ注意:GETあるファイルへの書き込みを引き起こす要求について書きました。私は常に、何らかの状態変更操作をPOST代わりに関連付けます。アプリが独自のものである場合は、それほど重要ではありませんが、ブラウザはGETユーザーに確認せずにリクエストを再送信することが知られているため、一部のアクションに対して重複したリクエストが発生します。

于 2012-07-13T22:52:50.000 に答える
2

まず、ssl をアプリに実装する必要があります。それ以外の場合は、ほとんど知識のない人が電話を Wi-Fi に接続し、wireshark または cain と abel ect を使用してアプリとサイトの間のトラフィックを盗聴することができます。URLと渡されたパラメーターを取得します。何も逆アセンブルする必要はありません。

アプリはサイトに接続し、ユーザーがログインします。サーバーがアプリにリクエスト ID を割り当て、このキー/トークンがすべてのリクエストと共に渡され、サーバー上のセッション内で検証されます。

トークンは次のようになります: UNIQUE_REQUEST_ID_ASSIGNED_BY_SERVER:APPsIP:APPsTIMEこの文字列を暗号化し、$_GET['token']

次に、サーバーで文字列と文字列をその部分に復号化explode()し、データベースまたはセッションに対して、リクエスト ID、IP、および時刻が一致することを確認します。

安全なログイン システムと同じように、各ユーザーに一意のソルトを割り当て、それをユーザーの要求 ID と共に保存します。

要するに、悪用者がシステムを悪用しにくくするだけです。99% の人はいじろうとも思わず、残りの 1% の人は IP アドレスがブロックされています。

于 2012-07-13T09:17:52.607 に答える
1

保証方法はありません。oauth認証を使用できます...使用しているプラ​​ットフォームと電話へのアプリの展開方法に応じて、キーをアプリケーション自体にコンパイルできますか? 100% のセキュリティはありませんが、試すことは恥ではありません。:)

個人的に私がモバイルアプリに使用しているのは、有効期限が切れるまでトークンベースの通信と定期的なログイン/パスペアを使用した RESTful 認証です。:)

于 2012-07-13T09:03:02.210 に答える
0

HTTP リクエストは、送信者が希望する方法で 1 文字ずつ作成できます。スプーフィングは常に可能です。

于 2012-07-13T08:51:38.557 に答える
0

認証 (ログイン、パスワード、セッションなど、および/または「API キー」) を PHP アプリケーションに追加するだけで、必要なリクエストを送信する前に電話アプリで認証を行うことができます。スクリプトが単純な場合、スクリプトが煩雑になる可能性があるため、おそらく考慮していませんでしたが、ほとんどすべての Web システムでそれが必要になり、最終的にはそれに直面することになります。

アプリケーションに電話をかけ、HTTPS 経由で PHP アプリにログインして傍受を排除します。

于 2012-07-13T09:02:15.703 に答える