web-dev-qa-db-ja.com

Cookie認証を使用するSSR SPAでCSRFは可能ですか？

私は単一ページアプリケーションを持っています。これは、基本的にはAuthorizationヘッダーを使用して認証する私のAPIのコンシューマーです。ここで、サーバー側レンダリングを行うため、最初のリクエストで認証する必要があります。つまり、認証トークンを格納するためにCookieを使用する必要があります。

私が理解している限り、CSRFは一般的なWebサイトでは次のように機能します：

  • Cookieで認証する/delete-accountなどの有害な処理を行うエンドポイントを見つけます
  • example.comに、<img href="http://mywebsite.com/delete-account">（またはPOSTリクエストの場合は何でも）を入れます）

しかし、私には、SPAの場合、認証トークンがcookieとして送信されても​​、CSRF攻撃が発生することは不可能のようです。通常の手順は次のようなものです。

  • ユーザーがページにアクセスする、たとえば/account
  • サーバーは認証されたユーザーごとにページをレンダリングします（認証Cookieが与えられます）
  • Webページが返されます
  • ユーザーが自分のアカウントを削除したい場合、ボタンを押すことができます。これにより、Authorizationヘッダーのみでリクエストを認証するリクエストがAPIに送信されます。

現在、CSRF攻撃では：

  • <img href="/account">
  • サーバーがWebページをレンダリングして返す
  • ええと、何も起こりませんか？

つまり、認証にCookieを使用していても、CSRF攻撃はWebページからデータをこすり落とすことができないため、機密情報を返すことはできません。アクションをトリガーしない限り、データは重要ではありません。

だから私の質問は、この場合はいかなる種類のCSRF保護も実装しないことは問題ないのですか？それに関してセキュリティの問題があるのをとても恐れています。

web-applicationcookiescsrfsingle-page-app
5
OverCoder

ユーザーが自分のアカウントを削除したい場合、ボタンを押すことができます。これにより、Authorizationヘッダーのみでリクエストを認証するリクエストがAPIに送信されます。

最終的には、何らかの方法で認証する必要があるアクションを実行するリクエストを送信します。また、認証にAuthorizationヘッダーを使用しているため、HTTP Basic Authまたは[〜＃〜] ntlm [〜＃〜]を使用していない限り、CSRFを何らかの形で防止します。これらの認証トークンは、Cookieと同様に、各リクエストで送信されます。

つまり、認証にCookieを使用していても、CSRF攻撃はWebページからデータをこすり落とすことができないため、機密情報を返すことはできません。アクションをトリガーしない限り、データは重要ではありません。

CSRFに対して脆弱であると思われる状況があります。

  1. サーバーがCookieまたはトークンのいずれかを受け入れる場合はどうなりますか？

->私は最近同じに遭遇しました。アプリケーションにはCookieまたは認証トークンが必要です。 Cookieは常に送信されるため、ユーザーは認証されたものと見なされ、リクエストが処理されて、アプリケーションが任意のドメインから認証トークンを送信できると想定して、CSRFに対して再び脆弱になります。

  1. アプリケーションがクロスドメインで読み取ることができる認証トークンをリークした場合はどうなりますか？

->クロスドメインで読み取ることができる定義済みのエンドポイントからトークンをフェッチするアプリをいくつか見ました。 JSONP、CORS、crossdomain.xml、JSONハイジャックなどの可能性があります。これもまたCSRFにつながります。

認証にCookieを使用しても

それは常に脆弱であり、あなたのケースではAPIリクエストである最終リクエストで遊ぶ必要があるだけです。

だから私の質問は、この場合はいかなる種類のCSRF保護も実装しないことは問題ないのですか？それに関してセキュリティ上の問題があるのをとても恐れています

実際のところ、そうです。また、APIにリクエストを送信してAccess-Control-Allow-Credentials: falseを返すことができるドメインをホワイトリストに登録してください。私の意見では、これはCSRFに対してかなり安全になります。

4
1lastBr3ath

まず、次のことを理解することが重要です。ユーザーを認証するために何かを実装し、リクエストを認証するために何かを実装する必要があります（Anti-CSRF）。 CSRF攻撃は被害者のセッションを使用するため、Authorizationヘッダー値がすべてのセッションで同じである場合、アプリケーションはCSRF攻撃に対して脆弱である可能性があります。アプリケーションはユーザーセッションのみを検証するため、リクエストを検証します。これは、次の機能を持つトークンを使用して可能です。

  • 十分な長さ。
  • 疑似ランダム。
  • ユニークな値。
  • リクエストごとに1つ。

まず、ユーザーセッションを検証します。それが有効なユーザーであり、そのユーザーの権限または役割である場合は、トークンを使用してリクエストを検証します。有効なトークンである場合は、リクエストを許可できます。

この情報がお役に立てば幸いです。

2
hmrojas.p