0

あらゆる場所を検索しましたが、理解できない情報がたくさん見つかりました。私はWAMPサーバーを使用しており、「SELECT name FROM Tablename」クエリを実行して、データをに渡しましたjson_encode()。ここまでの結果は気に入っていますが、今度はサーバー内の JSON ファイルを保護して、Android アプリを実行するユーザーのみがアクセスできるようにする必要があります。

調査の結果、REST が解決策になる可能性があることがわかりましたが、自分の場合にそれを実装する方法がわかりません。サーバー側の REST セキュリティと、クライアント側も同様に持つことは可能ですか? REST が Web サービスであることを理解し、Web サービスが基本的に Web ページであるチュートリアルを読みました。私の優先事項は、サーバー側の json ファイル、セキュリティ、および速度です。ユーザーが Android アプリを介して情報を挿入することはありません。特定のjsonファイル(検証)にユーザーとパスワードを指定してAndroidアプリケーションをデプロイすることを考えていました。

私の申請の流れ

このテーマに関連するビデオ チュートリアルや初心者向けのチュートリアルを教えていただけると助かります。

これが私の具体的な質問ですか?

  • JSON で画像を解析できますか?
  • mysqldump --> .csv ファイルの変換 ---> SQLite の方が効率的ですか? (安全に)。
  • データベースに 100 万個のエントリがある場合、.CSV ファイルはどのくらいの大きさになりますか?
  • どうすればこれをすべて達成できますか?

助けてください、ありがとう。

4

2 に答える 2

0

解決策: HTTP ヘッダーを使用する

安全でない解決策:

User-Agent ヘッダーを使用します。

User-Agent: MyAndroidApp/1.0

より安全なソリューション:

まず、SSL を使用する必要があります。これにより、秘密鍵が簡単に見られることはありません。

次に、Android アプリから行うリクエストの HTTP ヘッダーに秘密鍵を入れることができます。

X-Android-Secret-Key: fee400be-7d08-45c5-bf7c-ff79c35a838c

サーバー上のヘッダーをチェックし、目的のヘッダーが受信された場合にのみファイルを返します。ヘッダーをある程度秘密に保ちますが、SSL で侵入できないわけではありません。

于 2012-04-16T01:06:11.577 に答える
0

アプリ認証に関する最初の質問にのみ答えるつもりです。他の質問は別の質問として属します。

クライアントとサーバーのみの場合は、何も購入せずに相互認証 SSL を使用できます (使用する必要があります)。サーバーとクライアントを制御するため、それぞれが 1 つの証明書のみを信頼する必要があり、一方は他方に属しており、この目的のために CA は必要ありません。

これが高レベルのアプローチです。自己署名サーバー SSL 証明書を作成し、Web サーバーにデプロイします。この目的のために、Android SDK に含まれている keytool を使用できます。次に、自己署名クライアントを作成し、それをアプリケーション内にリソースとして含まれるカスタム キーストアにデプロイします (keytool はこれも生成します)。クライアント側の SSL 認証を要求し、生成したクライアント証明書のみを受け入れるようにサーバーを構成します。そのクライアント側の証明書を使用してそれ自体を識別し、その部分についてサーバーにインストールした 1 つのサーバー側の証明書のみを受け入れるようにクライアントを構成します。

これに対する段階的な回答は、ここで保証されているよりもはるかに長い回答です。サーバー側とクライアント側の両方で、Android で自己署名 SSL 証明書を処理する方法に関するリソースがウェブ上にあるため、これを段階的に行うことをお勧めします。O'Reilly から出版された私の著書、Application Security for the Android Platform にも完全なウォークスルーがあります。

通常、その証明書/秘密鍵を何らかのタイプのキーストア (Android を使用している場合はキーストア) に保存し、そのキーストアは暗号化されます。その暗号化はパスワードに基づいているため、(1) そのパスワードをクライアントのどこかに保存するか、(2) ユーザーがクライアント アプリを起動するときにパスワードを尋ねる必要があります。何をする必要があるかは、ユースケースによって異なります。(2) が受け入れられる場合、認証情報は暗号化され、パスワードはどこにも保存されないため、リバース エンジニアリングから保護されています (ただし、ユーザーは毎回パスワードを入力する必要があります)。(1) を行うと、誰かがクライアントをリバース エンジニアリングし、パスワードを取得し、キーストアを取得し、秘密鍵と証明書を復号化し、サーバーに接続できる別のクライアントを作成できるようになります。

これを防ぐためにできることは何もありません。コードのリバース エンジニアリングを (難読化などによって) 難しくすることはできますが、不可能にすることはできません。これらのアプローチで軽減しようとしているリスクが何であり、それを軽減するためにどれだけの作業を行う価値があるかを判断する必要があります。

于 2012-04-16T12:03:30.593 に答える