DRF_CSRF対策の必要性について　#173日目

低気圧のせいか頭痛が酷いです。。
頭痛薬飲んで多少マシになったので本日はライトめなアウトプットだけしようと思います。

CSRF (Cross-Site Request Forgery) とは

これはリクエスト強要とも呼ばれ、利用者の意図に反して、副作用を伴う重要なリクエストを強要する攻撃を指します。

Webブラウザに保存されているCookieなどの値が、自動的にリクエストヘッダにセットされて送信されるという性質を利用しています。ログインセッションが残った状態（Cookieに値が保存されている状態）で悪意あるサイトに誘導され、罠によって、正規のサイトに不正なリクエストを送信してしまいます。Cookieの情報がセットされて送信されてしまうので、正規のサイト側からは、正規のリクエストなのか不正なリクエストなのか区別がつかないのです。

例えば何かのサイトにログインしっぱなしのまま、罠サイトに引っかかってしまうと、不正なリクエストが送信されてしまう可能性があります。ユーザーやセッションを識別するための情報が悪用されてしまうということですね。

そのためこのような罠への対策を施しておく必要があります。

DRFでのCSRF対策

DRFでは以下のケースでCSRF対策が必要です。

１．Cookie認証を利用する場合
２．Basic認証やDigest認証を利用する場合
３．トークン認証やJWT認証を利用し、かつトークンの保存先をCookieにした場合

上述のとおり、ユーザーやセッションを識別するための情報が、Webブラウザから自動送信されることがCSRF攻撃の大きな要因になっています。Cookieはもちろん、Basic認証もWebブラウザに保存された認証情報が自動的に送信されてしまうため、CSRF対策が必須です。

トークン認証やJWT認証でも、認証用トークンをCookieに保存する場合は対策必須です（トークンをlocalStorage等のWebストレージに保存する場合は不要）。

DRFのようなSPAでは、以下のような対策を施します。

・カスタムヘッダを利用してCSRFトークンを毎回送信する
・Cookie認証を諦めてトークン認証やJWT認証を使う

前者はAjaxリクエストを活用する方法です。Ajaxについては前回の記事で触れましたが、HTTPリクエストヘッダの値を変更したり、カスタムヘッダを任意に追加したりできます。Ajaxは同一オリジンまたはCORSで許可されたオリジン以外ではレスポンスが読み取れないのでその点で安全です。また、クロスドメインでカスタムヘッダを利用した場合、「プリフライト (preflight) 」というリクエストが事前送信されますが、これも同一オリジンまたはCORSで許可されたオリジン以外ではレスポンスが読み取れません。この二段構えの認証により、同一オリジンまたはCORSで許可されたオリジンからのAjaxリクエストであることが保証されるため、CSRF攻撃の心配はないという理屈になります。

後者はlocalstorage等のWebストレージに認証用トークンを保存して、Cookieに保存しないという選択ができるため、その場合はCSRF対策は不要になります。

ここまでお読みいただきありがとうございました！！