CSRF（Cross-Site Request Forgeries）

クロスサイトリクエストフォージェリ

フォージェリが偽造とかって意味みたい

簡単にいうと別のサイトから単純にAPI叩くときにちゃんと対応してないサイトとかだったらリクエストが正常なものとして処理されてしまう。

code:html

</form>

お金送金みたいなのも正常なリクエストとして処理されちゃうからヤバみ！

発生するパターン

POSTリクエストとかで認証とかせずにcsrf tokenを送ってない場合とか

最近でPOSTリクエストで認証挟んでないケースあるのか知らん

csrf tokenみたいな一時的なトークン生成してあってるか検証する必要がある

認証をcookieとかに保持している場合に起き得る

設定によっては自動で送信されるから。

samesite設定ちゃんと設定する、noneにするならちゃんとcsrf tokenの仕組みとか作らないとアブナミ

headerの情報は勝手に送られるわけではないから。headerとかで送るAuthorization headerとかは送られない。

というかなんで自動送信されるの？

cookieに記されてる、domain, path, samesiteの設定等を見てリクエストを送るから。

例えば、bank.comのcookieがあって、evil.comからbank.comへのformリクエストを作っている場合

samesiteがnoneだとクロスサイトからでも送れるようになるので、evil.comからbank.comへアクセスするリクエストではcookieを送る必要があると判断して送ってしまう。

結果的にお金を送る処理が成功してしまう可能性がある。みたいな感じかな。

samesiteをstrictにしていると送らないのでこれにしておけると安全ではあるのかな

jsの場合は自動で送られないけど、credentials includeにしてて、corsの設定も適当なら起き得るかな。

cors設定していれば、仮に送られてもレスポンスが破棄されるはず。

あとはreferrerとかでリクエスト元調べてそもそも拒否するってのでも対応できそう

originとかも

originで検証してなければreferrer見るってのが安全そう。

あとなんかcsrf用のトークンをサーバーでcookieに保存させてやるやつ

double submit cookie

token自体注入できてしまうとcsrfできてしまうみたい。

別サイトからset cookieされる可能性あるのかな。

同じキーで作成されたcookieの場合とかってどうなるんだろう。

そのドメインのcookieを作成するってのはsopで難しいけど、インジェクションしてheaderを書き換えれたりする場合そこからset-cookieできるみたいな感じなのかな。記事で例に出てたcookieの注入がいまいち理解できてない。

記事のコード見る感じサービスが脆弱な場合cookie注入できてしまったらDouble Submit Cokkieの検証が意味なくなる。

使わない方がいいというよりかは、使うのならそこらへんも気にした方がいいってことかな

それこそ、origin見たり、ちゃんと生成済みのやつか確認したり、そもそもinjectionできないみたいなところの対策は必要。

httponlyつけずにcsrf token cookieに入れたらjsで読み取れそうだけど、なんでcsrfできないのか疑問

同一オリジンポリシー（SOP）で制御しているから仮にhttponly外してjsからアクセスできるにしてもcookieの値にまではアクセスできない。

nextjsとかだとServer Componentとか使えるからサーバー側で毎回生成してチェックしてあげる方がいいと思う。

そもそも単純にCookieを適切な状態で渡すのが一番大事かな。これをしなくてもCookieの設定を見直してsamesiteやhttponly, secureをつけておくってのは大事。double submit cookieを使わなくてもなんとかできると思うし。

最近のnextjsでserver action使ってるけど、勝手にorigin判定して弾いてくれるみたい。

てか、これ仮にx.comみたいなドメインがなんかしらで切れて誰かに買われたとかってなったらcsrfし放題なのでは。

ログインできるサービスのドメインって容易に変えるべきではないのかな。

その前にトークン破棄させるとか、既存のトークン使えないようにするとかは考えないといけなそう。