web-dev-qa-db-ja.com

このセキュリティモデルにREST Webサービス？

私はREST認証を必要とするWebサービスを設計しました。これは、Amazon Webサービスと同様の方法で認証を処理します。つまり、ユーザーはACCESS_KEY（たとえば、 'abcd'）を持っています）およびSECRET_KEY（たとえば、 'aabbcc'）。SECRET_KEYは、リクエスト情報を使用してTOKEN：SHA-1を作成するために使用されます。次に例を示します。

GET path HTTP/1.1
Date: Mon, 23 May 2005 22:38:34 GMT
ACCESS_KEY: abcd
TOKEN: SHA1(SECRET_KEY + ACCESS_KEY + Date + path)

サーバーのTOKENを確認して、リクエストを認証できます。ここまでは、セキュリティモデルに問題はないと思います。

私の唯一の質問は、Webページからサービスを使用するときにSECRET_KEYを提供する方法です。私はそれをJavaScript変数（接続はHTTPS）として送信し、適切なヘッダーをすべてのHTTPRequestに追加するJavaScript関数でその変数を単に使用できると考えました。初期認証は、標準のCookieベースのアプローチを使用して実行できます（たとえば、Djangoを使用してセッションを処理する）。

したがって、アーキテクチャは次のようになります。

  • Webサイトセッション：Djangoによって処理され、標準のセッションベースのセキュリティを使用（example.com）
  • Webサイトセッションは、HTTPSを介してSECRET_KEYをJavaScriptグローバル変数として受け取ります。これは、すべてのHTTPRequestに適切なヘッダーを追加するために使用されます。
  • HTTPRequestsはapi.example.comに変換されます。これは、Djangoセッションには気づかれません。適切なヘッダーがあるかどうかだけが重要です。

完全にステートレスなREST APIを維持しながら、このアプローチは安全だと思います。標準のHTTP認証（基本認証またはダイジェスト認証）は使用しません。 "問題。APIを厳密にRESTにしたいと考えています。

このアプローチについて何かコメントはありますか？欠陥がある場合、どのように私の目標を達成しますか？

ありがとうございました！

appsecauthenticationweb-servicerest
9
Escualo

欠陥は見当たりませんが、あなたはそれをやりすぎていると思います。私には何かが欠けているかもしれません-正当な理由があるからではなく、あなたがそうすべきだと思うからトークンを使うのです。

最善のアプローチは、まず（セキュリティ）要件を特定し、次にソリューションを探すことです。

ステートレスAPIについて考える必要があることの1つは、リプレイ攻撃です。それを説明すると、プロトコルは再生攻撃に対して脆弱であるように聞こえます。さらに、各リクエストにランダム性がないため、CSRFに悪用される可能性があります。これがREST APIで修正できるものかどうかはわかりません。これは、Webアプリケーションに固有の問題であるため、検討する価値があります。

結論として、セキュリティ要件（および脅威の状況）がない場合、セキュリティが大丈夫かどうかを誰も評価できません。

8
Henri

私はあなたがちょうどhttpsに固執するべきだと思います。主要な部分がクライアント側のJavaScript（たとえば、トークンのsha1）で生成されている場合、攻撃者がサイトの偽バージョンに攻撃者を誘導するMITM攻撃はどれほど難しいでしょうか。サーバーへの秘密鍵？ （たとえば、DNSを変更し、公共のwifiホットスポットでサイトを偽装します。）

また、日付を生成しているのは誰ですか（クライアントまたはサーバー）？トークンはどのくらい有効ですか？ 2分前に生成/検証されたトークンはまだ有効ですか？ MITMが有効なトークンを傍受して特定のリクエストを実行し、それを再生することはできますか？

6
dr jimbob