9

これが私の要件です:

  • 私が開発しているすべてのモバイルアプリケーションで使用可能

私はモバイルアプリケーションを開発しているので、あらゆるセキュリティ戦略を実装できます。

  • 従来のHTTPキャッシュ戦略を使用してキャッシュ可能

私は非常に基本的な構成でVarnishを使用していますが、うまく機能します

  • 公開されていません

人々が私のAPIを利用できるようにしたくない

私が考える解決策:

  • HTTPSを使用しますが、アプリケーションからのプロキシリクエストには、使用されているAPI KEYが表示されるため、最後の要件はカバーされていません。

これを行う可能性はありますか?たとえば、秘密鍵/公開鍵のようなものを使用しますか?

これは、HTTP、Apache、およびVarnishによく適合します。

4

3 に答える 3

15

ネットワークリンクのもう一方の端がアプリケーションであることを確認する方法はありません。これは解決可能な問題ではありません。証明書、キー、シークレットなどで物事を難読化できます。ただし、エンドユーザーはアプリケーションにアクセスできるため、これらはすべてリバースエンジニアリングできます。証明書などの少しわかりにくいものを使用してもかまいませんが、安全にすることはできません。サーバーは、サーバーに接続している人が敵対的であると想定し、それに応じて動作する必要があります。

ユーザーはアカウントを持つことができるため、ユーザーを認証することができます。したがって、有効なユーザーのみがサービスを使用できるようにすることができます。ただし、アプリケーションのみを使用することを保証することはできません。現在のアーキテクチャでそれが必要な場合は、再設計する必要があります。これは解決できず、一般的なモバイルプラットフォームでは解決できないことは間違いありません。

スマートカードなどの安全なハードウェアを統合できる場合は、セキュリティを向上させることができます。これにより、相手側の人間が実際に顧客であることがより確実になりますが、それでもアプリケーションが保証されるわけではありません。サーバーに接続しているのは、接続しているアプリケーションでスマートカードを使用できる場合のみです。

このテーマの詳細については、iPhoneアプリのWebページへのセキュアhttps暗号化を参照してください。

于 2012-11-20T17:39:20.110 に答える
3

確かに、シークレットを保存するためにハードウェアの安全な要素を使用しない限り、APIがクライアントによってのみ消費されることを保証する方法は基本的にありません(これは、自分の電話を最初から作成することを意味しますが、外部デバイスはすべての非ユーザーによって使用される可能性があります公式クライアントアプリも)APIを隠すためにできるかなり効果的なことがいくつかあります。まず、HTTPSを使用します。これは当然のことです。ただし、ここで重要なのは、アプリで証明書のピン留めを行うことです。証明書の固定は、接続しようとしているHTTPSサーバーの有効な公開鍵証明書を保存する手法です。次に、すべての接続で、それがHTTPS接続であることを検証し(ダウングレード攻撃を受け入れない)、さらに重要なことに、それがまったく同じ証明書であることを検証します。このようにして、パス内のネットワークデバイスが中間者攻撃を実行するのを防ぎ、サーバーとの会話で誰もリッスンしていないことを確認します。これを実行し、APIのパラメーターの一般的な設計をアプリケーションに格納する方法について少し賢くすることで(コードの難読化、特に文字列定数を難読化する方法を参照)、サーバーと通信しているのは自分だけであると確信できます。もちろん、セキュリティは、誰かがあなたのものにどれほどひどく侵入したいかの関数にすぎません。これを行うことで、経験豊富なリバースエンジニアが、ソースコードを逆コンパイルして、探しているものを見つけるために時間を割いて(そしておそらく成功するために)時間を割くことができます。しかし、これをすべて実行すると、バイナリを確認する必要があります。これは、中間者攻撃で男性を実行するよりも数桁難しいことです。これは、リークされた画像の最新のスナップチャットの騒ぎに関連していることで有名です。スナップチャット用のサードパーティクライアントが存在し、中間者攻撃の際にトラフィックを監視するスニファを使用して、APIをリバースエンジニアリングすることで作成されました。snapchatアプリの開発者が賢明だったとしたら、証明書をアプリに固定して、話しているのがsnapchatのサーバーであることを絶対に保証し、ハッカーはバイナリを検査する必要があります。これはおそらくはるかに面倒な作業です。関係する努力を考えると、実行されなかったでしょう。これらは、中間者攻撃の際にトラフィックを監視するスニファを使用して、APIをリバースエンジニアリングすることによって作成されました。snapchatアプリの開発者が賢明だったとしたら、証明書をアプリに固定して、話しているのがsnapchatのサーバーであることを絶対に保証し、ハッカーはバイナリを検査する必要があります。これはおそらくはるかに面倒な作業です。関係する努力を考えると、実行されなかったでしょう。これらは、中間者攻撃の際にトラフィックを監視するスニファを使用して、APIをリバースエンジニアリングすることによって作成されました。snapchatアプリの開発者が賢明だったとしたら、証明書をアプリに固定して、話しているのがsnapchatのサーバーであることを絶対に保証し、ハッカーはバイナリを検査する必要があります。これはおそらくはるかに面倒な作業です。関係する努力を考えると、実行されなかったでしょう。

于 2014-10-13T16:42:08.957 に答える
1

HTTPSを使用し、許可されたユーザーにキーを割り当てます。このキーは、リクエストごとに送信され、検証されます。

また、HMACハッシュを使用します。

このHMACをよく読んでください: http ://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

于 2014-10-13T16:49:03.387 に答える