academy CSRF 8問目 samesite strictをリダイレクトの穴とGETメソッドで回避

CSRF

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

コメント

タイトルとURLをコピーしました