ソース：
脆弱性：ATO
訳：
偵察:
まず偵察から始めましょう。
プログラムの範囲はメインの Web サイトとモバイル アプリのみで。
モバイル アプリ API をテストしたところ、多数のバグが見つかり。
次に、サブドメインをテストして、メインの Web サイト/モバイル アプリに影響を与える可能性のある重大な脆弱性を見つけようと。
別のデータベースを持つステージング サブドメインを見つけたので、メイン アプリの資格情報を使用してログインしてそれを確認し。
次に、脆弱性の説明に。
脆弱性:
この脆弱性自体が悪用するのは簡単ですが、まずこの脆弱性がどのように機能するかを理解し。
問題は、開発者がステージとメイン サイトに同じ署名と JWT 構造を使用したため、ランダムなアカウント乗っ取りが発生し、stg-redacted.com で作成されたアカウント JWT を redacted.com で使用すると、設定ミスにより有効になってしまうことで。
それは開発者によって行われ。
そこで、重大な脆弱性を見つけようとしたときにすぐにこれを思いつき、ステージング アプリで作成されたすべてのユーザーが同じ構造の連続した ID を持っていることに気付いて。
次に、すぐにアカウントを作成し、作成したアカウントの JWT をコピーし。
応答にあるように、ID は [1000987] で。
ステージング アプリの JWT をコピーしてメイン アプリに貼り付けると、ステージング アプリのアカウントと同じユーザー ID [1000987] のランダムなアカウントでログインされて。
添付の画像は、ステージング アプリの同じユーザー ID を持つランダム ユーザーによる PoC を示していて。
どのユーザー ID を引き継ぐかは基本的に制御できないため、なぜランダムなアカウント乗っ取りなのか疑問に思うかも。
ただし、アプリが破壊される可能性があるため、これは大量乗っ取りと呼ばれる可能性があり。
言い忘れていましたが、ターゲットが環境をどのように構成するかによって、メイン Web サイトとモバイル アプリで同じ JWT を使用できて。
再現する手順：
- ステージング環境に移動する
- アカウント登録: 詳細情報を入力してサインアップ プロセスを完了し。
新しいアカウントに割り当てられた連続 ID をメモします (例: ID)。1000987. - 認証トークンの抽出: 登録とログインが成功した後、ブラウザの開発者ツールにアクセスするか、API 応答を検査して認証トークンを見つけます。
Authorizationトークン。
をコピーしますAuthorization次のステップのトークン。 - メイン サイトでのアカウントの乗っ取り: メイン サイトに移動し。
ブラウザの開発者ツールまたは API テスト ツールを使用して、既存のAuthorizationトークンをステージング環境からコピーしたトークンと置き換え。 - 認証が必要な機能にアクセスし。
特定の ID を持つユーザーとして認証されたことがわかり。1000987ステージング環境から、メイン環境のランダムなアカウントを効果的に引き継ぎ。
修復:
開発者は、異なる環境で JWT に署名するために異なるシークレットを使用する必要があって。
この変更により、ある環境のトークンを別の環境では使用できなくなり。
ほなほな。
