JSON-RPC over TLS (HTTPS) を受け入れる PHP Web サービスを用意するつもりです。すべてのクライアントには、識別目的で使用する API キーがあります。それは十分なセキュリティですか?JSON-RPC セキュリティ固有の標準はありますか?
質問する
2763 次
2 に答える
5
それは物事を行うための素晴らしい方法です。セキュリティ スキームでの要件とコンポーネントの概要は次のとおりです。
チェックリスト
必要なセキュリティと、それに対処する方法のチェックリストを次に示します。
- 第三者があなたの通信を傍受することはできません。HTTPS はこれを提供します。
- 第三者があなたの通信を改ざんすることはできません。HTTPS もこれを提供します。
- クライアントはサーバーを認証できます。HTTPS はこれを提供します (*)。
- サーバーはクライアントを認証できます。
クライアント認証
クライアントを認証する方法はたくさんあります。以下にいくつかの例を示します。
- API キーを使用してリクエストの HMAC を計算し、HMAC をヘッダーとしてリクエストに含めます。(**) 最も安全ですが、設定がより複雑です。主な利点は、サーバーが侵害された場合でも、API キーが公開されないことです。
- リクエストに API キー自体を含めます。設定が簡単で、要件によっては十分なセキュリティである場合があります。
- ...
(*): クライアント ライブラリがある限り。HTTPS では、サイトがドメイン名に対応していることを検証する証明書を使用する必要があります。残念ながら、多くの HTTPS ライブラリはデフォルトでこれを検証しません。
(**): リプレイ アタックを防ぐためにナンスも使用する必要があります。
于 2012-12-28T13:18:56.043 に答える
1
秘密のソルトを使用してリクエストに署名することができます (+ 選択したハッシュアルゴリズム、MD5 で問題ありません)。これは、盗聴者が「API キー」を取得して自分のリクエストを偽造することができないためです。非常に長い塩を使用してください。
また、salt は、盗聴に成功した人によるメッセージの意図的な変更から保護する役割も果たします。
どうして真ん中に男がいるの？TLS(SSL) は、クライアントごとにホワイトリストに登録された証明書を発行しない限り、中間者攻撃に対するセキュリティとしては不十分です。たとえば、中間のサーバー (攻撃者) が有効な証明書を取得するか、クライアント アプリケーションがさまざまな証明書の有効性設定 (有効期限など) を確認していません。管理下にない場合、RPC サーバーのクライアントは、セキュリティ チェックを一切行わずに接続する可能性があります。これは広範囲にわたる問題です。盗聴は通常、あなた (またはあなたのクライアント) のネットワークへのアクセスを意味するため、悪質な DNS トラフィックが不正なサーバーにリダイレクトされることを意味する可能性があります。
あなたまたはあなたのクライアントのネットワーク接続が DNS ポイズニングの可能性を排除するのに十分安全であるか、クライアントが証明書の有効性をチェックしているか、またはクライアントにホワイトリストに登録された SSL 証明書を使用するよう強制しているかどうかは、あなただけが影響を与えたり決定したりできるものです。
重複したリクエストを拒否するために、リクエストごとに一意の番号を割り当てて (これらの API 呼び出しが読み取り専用の場合はやり過ぎになる可能性があります)、リプレイ攻撃を防ぐこともできます。
あなたが言及したAPIキーは、通常、ブラウザ側のJavaScriptクライアントが使用状況を追跡するために関与するときに使用されます. API キーは盗まれたときに再発行され、許可されていないアプリを特定して無効にします (また、さらなる [訴訟] アクションのために不正なドメイン名のリストを自動的に作成する場合もあります)。
于 2012-12-28T12:53:29.017 に答える