Rest APIエンドポイントでCSRF保護を使用する必要がありますか？
簡単なメモ：これは カスタムヘッダーを使用した（および検証トークンを使用しない）CSRF保護 の重複ではありませんが、いくつかのオーバーラップがあります。その投稿では、実際に必要かどうかについては説明せずに、RestエンドポイントでCSRF保護を実行する方法について説明しています。実際、私がこのサイトで読んだCSRF/Restの質問の多くは、CSRFトークンを介してエンドポイントを保護することについて話しているが、実際にそれが必要かどうかは論じていない。したがって、この質問。
CSRF保護はRest APIエンドポイントに必要ですか？
CSRF攻撃に対するエンドポイントの保護についてRESTエンドポイントを保護することについて多くの議論を見てきましたが、トピックについて多くのことを考えてきたので、RESTエンドポイントは追加の保護をゼロで付与します。したがって、RESTエンドポイントでCSRF保護を有効にすると、アプリケーションに不要なコードが導入されるだけなので、スキップする必要があると思います。何か不足している可能性がありますとはいえ、この質問です。CSRF保護がそもそもなぜ必要なのか、またそれが防御する攻撃ベクトルを覚えておくことは役立つと思います。
CSRFを選ぶ理由
要するに、Cookieを送信することで、リクエストに対するログイン認証情報を自動的に提示するブラウザの機能です。セッションIDがCookieに保存されている場合、ブラウザーはそれを元のWebサイトに戻るすべての要求と共に自動的に送信します。これは、攻撃者が被害者ユーザーとしてアクションを実行するために実際に認証の詳細を知る必要がないことを意味します。むしろ、攻撃者は被害者のブラウザをだましてリクエストを行わせるだけでよく、リクエストを認証するための資格情報は無料で利用できます。
REST APIと入力します
Rest APIエンドポイントは他のリクエストと非常に重要な違いがあります。それらは特にステートレスであり、Cookieまたはセッションからのデータを受け入れたり使用したりしてはなりません。その結果、標準に固執するREST APIは、このような攻撃の影響を自動的に受けません。Cookieがブラウザから送信された場合でも、Cookieに関連付けられている資格情報は完全に無視されます。REST APIへの呼び出しの認証は、まったく異なる方法で行われます。最も一般的な解決策は、ある種の認証キー（OAuth Tokenなど）ヘッダーのどこか、またはおそらくリクエスト本文自体で送信されます。
認証はアプリケーション固有であり、ブラウザー自体は認証トークンが何であるかを認識していないため、APIエンドポイントにアクセスするように騙されたとしても、ブラウザーが認証資格情報を自動的に提供する方法はありません。結果として、CookieのないRESTエンドポイントは、CSRF攻撃から完全に影響を受けません。
それとも何か不足していますか？
私はもともと自己回答を目指していませんでしたが、さらに読んだ後、RESTのCSRF保護にまだ興味があるかもしれない理由を説明する包括的な回答であると思います。エンドポイント。
Cookieなし= CSRFなし
とても簡単です。ブラウザはすべてのリクエストとともにCookieを送信します。 CSRF攻撃はこの動作に依存します。 Cookieを使用せず、認証にCookieを使用しない場合、CSRF攻撃の余地はまったくなく、CSRF保護を適用する理由もありません。 Cookieがある場合、特にそれらを認証に使用する場合は、CSRF保護が必要です。 「APIエンドポイントにCSRF保護が必要ですか？」ここで停止して、答えを残すことができます。それ以外の場合、悪魔は詳細にあります。
h/t to paj28：CookieはCSRF攻撃の主要な攻撃ベクトルですが、HTTP /基本認証を使用する場合にも脆弱です。より一般的には、ブラウザーがアプリのログイン認証情報を自動的に渡すことができる場合、CSRFが重要になります。私の経験では、CookieはCSRFを発生させるために利用される最も一般的な技術ですが、同じ脆弱性をもたらす可能性のある他の認証方法がいくつか使用されています。
REST =ステートレス
誰かに「RESTとは」と尋ねると、さまざまな異なるプロパティについて説明するさまざまな回答が得られます。誰かがスタックオーバーフローについてその質問をしたので、あなたは多くを見ることができます： https://stackoverflow.com/questions/671118/what-exactly-is-restful-programming
私が常に信頼してきたRESTのプロパティの1つは、ステートレスであることです。アプリケーション自体にはもちろん状態があります。データベースのどこかにデータを格納できない場合、アプリケーションはかなり制限されます。ただし、この場合、ステートレスには非常に具体的かつ重要な意味があります。RESTアプリケーションは、クライアント側の状態を追跡しません応用。セッションを使用している場合は、（ほぼ確実に）クライアント側の状態を追跡しており、RESTフルアプリケーションではありません。したがって、Cookieを介して追跡されるセッション（特にログイン用）を使用するアプリケーションは、RESTフルアプリケーション（IMO）ではなく、RESTアプリケーションのように見えても、CSRF攻撃に対して確実に脆弱です。 。
クライアント側のステートレス性がRESTアプリケーションにとって重要である理由の1つは、仲介者が応答をキャッシュする機能もRESTの望ましい部分であることです。パラダイム。アプリケーションがクライアント側の状態を追跡している限り、キャッシングはできません。
Rest≠Cookieless
これらの理由により、完全に準拠したRESTアプリケーションはセッションを必要とせず、Cookieを必要としないため、CSRFセキュリティを必要としないと当初は想定していました。ただし、いずれにせよCookieを優先する可能性のある少なくとも1つの使用例があります。それは永続的なログインです。
一般的なクライアント側（この場合はモバイルではなくブラウザ）のWebアプリケーションを考えてみます。ログインから始めます。これは、REST APIを使用してユーザーの資格情報を検証し、その結果、将来のリクエストを承認するためのトークンを受け取ります。シングルページアプリケーションの場合、そのトークンをメモリに保持するだけで済みますが、そうすることで、ユーザーがページを閉じた場合にユーザーを効率的にログアウトできます。その結果、単一のブラウザセッションよりも長く続く可能性がある場所に状態を保持することをお勧めします。ローカルストレージはオプションですが、XSS攻撃に対しても脆弱です。XSS攻撃が成功すると、攻撃者がログイントークンを取得し、それらを攻撃者に送信して、その裁量で使用される可能性があります。
このため、ログイントークンを保存するためにCookieを使用することをお勧めする人もいます。 Cookieを使用すると、httpのみのフラグを設定できます。これにより、アプリケーションがCookieを設定した後に、Cookieを読み取ることができなくなります。その結果、XSS攻撃が発生した場合でも、攻撃者はあなたに代わって電話をかけることができますが、認証トークンを一緒に持ち去ることはできません。このCookieの使用は、サーバーがクライアント側の状態を追跡していないため、RESTのステートレス性の要件に直接違反しません。ヘッダーではなくCookieで認証資格情報を探しているだけです。
REST APIでCookieを使用することが正当な理由である可能性があるため、これについて言及しますが、さまざまなセキュリティと使いやすさのバランスをとるのは明らかに特定のアプリケーション次第です。個人的にはREST APIでCookieを使用しないように努めていますが、いずれにせよそれらを使用する理由は十分にあるでしょう。どちらの方法でも、全体的な答えは簡単です。Cookie（またはブラウザーが自動的に実行できる他の認証方法）を使用している場合は、CSRF保護が必要です。 Cookieを使用していない場合は使用しません。
「APIエンドポイントにアクセスするようにだまされたとしても、ブラウザーが認証資格情報を自動的に提供する方法はありません。」
統合されたWindows/Kerberos認証を使用するプライベートネットワークには注意してください。このシナリオでは、構成されている場合、ブラウザーは資格情報（KerberosまたはNTLMトークン）を自動的に提供します。
だから-私はこの場合CSRFが必要だと思います。
CSRF保護が必要かどうかは、次の2つの要素に基づいています。-
リクエストは状態変更アクションを実行していますか（REST API Statelessness）とは異なります）-状態変更アクションは、アプリケーションの状態を変更するアクションです。たとえば、何かを削除する、何かを追加する、何かを更新するなどです。これらは、アプリケーションがユーザーのバック状態を変更するためのアクションです。すべてのPostリクエストといくつかのGetリクエストがこのカテゴリに分類されます。REST = APIは状態変更アクションを持つことができます。
ブラウザーによって提供される認証（Cookieに限定されない）です-CSRFは、要求がユーザーによって開始されたか、他の開いているタブによって開始されたかに関係なく、ブラウザーによって要求に認証情報が含まれるために発生します。そのため、ブラウザが情報を自分で含めることができるあらゆる種類の認証には、CSRF保護が必要です。これには、Cookieベースのセッションと基本認証の両方が含まれます。
上記の2つのカテゴリに該当するすべてのリクエストには、CSRF保護が必要です。
Rest APIエンドポイントは他のリクエストと非常に重要な違いがあります。それらは特にステートレスであり、Cookieまたはセッションからのデータを受け入れたり使用したりしてはなりません。
それが「REST API」の定義方法である場合、CSRFは不可能です。 CSRFは「セッションライディング」とも呼ばれます[ citation ]。「ライド」するセッションがないと、明らかに機能しません。
私が他の答えに追加する1つのことは、CSRF保護が必要であるということです のみ Cookieのドメインとパス 問題です。または別の言い方をすると：
承認！=認証
Cookie ==認証
トークン==承認
これは、持続的ログインの実装に関連しています（3番目のポイント）。ログインUIとlogin.example.comエンドポイントをホストする/authorizeにcookieを添付すると、暗黙的にOAuthフローを数分ごとに実行することができ、新しいログイン（例：パスワードダイアログなし）クライアントはCookieがホストに送信されないため、取得したアクセストークンをCSRFなしでapi.example.comに送信できます。
したがって、REST APIでCSRFを扱うことを安全に回避できます。しかし、ログイン/認証サーバーは防弾（およびCSRF保護）の方が優れています。
Answer：トークンをlocalStorageに保存し、JSを使用してリクエストに追加すると、CSRF保護が自動的に保証されます（攻撃の性質による） ）
Addendum：localStorageではなくhttpのみのCookieを使用する方が安全かどうか（この方法でCSRF保護を行うと、 XSSの場合の問題）：実際には問題ありません。悪用されたXSSを介してサイトのJSを制御している攻撃者にとって、それを少し難しくするだけです。 @bobinceはそれをより良い言葉で説明しています： httponlyを設定するとXSSを使用してセッションを盗むのを防ぎますか？
XSSはアプリケーションレベルの脆弱性ですが、クレームの使用を通じてトークンの能力を制限することでその影響を軽減できます（必要最小限に制限）