安全なiPhoneアプリ↔サーバー通信

iOSアプリとそのサーバーコンポーネント間のプライベート通信を達成するための最良のアプローチは何でしょうか？単一の不変の「秘密鍵」がアプリのソースに十分に焼き付けられていますか、またはそのような「ハンドシェイク」鍵の世代を何らかの形で動的に設定する必要がありますか？

サーバー自体には機密データへのアクセス権がないため、ユーザーがプライベートエンドポイントにヒットしても、どこにもアクセスできませんが、それらはパブリックから非表示にしたいだけです。基本的に、iOSアプリからの要求でない限り、特定のルートにヒットするすべてのリクエストを無視します。

サーバーコンポーネントは、重要な場合はRoRで実行されます。

すべての顧客に個別に取り消すことができる秘密鍵を提供しない限り、接続を効果的に拒否することはできません。しかし、これはおそらく過剰です。ほとんどの人が気に弾丸を発射することを気にしない場合、防弾ソリューションは必要ありません。

これはセキュリティの質問なので、脅威モデルと緩和戦略について説明しましょう。

目に見えるコスト（処理コストなど）が発生する可能性があるURLヒットがあり、単純なDoS攻撃と模倣アプリの両方から保護したいとします。

SSLを使用して、接続が簡単に分析されないようにします。要求のコストのかかる部分を行う前に、obviuos以外のポート番号、リダイレクトシーケンス、Cookie交換を使用して接続を少し複雑にします。アプリに組み込まれたシークレットコードを使用して、接続を受け入れる必要があることをサーバーに通知します。

誰かが単にパケットスニファーを実行したり、コード内のURLのような文字列を見たりするだけでは、ヒットする高価なURLを知ることができません。潜在的な攻撃者は、アプリを逆コンパイルする必要があります。

コードを逆コンパイルおよび/またはデバッガーの下で実行されることから実際に保護することはできません。攻撃者は最終的に秘密鍵と接続シーケンスを学習します。

コストのかかるURLで不正なリクエストを受信し始めていることに気付きます：攻撃の形式、または実行するためにサービスにアクセスする必要がある模倣アプリの形式、または悪用コードが公開されている可能性があります。ただし、不正なリクエストを正当なリクエストと区別することはできません。

別の秘密鍵を使用して、アプリに無料のマイナーアップデートを作成します。侵害された高価なURLと同じデータを提供する、別の高価なURLにヒットするはずです。しばらくの間、両方のURLにアクセスできるようにします。

更新されたバージョンへのユーザーベースの切り替えを確認してください。侵害されたコストのかかるURLを調整し、最終的に404にします。セキュリティ侵害を軽減しました。うまくいけば、多くを失うことはありません。振り出しに戻って。

免責事項：私はセキュリティの専門家ではありません。

あなたは持っている古典的な問題は本当に解決することはできません。

シンプルなプライバシーを確保する（つまり、データが転送中にスヌープまたは変更されないようにする）ために、SSLを介してすべてを実行し、iPhoneが認識するCAによって適切に発行された証明書をサーバーに与えることができます。

ただし、承認については、アプリ以外がAPIにアクセスできないことを100％保証する優れたソリューションはありません。以下を除いて、提案されたソリューションは機能します。

• あなたのアプリをダウンロードした人は誰でも必然的に秘密鍵を持っています
• 彼らがなんとかしてあなたのアプリをアンパッケージし、それを逆コンパイルするなら、彼らは平文の秘密鍵を持っているでしょう
• プレーンテキストの秘密キーを取得したら、それを使用して自分の悪意のある要求に署名できます。

これを回避する方法はありません。そのアプローチを採用できなかったと言っているわけではありませんが、絶対確実ではないことを理解してください。DRMが完全に無効になるのはこの問題です。

これがTLSとSSLの目的です。どちらも、固定秘密鍵を必要とせずに安全な接続を作成できます。リンクされたページの説明セクションを読んで、これを行う方法を学んでください。

多くの作業を行わずにTLS / SSLの利点を得る効果的な方法は、クライアントがHTTPSプロトコルを使用してアクセスするWebサービスをサーバーに実装させることです。HTTPSは安全な接続を介した単なるHTTPであり、iOSのURLローディングシステムはそれを実装します。