※この記事は社内の勉強会で使用した資料を一部改訂したものになります。

そもそもCSRFとは？

• cross site request forgery(xsrfともいう)
• クロスサイトでリクエストを強制する手法

何ができるの？

• 掲示板に勝手に書き込みのようなしょうもないこと
• パスワードを勝手に変更のような危険なこと
• 要はPOSTリクエストでできること

どうやってやんの？

1. ユーザーがcsrf対策をしていないサイトAにログインする
2. 攻撃者がサイトAへリクエストを送る罠サイトBを作成する
3. ユーザーが罠サイトBのリンクを踏む
4. 罠サイトBからサイトAにリクエストが送られる
5. サイトAのユーザーの情報が勝手に作成・更新される

実例

• はまちちゃん（2005年）
  罠サイトのURLをクリックすることで、勝手に「ぼくはまちちゃん！」というタイトルで日記がアップされてしまうという現象が多発した。
• パソコン遠隔操作事件（2012年）
  罠サイトのURLをクリックしてしまい、横浜市の公式サイトに意図せず殺害予告文を書き込んでしまった大学生が誤認逮捕された。

BurpでCSRFのPoC生成

PoCの生成は以下のとおりです。
Proxy > Http history > リクエスト右クリック > Engagement tools > Generate CSRF PoC

• Options
  formタグのenctype属性を変更したり、XHR形式を選択できたりする。詳細は下図。
• Regenerate
  PoCを再生成する。
• Test in browser
  PoCをブラウザで表示する。
• Copy HTML
  PoCのHTMLをクリップボードに保存する。

Optionsを開いた画面。

CSRF対策

• Refererのチェック
• 確定前にパスワードの入力を求める
• token等の秘密情報をリクエストパラメータに埋め込む

Refererのチェック

ブラウザから送信されてくるリンク元の情報である Refererを確認することで、正しい画面遷移を行なってきていることを判断する。
ユーザの設定や環境によっては送信されないことがある。
そのため、社内環境など、環境を特定できる場合に利用することがいい。

token等の秘密情報をリクエストパラメータに埋め込む

ユーザーが画面に必要情報を入力後送信処理を行うと、トークンも一緒にWebアプリケーションに送信する。
この送信されたトークンとセッションに保存しておいたトークンが等しければ、正しいリクエストだと判断できる。トークンが空だったり、値が異なればエラーとして処理をする。

確定前にパスワードの入力を求める

リクエストの際にパスワードを求める。
防げるけど、ユーザビリティの低下につながるので、決済などのセキュリティが重要な処理などで有効。

Cookie でセッション管理を行なっていることでcsrfが起きるなら、クロスオリジンへのリクエスト送信時にCookieを付与しなければ緩和できるんじゃね？

CookieのSameSite属性

• Lax
• Strict

Lax

アドレスバーのURLの変更が伴う遷移かつGETのとき以外はCookieを送らなくなる。
POSTではCookieが送られないため、CSRFのような攻撃への耐性が高まる。

Strict

SameSite以外からの全てのリクエストで一切Cookieを送らなくなる。
別のサイトからリンクで遷移した場合にもCookieが送られなくなるなるんで、毎回ログインが必要となり、ユーザの利便性が・・・
Laxよりセキュリティが高いので、銀行サイトなどでは有効な値です。

ブラウザの対応状況

Edge, Firefox, chrome, safariなどの主要ブラウザでは使えそう

まとめ

• 勝手に更新・作成ができるだけだが、対象によっては幅広い攻撃が可能
• tokenとSameSiteのLaxをやっておけば基本的には問題ない（Laxはおすすめだけど、ブラウザの種類や画面上の操作によってはきかないことがあるため、あくまで保険的な対策になります）