ソース：
脆弱性：RaceCondition、BAC
訳：
このレポートでは、ターゲット Web サイトで発見された 2 つの脆弱性、競合状態とアクセス制御 (BAC) の問題を明らかにして。
つまり、ターゲットは自己ホスト型プログラムであり、報酬は Critical、High、Medium のみで。
サブドメインの列挙からテストを開始し、ライブサブドメインを除外し。
サブドメインを 1 つずつテストした後、ログイン/登録機能のある「developer.target.com」の開発者ダッシュボードを見つけ。
ただし、ログインはメインドメイン「target.com」から行う必要があり、その場合のみユーザーが開発者ダッシュボードにリダイレクトされて。
ここから実際のテストが始まり。
ダッシュボードの [マイ アプリ] タブをクリックすると、ユーザーが SDK アプリの構築をリクエストし、REST API にアクセスするためのフォームが開き。
フォームには、名前、電子メール、会社の URL、その他多くのフィールドを含むさまざまなフィールドが含まれていて。
フォームはログインしたアカウントからアクセスされたため、電子メールフィールドにはログインしたユーザーの電子メールアドレスが自動的に入力され。
したがって、ユーザーはランダムな電子メール アドレスやその他の電子メールアドレスを提供することはできず。
しかし、リクエストを傍受し、被害者の電子メールに変更すると、その後、被害者に代わってフォームが送信されることになり。
その後、被害者はフォームの送信が成功したことを示す確認メールを受け取り。
これだけでなく、被害者の電子メールからリクエストの送信が成功した場合、リクエストフォームは 1 つのアカウントに対して 1 回のみ利用可能であるため、被害者は自分側から別のフォームリクエストを送信することはできません。
この BAC により、被害者はアプリを作成したり、新しいアプリの作成をリクエストしたりすることができません。
上記の文でお気づきかと思いますが、フォームの送信はアカウントに対して 1 回限りであると述べました。
フォームが一度正常に送信された場合、URL にアクセスすると、次のように表示されることを意味します。
また、ユーザーはフォームを 2 回送信することはできず。
ここで競合状態の脆弱性をテストしてみてはいかがでしょうか。
次に、げっぷ履歴に移動して、そのフォーム送信リクエストを Burp 侵入者に送信し、同時リクエストを 1 秒あたり 100 リクエストに設定し。
攻撃が成功した後、確認メールがないかメールをチェックし。
そして、500 件の同時リクエストのうち、約 250 件のリクエストが成功したことを推測でき。
また、アカウントごとに複数のアプリ リクエスト フォームを送信することができて。
ほなほな。
