Lab: SameSite Strict bypass via client-side redirect
今回の条件は、
1.samesite=strict
2.GETでCSRF受け付けてしまう
3.オープンリダイレクトの穴がある
です。
条件がそろえば、以下の手順で、CSRF攻撃が可能になる可能性があります。
ログインして
POST /login 見ると、samesite strict
メール変更して
POST /my-account/change-email 見ると、CSRFトークンらしきものがありません。
samesite=strictなので、外部から直接のCSRF攻撃は無理。（クッキーがクロスサイトでまたげないので）
このサイト内で、どこか中継できるような機能（オープンリダイレクトとか）ないかな？
他の機能を触っていると、
コメント書き込みのとき、数秒遅れて、ブログページに飛んでいるのを発見
オープンリダイレクトしてないかな？（してれば、外部サーバーからの中継に使えるので
GET /post/comment/confirmation?postId=1 を確認
レスポンスを見ると、
/resources/js/commentConfirmationRedirect.js というjsを呼んでいる
このJSソースをみると
GET /post/comment/confirmation?postId=1
のpostIdパラメータを使って、リダイレクトしている
やった！オープンリダイレクト！ 侵入起点発見。
試しに、GETで以下のリクエスト送ってみる
/post/comment/confirmation?postId=1/../../my-account
../../というのは、パストラ―バーサルのペイロードですね。（../が多すぎても一番上までいけば止まるので、適当につければいいと思います）
おおっ
/my-account
にリダイレクトされました
オープンリダイレクトが動くのが確認できました。
上記の操作をエクスプロイトサーバー（外部サーバー）からアクセスできるか確認
保存して、表示
こちらもちゃんと /my-accountにリダイレクトされました
これで、/post/comment/confirmation へのリクエストを外部サーバーから送っても、
samesite strictのクッキー制限を回避して、
/my-accountページにジャンプしていることを確認できました
次は、CSRF自体のバイパスです。
メソッドをGETに変えれないかやってみます。
メール変更のリクエスト POST /my-account/change-email をリピータに。
右クリック、Change request method して、メソッドをGETに変更して send
302かえって、メール変更成功
GETでいけました。
これを先程のオープンリダイレクトできるリクエストに追加
エクスプロイトサーバーのbodyにはりつけ、被害者に送信して、クリア!
strictだから安心と思いきや、オープンリダイレクトの穴を使って、中継されてしまってます。
オープンリダイレクトは、危険度が低いと評価するケースもあるようですが、
こういった踏み台に使えるので、やはり地道に封じていくべきなのかと思います。
–)v
コメント