Hello there, ('ω')ノ
SameSite=laxクッキー制限を迂回してCSRFを実行し、不十分なメール確認メカニズムによる横方向の権限昇格を実現するを。
脆弱性：
CSRF
記事：
SameSite laxクッキー制限は、CSRFのバグを探しているときにいつも面倒で。
CSRF攻撃は常に狙っていたもので。
ほとんどの場合、XSS、CSRFなどのクライアント側の脆弱性は、
XSSベクトルをペーストしてアラートが表示されるのを待つだけで
簡単に探し出すことができ。
これは、ハッキングの旅を始めたばかりの人にとっては素晴らしいことですが、
1年以上のハッキング経験がある人がまだこの手法を使っていると、
少しがっかりして。
CSRF攻撃にも同じことが言えて。
例えば、ページがcsrfトークンで保護されていないフォームを使用している場合、
基本的なCSRFを構築することができ。
あるいは、一般的にいくつかの変わったアイディアを試してみることができ。
それでは、どのようにして、同じサイトのlaxクッキー制限やcsrfトークンを使用して
フォームを保護しているウェブサイトでCSRFバグを見つけ、
それを深刻なバグにエスカレートさせることができたのかを。
自国で最も人気のあるウェブサイトの一つを研究し始め。
このサイトは、車や技術機器などの商品の販売をはじめ、多くのことができ。
ユーザはアカウントを登録して、必要なものを検索するか、
自分の商品をアップロードして、アップロードしたものに関して
他の人と連絡を取ることができ。
最初にログインしたとき、Chromeが自動的にSame-Site=laxをセッションクッキーに
割り当てたことに気づき。
そこで、計画はクライアント側のセキュリティ問題を追い求めることであったため、
これが簡単ではないことをすぐに知り。
その上、セッションクッキーはHttpOnlyで。
そこで、ウェブアプリが他のデータをどのように扱っているかを研究し続け。
すべてのフォームがcsrfトークンを使用しており、XSSの試みが
すべて失敗していることを発見し。
すべてが適切にエンコードされ、エスケープされていて。
メールと電話番号の確認フォームを見てみると、これらのフォームは
csrfトークンで保護されていないことに気づき。
つまり、サーバに誰かが確認リンクのリクエストを行っていることを伝える以外に
フォームで何か特定のアクションを行うわけではないので、
なぜcsrfトークンを使用する必要があるのか。
しかし、あることに気づき。
そのリクエストは次のように見えて。
これは/email_verifyエンドポイントへのPOSTリクエストで、
アカウントを作成するために使用したメールを含んでいて。
もし自分がそのメールアドレスを別のメールアドレスに変更したらどうなるのか。
それをやったとき、驚いて。
自分が提供したメールアドレスにメール確認リンクが届き。
アカウントに関連付けられたメールはpinklad@wearehackerone.comでしたが、
/email_verify POSTリクエストのメールパラメータを変更しただけで、
deadoverflow@gmail.comにメール確認を受け取り。
これは確かにウェブアプリによる奇妙な振る舞いで。
しかし、これが最も驚くべき部分ではなく。
再びプロフィールを訪れたとき、自分のメールが変更されたことに気づき。
今、自分のメールはdeadoverflow@gmail.comで。
/email_verifyリクエストのメールパラメータを操作して、
自分のアカウントのメールアドレスを変更してみたが。
自分はまだ横方向の特権昇格を悪用するためには遠くあり。
自分で言及したように、ウェブサイトはSame-Site=laxを使用していたので、
別の起源から/email_verifyへのPOSTリクエストを送信すると、
ログインへのリダイレクトとなるかと。
それで、電話番号の確認も/tel_verify POSTリクエストの番号パラメータが
操作された場合、現在ログインしているアカウント上の電話番号の
上書きをもたらすだろうことに気づき。
その後、最終的に横方向の特権昇格の結果として期待することができ。
しかし、持っていた奇妙なアイディアのいくつかを試してみて。
そのうちの1つは、/email_verifyへのGETリクエストを、
クエリパラメータemail=attacker@example.comとともに送信することで。
そして、それは成功して。
リンクを開いただけで、自分のアカウントのメールアドレスを
pinklad@wearehackerone.comからattacker@example.comに変更して。
リンクを開くだけで被害者のアカウントのメールを
上書きすることができるバグを見つけ。
しかし、メールまたは電話番号が確認されていないユーザだけが、
このバグの被害者になる可能性があり。
また、何かを売ったり、買ったりするだけの通常のユーザは、
メールが確認されていないという事実に注目することはなく。
単純なエクスプロイトを作成って。
被害者がリンクを開くと、ボタンが表示され。
それをクリックすると、いくつかのことが起こり。
新しいウィンドウが開き、最初にメールアドレスが上書きされ。
次に電話番号が更新され、最後にユーザはyoutube.comにリダイレクトされ。
ボタンのインタラクションなしでメールを更新できただけでしたが、
メールと電話番号の両方を変更するために追加して。
被害者がリンクを開いたとき、実際に何が起こったのか。
今、攻撃者はメールpinklad0x00@wearehackerone.comのパスワードを
リセットするリクエストを行い、
そのパスワードを取得して被害者のアカウントにログインすることができ。
それで、攻撃者は被害者のアカウントを盗んで。
要するにバグを探したり、いくつかのバグを「使えない」とラベル付けして
エスカレートさせるのは難しいかも。
しかし、何かを悪用する方法を考えたり試したり、失敗したりすることは
まだセキュリティリサーチで。
バグを見つけられなくても、それでもリサーチで。
それを念頭に置いてみて。
ウェブアプリケーションに親しむこと、考えたことを試してみること、
アプリケーションがどのように反応するかを見ることは、
後でバグを見つけるのに役立ちます。他の人々のライトアップを読むことも
素晴らしいことで。
それは新しい技術を学ぶのを助け、知識を拡張することができ。
ここで見たように、保護され、すべてが安全であるように
見えるウェブアプリケーションでさえ、何か簡単なことでミスをすることができ。
だから、希望を失わずにハッキングを続けてみて。
Best regards, (^^ゞ
