2

この質問には正確な状況があります: csrf 保護と RESTful API を組み合わせるための実行可能な手法は何ですか?

与えられた1つの答えは、使用について話します

  • SSL による基本認証
  • アプリケーションごとに 1 つの API キー
  • OAuth

アプリごとに access_token、client_id、client_secret を持つ OAuth2.0 を実装することについて、私はすでに確信しています。

しかし、これが実際に CSRF の防止に役立つとは知りませんでした。

私の意見では、結局のところ、ssl はまだ必要です。

OAuth2.0 では、クライアント アプリがリソース オーナーに代わってリクエストを送信する場合、client_id、client_secret、アクセス トークンなどのデータ パラメーターと一緒に送信する必要があるためです。

HTTPS を使用しない場合、client_id、client_secret、およびアクセス トークンがリークまたは中間者によって知られている場合、アクセス トークンの有効期限があるため、小さなものではありますが、CSRF の可能性は依然としてあります。

私の理解は正しいですか?

4

1 に答える 1

2

リソースがOAuth2のみで保護されており、攻撃者がclient_id、client_secret、およびアクセストークンを取得した場合、CSRFはまったく必要ありません。攻撃者は、保護されたリソースを使用するリクエストを直接送信できます。OAuth2はリクエストのソースをフィルタリングせず、アクセストークンのみを必要とするため、サービスが提供されます。

一般に、man-in-the-middle攻撃を回避するために、認証サーバーと保護されたリソースの両方にHTTPSを確実に使用する必要があります。ただし、「認証コードの付与」シナリオを使用している場合(つまり、独自のWebアプリケーションから使用している場合)、リソース所有者はアクセストークンを認識できず、認証コードのみを傍受できます。したがって、Webアプリケーションが認証サーバーと保護されたリソースの両方への信頼できる(イントラネットなどの)接続を持っている場合、保護されたリソースへの暗号化されていない接続を使用しても安全です。

于 2012-06-13T11:05:58.167 に答える