私はREST APIを使用しており、ヘッダーまたはURLクエリとして送信されるアクセストークンを使用しています。Cookieはまったく使用していません。
CSRF攻撃に対してまだ脆弱ですか?他のタブがリクエストを送信でき、Cookieも送信されるため、Cookieを使用する場合は、私は知っていますが、私の場合、Headers/UrlParamはまったく送信されません。
Noそのシナリオでは脆弱ではありません。
その理由は、あなたが説明したとおりです。サードパーティのサイトがサイトへのリクエストを生成する可能性がありますが、認証の詳細は添付されません。
HTTP基本認証またはHTTPダイジェスト認証を使用している場合でも、CSRFは可能です。その理由は、ブラウザーがこれらのプロトコルを「ネイティブに」実装するためです。つまり、ブラウザーは、特定のドメインに送信されるすべての要求で資格情報を自動的に挿入します。
Cookieなしで他の認証形式を使用している場合、CSRFは使用できません。
これを説明する良いリンクがあります: OWASP CSRF
あなたの質問から、あなたが脆弱かどうかは明らかではありません。トークンは固定されていますか、それとも暗号的に強力でランダムに生成されたトークンですか?固定されている場合は、意味がありません。
SSLを使用していますか?そうでない場合、トークンが盗聴および盗難される可能性があります。SSLを使用することを強くお勧めします。
また、URLでトークンを渡すことはお勧めしません。 URLは、ブラウザーの履歴、ネットワークアプライアンスなど、多くの場所でログに記録されるため、機密情報です https://www.owasp.org/index.php/Cross-Site_Request_Forgery_( CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL
トークンが有効であることをサーバー側でどのように検証しますか?あなたはそれをサーバーセッションに保持しますか?通常REST APIはステートレスになるように設計されています。つまり、セッションを維持する必要はありません。このルールを守りたい場合は、httpのみのcookieにトークンを作成し、API呼び出しごとに送信する必要があります。リクエストの一部としてのCookie値。APIは、Cookie値がリクエスト内のトークンと同じであることを確認する必要があります。攻撃者はCookieを読み取ることができなかったため、リクエスト内で正しいトークンを送信できませんでした。
これはいいブログです: http://blog.codinghorror.com/preventing-csrf-and-xsrf-attacks/
これは、CSRF攻撃から保護するための正しい方法のようです。ただし、リクエストごとに新しいトークンを生成し、以前に使用したトークンを無効にすることもできます。