CSRFに関する備忘録
こんにちは，なめこです．
最近業務でCSRF脆弱性への対策をする機会があったので，調べたことを備忘録として残しておきます．
あくまで備忘録なのでざっくりとした理解の部分もあります．
他にわかったことがあれば追記していく予定です．
CSRFとは
CSRF(cross-site request forgeries)はWebアプリケーションの脆弱性を利用した攻撃のことで，リクエスト強要とも呼ばれます．
悪意のあるサイトのリンクを踏ませることなどによって，ログイン中のサービスに対して意図しない操作を実行させる攻撃のことです．
仕組みに関しては後述しますが，この攻撃が成功すると，ログイン中にユーザが可能な操作を全て行えます．
例えばSNSなどでは，意図しない投稿，情報の公開/非公開の制限の操作などが可能です．
また，CSRFへの対策がされていない銀行のサービスがあった場合，他の口座への振込を強制されるようなインシデントが発生する可能性があります．
原理
一般的にWebアプリケーションのログイン状態は，Session IDという文字列をユーザ側とサーバ側両方で管理し，通信のたびにそれを照合することで保持されています．(他の認証方式もありますが本筋とはずれるので割愛)
このSession IDはユーザ側ではCookieなどに保存され，サーバにリクエストをする際に正しいIDを持っているかどうかで正当なリクエストであるかを判断しています．
(Cookieはその値を設定したサーバに対してリクエストする際，自動的に送られます)
これは別のページからリクエストがあった場合も同様であり，正規のリクエストであるかの検証をSession IDとは別で行なっていない場合にCSRF脆弱性が生じます．
CSRF脆弱性のあるサービスのページにログイン中に，XSSや悪意のあるページによってそのページへのリクエストが送られると，そのリクエストにはSession IDの格納されたCookieが付随するので正当なリクエストとして処理されてしまいます．
このリクエストはログイン中のユーザのものとして送られるので，そのユーザがそのサービスで可能な操作であれば全て行える，ということになります．
対策
ユーザ側
「危険なURLを踏まないようにする」「適度にログアウトする」等の注意程度の対策となります．
そもそもユーザが危険を感じながら使わないといけないという状況があまりよろしくないので，ページを運営している側が対策をすることが必要です．
サービス提供側
主な対策はトークンの発行やreferrer監視，origin監視となります． 以下にその詳細を記します．
CSRFトークン
Session IDとは別に，推測不可能な文字列を発行し，正規のリクエストを行う際にはそれを付与するという方式です． Session IDとトークン，両方が正しいものが正当なリクエストとなります．
このトークンはユーザ側に持たせる必要がありますが，Session IDとは別の方法で保持させた方が良いでしょう．
セッションや，formのhidden値として発行するのが一般的でしょうか．
攻撃者は保存されているものを悪用してリクエストを偽ることはできますが，保存されている値そのものを参照することはできません(詳細はCORSで調べると良いかと)．
そのため攻撃者はトークンの偽造はできず，攻撃を防ぐことが可能になります．
この方法が，現時点では最も有効なようです．
referrer監視
Referrer(Referer)はそのリクエストがどのURLから送られてきたのかが記録されています．
CSRFは外部ドメインからの攻撃なので，リクエストのReferrerを監視することで攻撃を防ぐことが可能です．
しかし，Referrerはブラウザ側の設定で非送信にすることができるので，ユーザの設定次第では正規のリクエストでも不正のものとして扱われてしまうという危険があります．
また，XSSの脆弱性が残っている場合，正規のページから不正なリクエストを送信できるため，正当なリクエストとして処理されます．
Origin監視
Originにはリクエストが送られてきたURLのうち，サーバ名のみが記録されています．
手法としてはreferrer監視とほぼ同様となります．そのためXSSの弱点も同様に存在します．
※2018/9/27追記
OriginはReferrerと違い，ブラウザの設定で非送信にはできなさそうです．
また，クロスドメインなリクエストに関しては必ずOriginが付与されます(設定次第ではnullにはなるが，Originがあることには変わらない)．
なのでXSSの脆弱性が存在せず，正規ユーザからの不正なリクエストには寛容なシステムであるならばOrigin監視で十分に対策できると考えられます．
Origin監視はCSRFトークンの発行よりも実装コストが低いことが多そうなので(フレームワークで簡単にフィルタ実装できたりするため)，こちらを採用するのもアリかもしれません．
pre flight
まだちゃんと調べられてないです．(後日調べてまとめるかも)
フレームワークについて
フォームにトークンを自動的に埋め込み，リクエストの正当性を検討するフレームワークも多いようです(増えている？)．
気にしてなくても既に対策されているかもしれませんね，
