web-dev-qa-db-ja.com

CSRFの明確化と説明

クロスサイトリクエストフォージェリがどのように発生するかは理解していますが、SPA（React）アプリケーションを使用してそれを保護する方法については非常に不明確です。

たとえば、私の現在の戦略は、ログイン時にcsrfトークンをcookieとしてクライアントに送信し、クライアントでcookieを取得してreq.bodyまたはカスタムヘッダーに含めることです。

私の高速バックエンドはCSURFパッケージを使用しており、POSTルート上のトークンを検証します。

しかし、これはどのように安全ですか？悪意のあるWebサイトはまったく同じことを行い、ログインにアクセスし、トークンを受け取り、トークンにヘッダーに追加して、何でも実行できます。

APIがクライアントアプリケーションを送信するサーバーから分離されているSPAでCSRFから保護する適切な方法は何ですか？

web-applicationjavascriptcsrf
2
WriterState

しかし、これはどのように安全ですか？悪意のあるWebサイトはまったく同じことを行い、ログインにアクセスし、トークンを受け取り、トークンにヘッダーに追加して、何でも実行できます。

悪意のあるWebサイトはa csrfトークンを取得する可能性がありますが、サーバーにはユーザーセッションごとに異なるcsrfトークンがあるため、悪意のあるWebサイトは役に立ちません。

Csrf攻撃をよりよく理解するには、次のワークフローを検討してください。

  • ユーザーがウェブサイトに正常にログインし、セッションサーバー側を作成し、サーバー側セッションを識別するセッションCookieクライアント側を取得する

  • このユーザーは別のサイト（悪意のあるサイト）にアクセスします。このサイトには、Webサイトでフォームの送信をトリガーするonloadイベントがあり、ログインしたユーザーだけがアクセスできます。フォームは次のようになります。

    <form method="POST" action="https://your.web.site/secured/transferFund">
    <input type="hidden" name="amount" value="1000"/>
    <input type="hidden" name="to" value="malicous_guy_account"/>
</form>

    イベントでこのフォームを送信すると、次のようになります。

    • エンドユーザーには完全に見えなくなります
    • クライアントはあなたのウェブサイトにログインしており、セッションCookieはこのhttpリクエストに自動的に使用されるため、機能します

では、CSRFトークンはどのように役立ちますか？

Cookieには保存されませんが、非表示のフォームフィールドに直接、またはヘッダーに保存されるため、悪意のあるWebサイトで両方の場所をスキャンすることはできません。

そのため、悪意のあるWebサイトが以前のフォームを送信しようとすると、csrfトークンが見つからないか無効であり、承認されていないためサーバー側で拒否されます。

それが機能するには、以下が必要です：

  • ユーザーセッションごとに異なるトークン
  • トークンをセッションのライフサイクルに関連付けるには、
  • クッキーから遠ざけるために
  • 状態サーバー側を変更するすべてがPOSTアクションの背後にあること
  • すべてのPOSTアクションはそのCSRFトークンが検証されていること
4
Thierry

CSRF保護トークンは一意であり、予測不可能ですユーザーセッションごとに。自分の資格情報を使用してログインする攻撃者は、被害者と同じCSRFトークンを受け取りません。攻撃者によって偽造されたが被害者のブラウザから送信されたリクエストは、リクエストの本文/ヘッダーに攻撃者のCSRF防止トークンが含まれますが、Cookieに被害者のCSRF防止トークンが含まれます。トークンが異なるため、サーバーは偽造されたリクエストを拒否する必要があります。

このパターン（「double-submit cookie」と呼ばれ、値が本文と要求のcookieの両方で送信される）は、特に安全ではないことに注意してください。サーバーで簡単でロードバランサーに対応していますが、サーバーは状態を保存する必要がないため（「ユーザーXはCSRFトークンYを持っている」など）、Cookieの同じ元のポリシーは、ウェブ。

特に、攻撃者が被害者の中間者の位置にいる場合、ネットワーク攻撃を使用して、被害者のブラウザにHTTP経由でページを読み込ませることができます（サーバーがHTTP経由で応答しない場合でも、攻撃者はリクエストをインターセプトしてレスポンスを偽造するだけです）、攻撃者が選択した値でCSRF防止Cookieを設定します。ブラウザーは安全でない接続を介して設定されたCookieを安全な要求と共に送信するため、サーバーは被害者が設定したCookieを受信します。

これは、攻撃者が被害者のブラウザに特定のサイトのCookieを設定できるリスクです。攻撃者はそのCookieの値を知っているので、攻撃者はそのトークンを使用してリクエストを偽造でき、それらは受け入れられます。これを行う最も一般的な方法は、おそらく上記のMitM攻撃によるものです。これからの最善の保護はHSTS（HTTP Strict Transport Security）であり、これにより、ブラウザーが安全でない接続を介してアプリをロードすることさえ防止されます。

1
CBHacking