脆弱性診断ええんやでを聴講してきた その2
今回のテーマ「CSRF完全に理解した」
https://security-testing.doorkeeper.jp/events/85711
なんともタイトル詐欺っぽい笑
CSRF、、、これ診断員でも攻撃ができるできないでよく話に上がるんですよねぇ。
結局ここに
書いてある事が全てだったりそうでなかったりするのだけれど。
普段説明する相手にしっかり理解してもらうための伝え方を学ぶために参加!<( 'ω')/
CSRFとは
被害者ユーザのブラウザから自動で更新処理をさせるような攻撃。被害者ユーザのアカウントで勝手に商品を購入されてしまう、など。
- 攻撃者はCSRF攻撃用罠サイトを用意
- 適当なところに罠サイトのURLを貼る
- 攻撃対象サイトに利用者がログイン
- 別タブで罠サイトにうっかりアクセス
- 罠サイトのフォームが送信されてパスワードが変更させられる。。。
(↑スライドまま)
罠サイトを踏んだユーザのアカウントで処理がされてしまう理由としては、被害者側のブラウザから送信されるCookieを更新処理のあるページに送信している。Cookieは接続先のドメインを見てブラウザが勝手に送信するので自動で被害者側のブラウザのセッションとして利用されているCookieが送信され、正規のユーザからのリクエストを受け取ったとして、サーバが処理してしまう。
ということはログイン処理があるようなアプリケーションに限られる。(ユーザの道程ができないため)
そしてCSRFの流れの説明はホワイトボードをふんだんに使う!どうやってあのややこしい遷移を説明されるのかと思えば...!
対策が必要な処理
- パスワード変更
- 購入、決済
- その他更新が走る処理。
対策
- TOKENを使う
根本的対策として、そのページにアクセスをした際にのみ発行されるTOKENを付与するというやり方がある。
更新が走る処理には正しいTOKENを持っているかどうかをチェックし、正しい値でなければ処理を行わない。 - パスワードを再入力させる
本人しか知り得ない情報を入力させることは、攻撃者が罠サイトに埋め込めない値を使っているため、罠サイトを作ることができない。 - Rereferチェック
罠サイト=正規のサイトからのRefererではないため、ここが正しいかチェックすることで罠サイトからのリクエストを防ぐ事ができる。
(でも実際はRefererによる対策で防げていた対象はあまり見ない...よく抜ける。) 個人的には独自ヘッダ付与するのが結構強い対策だったりと思う。
Docker環境で行う脆弱性診断(LT枠)
dh_meganeさん
Sier6年目だそう。
Docker環境を使って脆弱性診断を試した結果を発表されていた!
localhostの環境に対してZAPを使ったリクエストのを拾い方や簡単なXSSを確認してみたよといった事も。
セキュリティとかいう分野外のことを始めたばかりなのに色々実践してみていてえらいです...!
スライドの以下の部分に共感...!
「Dockerイメージを配布して診断を実施してもらうのもあり?」
ありあり! 全然あり!
むしろコードを我々診断員が見ても良いなら断然Dockerイメージで欲しい。 手元で自由にできる環境の方が制限なく文字列を試せるから脆弱性も見つかりやすいしこういう方が増えてくれれば予定した診断日に突然動かないとかいう案件も一気に解決する予感。
なんと私のセミナーに参加された事があり…終わった後の懇親会で向こうから声をかけて頂いた。話しかけられるまですっかり、忘れていた…申し訳ありませんです🙇人の顔覚えるの苦手なの、どうにかならないかな…。
所感
やはり皆さんCSRFの理解には苦戦されている様子。
そして松本さんは今回もOWASP ZAPを使用して説明をされていた。そして今回も親切にOWASP ZAPのセットアップもレクチャーされていた。
QWASP ZAPの機能たまにしか使わない物もあるから助かります...!
