1

私は同僚と API の開発について話し合っていましたが、次の提案を見て、API の安全性について疑問に思いました。

シナリオ：

サーバー A で実行されている Web アプリケーションがあり、(他の機能に加えて) 管理者ユーザーが任意の URL を指定できるようにし、各 URL に関連するアカウント内のユーザーのセキュリティを許可します。だから基本的に：

URL:"/foo/bar", UserID:1234, AllowedToView:true

管理者ユーザーは、独自の別のサーバー B で独自の Web アプリケーションを実行しています。また、そのサーバー B アプリケーションにログインしているエンド ユーザーが、そのサーバー B アプリケーションの特定の URL にアクセスできるかどうかをチェックする必要があります。サーバー A の API。

このチェックには、次の 2 つの形式があります。

  1. サーバー B から URL を要求するユーザーのコンテキスト内で発生するサーバー側の HTTP 呼び出し (サーバー B からサーバー A へ) は、​​次のようになります。

     User requests "/foo/bar" with their client from server B
 During the processing of that request on server B, it makes an HTTP call to server A to check if that user has access to the requested URL
 With the response from server A, server B can then either allow the user to access or redirect, send 403 access denied, etc.

  2. エンド ユーザーのクライアントからサーバー A に直接送信され、JavaScript で応答を利用する AJAX 要求。ここでは、クロスドメイン スクリプティングの問題が問題になる可能性があります。

すぐに頭に浮かぶ課題の 1 つは、管理者ユーザーが、サーバー B 上の Web アプリにアクセスしているエンド ユーザーを、サーバー上の Web アプリでそのユーザーに関連付けられている UserID に直接関連付ける方法が必要だということです。 A. しかし、それがどういうわけかエレガントに解決されたと仮定しましょう :-D.

私の質問は、このようなシナリオに関連する固有の (内の) セキュリティに関連しています。サーバー A に対して行われている要求 (上記の 1 と 2 の両方) が https で行われている場合、応答の整合性を期待できますか?

4

2 に答える 2

1

サーバー B を本当に保護したい場合は、クライアント側の検証に頼ることはできません。つまり、クライアント側からサーバー A を呼び出してリソースにアクセスできるかどうかを確認する 2 番目のシナリオは、安全な方法ではありません。クライアントが適切に動作することを期待する必要がありますが、これはもちろん攻撃に対して無防備なままです。

最初のシナリオ - サーバーからサーバーへの呼び出しは、安全で推奨される方法です。署名を使用して呼び出しを保護するか、共有シークレット自体を渡して呼び出しの発信元を検証する必要があります (HTTPS を使用)。

とはいえ、クライアントを通過するフローを保護する方法はありますが、クライアントに署名させることができないため (クライアントにシークレットを配置することはできません)、通常はサーバー上でデータに署名する必要があります。

于 2013-08-09T18:49:30.627 に答える
1

HTTPS は、メッセージが中継側 (プロキシなど) によって読み取られたり、改ざんされたりできないようにしますが、データのソースが信頼されていることを保証するものではありません。別のサービスが別の URL とワイヤ形式を特定できる場合、そのサービスへのリクエストを偽装する可能性があります。これは通常、共有秘密署名メカニズムを使用したリクエスト署名のようなものが機能する場所です。Twilio の API は、このメソッドを使用して、実際にサーバーを呼び出していることを証明します。HTTP 署名は、これを行うための標準化された方法の提案です。

于 2013-08-09T17:24:33.900 に答える