しばらく調べていなかったのでまた調査を再開しました。
今回は少し前に見つけたUberの脆弱性。

ホワイトハッカーの方が2019年に見つけてUberに報告し、Uber側で既に修正済み。
ホワイトハッカーの方の脆弱性報告はどういう仕組みの脆弱性だったかまで明かしてくれるので、勉強になります。

脆弱性の内容

ドライバー側が使用しているAPIと乗車ユーザー側のAPIを組み合わせると、電話番号からユーザーの情報を全て参照できるようになってしまっていました。

ステップは以下の通り。

1. ドライバ側APIで任意の電話番号を検索

2. レスポンスから該当ユーザーのUUIDを取得

3. ユーザー側APIにリクエストを送る。この時UUIDがわかればCookieのフォーマットが作成できるようになってしまっていた

詳しい説明はサイトやサイトからリンクされた動画でご確認ください。
[The vulnerable Uber API] のリクエストサンプルの最後、Cookieのところにフォーマットがあります。これUUID差し替えたら別のユーザーのトークンとして機能してしまいますよね。

OWASP Top 10の方にはこの脆弱性があった

これはOWASP API Security Top 10の方では分かりにくいのですが、APIのほうではなくWeb全般のTop 10であるOWASP Top 10の方では長いことランクインしている脆弱性なんです。

2017年版では「Insecure Deserialization」のカテゴリに分類されるもので、最新の2021年版では「Software and Data Integrity Failure」に名前が変更されています。

CookieやTokenのフォーマットがわかりやすいものであればあるほど、偽造も簡単です。
類似事例では例えばCookieの中にRole (Admin/User) が書かれており、本来User権限のユーザーであってもCookieの中身をAdminに書き換えるとAdmin権限でアクセスできてしまうといった事例などがありました。

報告からの対応スピード！

この報告ではさらに対応スピードが記録されています。

4/19にUberに報告されたものが、4/26には修正されています。

ここから先は単なる推測です。

UberがCookieにUUIDを入れたのは、アイデンティティ情報をバックエンドのマイクロサービス側に引き回したかったのではないかと思うんです。もしそうであれば単なるCookieのフォーマット修正ではなく、バックエンド側マイクロサービスのアイデンティティ情報の読み取りの仕組みまであちらこちら修正しないといけないはずです。

もし推測が正しければこれはかなりのボリュームの修正をこの短期間で修正していることになります。
報奨金の金額も合わせてUberがいかに外部からの脆弱性報告の対応プロセスを確立しており、本気で取り組んでいるがわかりますね。