こう
- 「CSRF とは
何ですか。 どう 防ぎますか」 - 「ログイン中の
人が 別の サイトを 開いただけで、 こちらの サイトの 設定が 変わってしまいました。 何が 起きていますか」 - 「XSS と CSRF の
違いは 何ですか」
面接官が
- ブラウザが Cookie を
自動で 付けて 送る、という 前提から 説明できるか - 守りの
中心に トークンを 挙げ、 SameSite の Cookie を 合わせて使えるか - データを
変える 操作を GET で 受けない、という 前提を 押さえているか
短い答え
- CSRF は、
ログイン中の 人が 別の サイトを 開いた ときに、 本人の 知らない 要求を こちらの サイトへ 勝手に 送らせる 攻撃です。 - ブラウザが
ログインの Cookie を 自動で 付けて 送るので、 サーバーから 見ると 本人の 操作と 見分けが つかないのが 原因です。 - 防ぐには、
自分の 画面にだけ 埋めた トークンを 要求と 一緒に 送らせて サーバーで 照らし、 Cookie には SameSite を 付けます。
少し
なぜ起きるか
ログインの
トークンで照らす
サーバーは
SameSite の Cookie
Cookie に SameSite=Lax や SameSite=Strict を
前提として守ること
データを
作った
よく
- 「POST に
すれば 防げる」と言う ほかの サイトの フォームからも POST は 送れます。 トークンで 照らします - 「SameSite を
付ければ 完全」と言う 防げない 場面が あるので、 トークンと 合わせて使います - XSS と
同じ 物として話す XSS は 相手の 画面で スクリプトを 動かす穴、 CSRF は 本人の 権限で 要求を 送らせる攻撃です
深掘りの問い
- 「トークンを URL に
入れてはいけないのは なぜですか」 URL は 履歴や ログ、 ほかの サイトへの 参照元の 情報に 残って 漏れやすいから、と答えます - 「Authorization ヘッダーに
トークンを 入れる API では、 CSRF は どう 変わりますか」 ブラウザが 自動で 付けないので、 CSRF は 起きにくくなる、と 答えます。 代わりに、 トークンの 置き場が XSS で 読まれないかを考えます - 「SameSite の Strict と Lax の違いは」 Strict は
ほかの サイトからの 要求には Cookie を 付けません。 Lax は ほかの サイトの リンクから GET で 移ってきた ときだけ付ける、と答えます