認証 / セキュリティ
誰であるかを証明し、なりすましを防ぐ
認証は「セッションをサーバーが覚える」か「トークンに書いて持たせる」かの選択から始まる。この選択が、ログアウトの実装可能性・スケール特性・漏洩時の被害範囲をすべて決める。攻撃手法は、その選択の穴を突いてくる。
読み終わると、これに答えられるようになります
- ?JWT を使うとなぜ即時ログアウトが難しくなるのか
- ?SameSite=Lax だけで CSRF は防げるのか
- ?アクセストークンを localStorage に置くと何が起きるのか
基礎14分
Cookie とセッション — 状態を持たない HTTP に記憶を持たせる
サーバーが覚えるか、利用者に持たせるか。この選択が、ログアウトの実装可能性とスケール特性をすべて決める。
Secure 属性を付け忘れたセッション Cookie が、社内 Wi-Fi の平文通信で盗まれた
応用14分
JWT — 取り消せない代わりに、問い合わせが要らない
署名付きトークンが解いた問題と、その代償。「ステートレスだからスケールする」の裏で何を諦めているのか。
退会したユーザーが、24時間有効な JWT でその後もAPIを叩き続けられた
発展16分
OAuth 2.0 と OIDC — 「代理で使わせる」と「誰かを証明する」は別物
認可と認証を混同すると穴が開く。認可コードフローがなぜ遠回りに見える手順を踏むのか、一歩ずつ理由がある。
アクセストークンでログイン判定を実装し、他サービスのトークンで別人になりすまされた
応用16分
XSS・CSRF・SQLi — データとコードの境界が壊れる
3つの代表的な脆弱性は、どれも「データとして扱うべきものが命令として解釈される」という同じ形をしている。
検索キーワードをそのまま画面に出す実装で、管理者のセッションが盗まれた