ソース：
訳：
プログラム ポリシーを確認した後、アカウントを作成し、バックグラウンドで Burp Suite をオンにして、プログラムの性質とリクエストの種類を確認しました。
いつものように、プロファイル設定に移動すると、次のオプションが含まれていて。
- Change Username/Email/Phone
- Change Password
- Enable/Disable 2FA
そこで、すべてを試してみましたが、最後の 2 つのオプションはどちらもリクエストに CSRF トークンが含まれています。
しかし驚いたことに、「ユーザー名/電子メール/電話番号の変更」リクエストには CSRF トークンが含まれていませんでした。
私はこう思いました。
「彼らがこんなことを見逃すわけがない。もちろん、何らかの種類の Cookie 保護が行われる予定です。」
そこで、CSRF POC HTML ファイルを作成し、ブラウザで開きました。
出来上がり！ それはうまくいき 、被害者の電子メール/ユーザー名/電話番号を変更することができました。
電子メールの変更はアカウント乗っ取りにつながる可能性があります。
攻撃者がパスワードのリセット リンクを要求するだけで、そのリンクが新しい電子メール (攻撃者の電子メール) に配信され、アカウントが乗っ取られる可能性があります。
私はこの発見をすぐに報告しましたが、このプログラムは 2015 年に開始され、160 以上の解決済みレポートがあり、これが主要な領域であるため、これが見逃される可能性があることにショックを受けました。
翌日、チームからバグは再現できないという返答を受け取りました。
私は彼らに、それが私の側では機能することを伝え、別の POC を送りました。
なぜそれが彼ら側で機能しなかったのかを理解しようとして数時間試した後、Chrome がデフォルトで Cookie を SameSite=Lax として扱うため、問題は Chrome にあることがわかりました。
これは基本的に、Cookie がトップレベルのナビゲーション GET リクエスト (リンクのクリックなど) とともに送信されますが、クロスオリジン POST リクエスト (フォームによって作成されたリクエストなど) やクロスオリジンと一緒には送信されないことを意味します。 JavaScript によって開始されたリクエスト。
これは、サードパーティの Web サイトがユーザーの Cookie にアクセスする機能を低減することで、クロスサイト リクエスト フォージェリ (CSRF) やその他の種類の攻撃のリスクを軽減することを目的としたセキュリティ対策です。
これにより、CSRF 攻撃は、ユーザーが最近アカウントにログインしてから 2 分未満が経過した場合にのみ成功するようになり。
そのためFirefoxでは正常に動作しましたが、Chromeでは制限があって。
彼らはバグを優先順位付けし、翌日、CSRF がどのブラウザでも動作しないようにする修正を展開しました。
ほなほな。
