CSRF(クロスサイト・リクエスト・フォージェリ)
Overview
クロスサイトリクエストフォージェリ（CSRF）とは、Webアプリケーションに存在する脆弱性、もしくはその脆弱性を利用した攻撃方法のこと。
掲示板や問い合わせフォームなどを処理するWebアプリケーションが、本来拒否すべき他サイトからのリクエストを受信し処理してしまう。
攻撃者がユーザーのブラウザを介してユーザーの意図に反して、別のウェブサイトに対して不正なリクエストを送信させる攻撃手法です。ユーザーが特定のウェブサイトにログインしている状態で、そのサイトに対するリクエストが攻撃者によって偽装されることにより発生します。これにより、ユーザーが意図しない操作（例：パスワード変更、データ削除、資金移動など）が 行われる可能性があります。
例
サービスの利用者を罠サイトにアクセスさせて、APIサーバーに対する意図しないリクエストを送信させること。
そのユーザーがサービスにログイン済みであり、セッションIDをクッキーに保存していた場合、その情報も一緒に送信される。
そのため、そのリクエストは「認証済みのユーザーからのリクエスト」であるため、ユーザーが意図していなかったとしても、そのリクエストは正当なリクエストとして処理されてしまう。
これにより、退会や決済、SNSへの不適切な投稿などのセンシティブな操作が、ユーザーが意図しない形で行われてしまう。
一般的なWebアプリケーションにおけるCSRFとは、「ユーザの意図しない処理を強制される」脆弱性のことです。
Webアプリにログイン中の被害者が、攻撃者の用意したHTMLコンテンツにアクセスするなどした結果、
商品の購入
登録情報の変更
などを行うリクエストがユーザのブラウザから送信され、意図しない処理を強制される可能性があります。
以上を踏まえると、OAuth2.0でもユーザの意図しない何らかの処理を強制される脆弱性が想定されるということになります。
攻撃の手法・特徴
- 攻撃者は攻撃用Webページを準備し、ユーザがアクセスするよう誘導する。
- ユーザが攻撃用Webページにアクセスすると、攻撃用Webページ内にあらかじめ用意されていた不正なリクエストが攻撃対象サーバに送られる。
- 攻撃対象サーバ上のWebアプリケーションは不正なリクエストを処理し、ユーザが意図していない処理が行われてしまいます
対策 CSRFトークン
CSRF対策としてよく利用されるのがトークンを用いた対策。
SPAでは難しく、SPAをレンダリングするサーバーとAPIサーバーが別々の場合、
たとえばRailsアプリの場合は、Railsが返すhtmlのなかにトークンを仕込んでおき、それを document.getElementsByName('csrf-token')[0].content のような形で拾って、それをAPIへのリクエストの際に送信すればよい。
だが一般的なSPAではフロントエンドとバックエンドが独立して存在していると思うので、この方法は使えない
ここでCORSが絡んでくる。
SPAでAPIを叩く場合は、form ではなく XMLHttpRequests や fetch を用いて非同期通信で叩くことになるのが一般的だと思うが、異なるオリジンに対して非同期通信を行うときは必ず、CORSを用いた通信になる。
このCORSの仕組みが、「トークンを使わない場合のCSRF対策」の根幹になる。
上述したように、「異なるオリジン間の非同期通信」は必ずCORSを利用した通信になるので、CORSの仕組みを利用してCSRF対策を行っていく。
CSRF(Cross-Site Request Forgery):クロスサイトリクエストフォージェリ
Cookieを悪用したセキュリティ攻撃のひとつ この攻撃では、ドメインが異なるサイト間でCookieを悪用して本来意図しないサイトに対して書き込みをしてしまったり、意図せず退会処理をしてしまったりします。 今までは各サイト側でCSRFに対しての対策を各自が施す形でしたが、これをブラウザレベルでしっかりと防御しようという意図があるのが今回のSameSiteの仕様変更となります。