233

バックグラウンド：

RESTWebサービスの認証スキームを設計しています。これは「本当に」安全である必要はありません（それはより個人的なプロジェクトです）が、私はそれを運動/学習体験として可能な限り安全にしたいです。面倒なことや、ほとんどの場合、SSLを設定する費用がかからないので、SSLを使用したくありません。

これらのSOの質問は、私が始めるのに特に役立ちました。

私はAmazonS3の認証の簡略化されたバージョンを使用することを考えています（私はOAuthが好きですが、それは私のニーズには複雑すぎるようです）。リプレイ攻撃を防ぐために、サーバーから提供されたランダムに生成されたナンスをリクエストに追加しています。

質問に答えるには：

S3とOAuthはどちらも、いくつかの選択されたヘッダーとともにリクエストURLに署名することに依存しています。どちらも、 POSTまたはPUTリクエストのリクエスト本文に署名しません。これは、URLとヘッダーを保持し、リクエストの本文を攻撃者が必要とするデータに置き換える中間者攻撃に対して脆弱ではありませんか？

署名される文字列にリクエスト本文のハッシュを含めることで、これを防ぐことができるようです。これは安全ですか？

4

6 に答える 6

171

以前の回答では、データ転送のコンテキストで SSL について言及しただけで、実際には認証については触れていませんでした。

REST API クライアントを安全に認証することについて本当に質問しています。TLS クライアント認証を使用していない限り、SSLだけでは REST API の有効な認証メカニズムにはなりません。クライアント認証なしの SSL はサーバーのみを認証します。これは、ほとんどの REST API には関係ありません。実際にはクライアントを認証する必要があるからです。

TLS クライアント認証を使用しない場合は、ダイジェスト ベースの認証スキーム (Amazon Web Service のカスタム スキームなど)、OAuth 1.0a、または HTTP Basic 認証 (ただし SSL のみ) などを使用する必要があります。

これらのスキームは、要求が予期された誰かによって送信されたことを認証します。TLS (SSL) (クライアント認証なし) により、ネットワーク経由で送信されるデータが改ざんされないことが保証されます。それらは別個の、しかし補完的な懸念事項です。

興味のある方のために、 HTTP 認証スキームとその仕組みに関する SO の質問を拡大しました。

于 2012-05-11T19:47:08.407 に答える
60

REST は Web の標準に対応することを意味し、Web での「安全な」転送の標準は SSL です。それ以外のものは、一種のファンキーであり、暗号化ライブラリを利用できるようにする必要があるクライアントに追加の展開作業が必要になります。

SSL にコミットすると、原則として、認証に特別なことは何も必要ありません。ここでも Web 標準を使用し、HTTP 基本認証 (各要求と共に送信されるユーザー名とシークレット トークン) を使用できます。これは、精巧な署名プロトコルよりもはるかに単純であり、安全な接続のコンテキストでも有効であるためです。パスワードがプレーンテキストを超えないようにする必要があるだけです。そのため、プレーン テキスト接続でパスワードを受け取った場合は、パスワードを無効にして開発者にメールを送ることもできます。また、通常のパスワードをログに記録しないのと同様に、受信時に資格情報がどこにも記録されないようにする必要があります。

HTTP ダイジェストは、シークレット トークンが渡されないようにするため、より安全なアプローチです。代わりに、サーバーが相手側で検証できるハッシュです。ただし、上記の予防措置を講じていれば、機密性の低いアプリケーションではやり過ぎかもしれません。結局のところ、ユーザーのパスワードはログイン時にプレーンテキストで送信されており (ブラウザで高度な JavaScript 暗号化を行っている場合を除く)、同様に各リクエストで Cookie が送信されます。

API を使用する場合、開発者が Web サイトにログインする際に使用するパスワードではなく、クライアントがトークン (ランダムに生成された文字列) を渡す方がよいことに注意してください。そのため、開発者はサイトにログインして、API 検証に使用できる新しいトークンを生成できる必要があります。

トークンを使用する主な理由は、パスワードが侵害された場合にトークンを置き換えることができるためです。一方、パスワードが侵害された場合、所有者は開発者のアカウントにログインして、好きなことを行うことができます。トークンのさらなる利点は、同じ開発者に複数のトークンを発行できることです。おそらく、複数のアプリを持っているか、異なるアクセス レベルのトークンが必要なためです。

(接続を SSL のみにすることの意味をカバーするために更新されました。)

于 2009-01-28T20:57:33.903 に答える
8

または、この問題に対する既知の解決策を使用して、SSL を使用することもできます。自己署名証明書は無料で、個人的なプロジェクトですよね?

于 2009-01-28T13:52:06.710 に答える
5

URL のパラメーターの 1 つとして本文のハッシュが必要であり、その URL が秘密鍵を介して署名されている場合、中間者攻撃は、本文を生成するコンテンツにのみ置き換えることができます。同じハッシュ。少なくとも現在は MD5 ハッシュ値を使用するのは簡単で、SHA-1 が壊れている場合は、全体像がわかります。

ボディを改ざんから保護するには、ボディの署名を要求する必要があります。中間者攻撃は、署名を生成する秘密鍵を知らないため、解読される可能性が低くなります。 .

于 2009-01-28T06:37:07.480 に答える
3

実際、元の S3 認証では、弱い MD5 署名ではありますが、コンテンツの署名が許可されています。HMAC (署名する文字列) に Content-MD5 ヘッダーを含めるオプションのプラクティスを単純に強制できます。

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

彼らの新しい v4 認証スキームはより安全です。

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

于 2013-03-10T06:52:52.567 に答える
1

あなたの提案により、クライアントがサーバーと通信することが難しくなることを忘れないでください。彼らはあなたの革新的なソリューションを理解し、それに応じてデータを暗号化する必要があります。このモデルはパブリック API には適していません (amazon\yahoo\google.. でない限り)。

とにかく、本文コンテンツを暗号化する必要がある場合は、次のような既存の標準とソリューションを確認することをお勧めします。

XML 暗号化 (W3C 標準)

XML セキュリティ

于 2009-01-18T21:36:47.927 に答える