ソース：
脆弱性：情報漏洩
訳：
導入
対象となったアプリケーションは、電話番号を使用してアカウントにログインまたはサインアップできるソーシャル ライブ ストリーミングアプリ。
アカウントを作成するには、指定された電話番号に送信された確認コードを入力する必要があり。
詳しく見てみましょう
私の頭に浮かんだ最初の考えは、応答操作メソッドを使用してこの検証コードを回避することで。
まず、電話番号を使用してアカウントを作成し、キャプチャを解決し。
確認コードが私の電話番号に送信されて。
私はその正しい 4 桁のコードを入力し、ゲップでこのリクエストをキャプチャし。
リクエストを右クリックし、 [ Do Intercept] -> [Response To This Request] を選択して。
このリクエストに対する応答は次のようになって。
任意の電話番号を使用してアカウントを再度作成し。
次に、ランダムな 4 桁のコードを入力し、ゲップでこの要求を傍受して。
そのリクエストに対するレスポンスをキャプチャし。
今回のレスポンス本文は次のようになって。
コードをバイパスするには、被害ユーザーに固有の詳細情報、ユーザー名、アカウントID、ホスト名、ポートが必要だったよう。
これらの詳細を確認するためにもう一度アプリケーションにアクセスし。
私はアプリケーションのページ ソースと [ストレージ] タブでそれらを探し始めま。
[ローカル ストレージ] タブに、ユーザー名、アカウント ID などのアカウント情報が表示されていることがわかり。
アプリケーションからログアウトして、ログアウト後も情報が表示されるかどうかを確認し。 しかし、うまくいかず。
で開き そのアプリケーションをブラウザーのプライベート ウィンドウ (または別のブラウザー) 、(ログインせずに) ローカル ストレージを再度確認し。 そしてなんと！
他のユーザーのユーザー名、アカウントID、ホスト名、ポート番号が見つかって。
アプリケーションは、認証されずに [ローカル ストレージ] タブで他のユーザーの情報 (毎回異なります) を公開していて。
次に、バープスイートでキャプチャした応答にアクセスして試して。 応答本文に示されている値に従って、提供された正しいコード (例: 「loginResult」: 「LOGGED_IN」) でパラメーター値を変更し。
そして、ローカル ストレージからユーザー固有の情報を入力し、応答を転送し。
わーい！ うまくいきました🤩🥳
確認コードを回避して他人のアカウントを入力してしまいました。
注: どのユーザー アカウントにもアクセスできませんでしたが、特定の時点でアプリ内でデータが公開されたユーザーにのみアクセスできました。 そのため、問題の重大度は P2 に引き下げられました。
ほなほな。
