21

いくつかのUIDで識別できるクライアントアプリがあります。いくつかのリストを取得するためにクライアントアプリが呼び出す必要のあるバックエンドサービスがあります。このバックエンドサービスを保護するためのベストプラクティスは何でしょうか。ログイン/パスワードで保護したくない(クライアントがリストを取得するために「ログイン」する必要がないため)、ただし、誰もがこのバックエンドAPIを簡単に呼び出して、自分の目的でそれらのリストを取得することは望ましくありません。 。クライアントをカスタムFlashクライアントやモバイルクライアントなどと考えてください。通信はHTTPRESTを介して行われます。何か案は?

ありがとう

更新:申し訳ありませんが、SSLを使用せずに言及するのを忘れました。基本的に私はここでいくつかのアルゴリズム/戦略のアイデアを探しています。提案ありがとうございます!

4

3 に答える 3

5

ここでの一般的な考え方は、API プロバイダーが他の安全な方法で発行した X.509 証明書を使用してリクエストに署名するように構成されたクライアントで HTTPS を使用することです。サーバーはこの証明書 (またはクライアントの証明書が子である証明書) も持っており、着信要求がそれを使用して署名されたことを確認できます。これは、サーバー間通信のかなり標準的なものです。エンド ユーザーがローカルで実行するアプリを構築している場合、悪意のある人物がクライアント アプリからこの証明書を簡単に抽出し、スキーム全体を破ることができるため、これは機能しません。

これを構成する方法については、テクノロジー固有の記事がたくさんありますが、使用しているスタックを指定していませんが、ここでは、私がこのようなものを作成していないことを証明するための一般的な記事を示します :) http://www. ibm.com/developerworks/lotus/library/ls-SSL_client_authentication/

于 2012-07-03T04:05:40.347 に答える
2

こんにちは、この記事をご覧いただけると思います。hmac 認証を使用しています。http://bitoftech.net/2014/12/15/secure-asp-net-web-api-using-api-key-authentication-hmac-authentication/

ハッシュを使用して整合性を保証できることを覚えていますか?たとえば、リクエストをハッシュし、サーバーがリクエストとハッシュ ダイジェストを受信した場合、サーバーはリクエストをハッシュし、サーバーとクライアントの両方のリクエストを比較します。それらが一致する場合、リクエストがトランジションで変更されていないことを確認できます。プライベートな値 (誰も知らないはずです!)、たとえば "hiworld" (値は実際には GUID またはランダム値です) を持っていて、その値をハッシュのパラメーターとして使用すると、特別なハッシュ値が得られます。ハッシュの特別な値に沿ってリクエストを送信し、サーバー (プライベート値を知っている) がその特別な値を使用してリクエストをハッシュし、両方のハッシュ ダイジェストが一致する場合、サーバーはリクエストが改ざんされていないことを確認できます。送信者でした。

于 2017-02-06T05:47:25.697 に答える
0

承認のために OAuth を確認する必要があります。また、接続は常に HTTPS である必要があるため、パケットを簡単に盗聴することはできません。

認証なしでこれを使用することは、だれでも有効なクライアントになりすまそうとする可能性があるため、かなり安全ではありません。HTTPS に接続しても、ハッカーの速度が低下するだけです。

見る:

http://oauth.net

http://en.wikipedia.org/wiki/OAuth

http://library.edgecase.com/securing-apis-using-rack-middleware (Rails / Rack 用)

http://developers.sun.com/identity/reference/techart/restwebservices.html

http://www.slideshare.net/mohangk/securing-your-web-api-with-oauth

これも興味深いかもしれません: (OAuth なし)。

于 2012-07-03T04:02:43.480 に答える