Bug Bounty: Broken API Authorization から学ぶ

ソース:

medium.com

脆弱性API

 

訳:

プライベート プログラムで単純な API 認証のバグを発見した方法を共有したいと。
このバグにより、数千のサブドメインが影響を受け、アカウントの削除から乗っ取りや漏洩に至るまで、ユーザーの操作なしで保護されていない機能を悪用できるようになり。
限られた情報(フルネーム、電子メールID、雇用主)。 

 

Tl;dr: サーバーは、認可ベアラー トークンが通常のユーザーに属しているのか、パワーユーザーに属しているのかをチェックしていなく。

これはプライベート プログラムであるため、一部の情報は編集され、このサイトを「target.com」と呼び。

スキャンを実行していました dirsearch ざっと読んでいる間、バックグラウンドで
academy.target.com 、サイトの機能の概要を取得し。
次のような興味深いエンドポイントに気づきました: academy.target.com/api/docs
このようなエンドポイントには API ドキュメントがあり、リクエストとレスポンスの構造が指定されているため、宝の山で。

エンドポイントを参照すると、そのページが Swagger UI に非常によく似ていることがわかり(ただし、このサイトは Swagger を使用していませんでした)。
また、単に「認証」というボタンもあり、これをクリックするとログインページに移動しましたが、ログインしようとすると「アカウントが承認されていません」というメッセージが表示されて。

次のような興味深いエンドポイントがいくつかあり。

 

/poweruser/add
/poweruser/delete
/user/delete
/user/create
/user/user_logged_in
/user/profile

 

The page kinda looked like this.

これらのエンドポイントは内部/パワー ユーザーのみが使用するために予約されているように見えたので、これには不意を突かれ。
API トークンや認可ヘッダーを使用せずにエンドポイントを直接呼び出すと、次の結果が得られて。

 

An unsurprisingly disappointing response

この Web サイトでは API を提供していないようで、API トークンを生成する方法も見つからなかったので、後で確認することにし。
サイトを徹底的に検索した後も、リクエストまたはレスポンスで API トークンを 1 つも見つけることができず。
ただし、多くのリクエストに認証ベアラー トークンが含まれていることに気付き。

ヘッダーをコピーして、見つかった API エンドポイントへの呼び出しに含めることにして。
リクエストを使用して、そのパスワードを変更しようとしました POST への 別のアカウントを作成し、 api/user/edit


 

HTTP request to change another users password, this time with the bearer token.

 

Successful response lol.

ほら! それは魔法のようにうまくいき。
アカウントをパワーユーザーにエスカレーションすることを除けば、他のほぼすべての API エンドポイントを正常に呼び出すことができて。
ドキュメントには、新しいアカウントの削除/乗っ取り/作成やその他の悪いことをするために必要なパラメータが詳しく説明されて。 

 

ほなほな。