Hello there, ('ω')ノ
AuthTokenを使用したAPIの活用を。
脆弱性：
トークンリーク
情報開示
記事：
https://rafi-ahamed.medium.com/exploiting-api-with-authtoken-3bea7b1fb6a9
ツール：
Burp Suite
今回は、AuthTokenを使用したAPIエンドポイントの活用に関するもので。
偵察プロセスで、AuthTokenを見つけましたものの。
影響を示すことができず。
APIとは：
APIは、Application Programming Interfaceの頭字語で。
２つのアプリケーションが相互に通信できるようにするソフトウェア仲介で。
Facebookなどのアプリを使用したり、インスタントメッセージを送信したり。
スマートフォンで天気を確認したりするたびに、APIを使用していて。
仮に偵察プロセスで任意のユーザのAuthToken、またはAPIトークンが見つかっても。
ほとんどの場合、該当しないと報告するだけで。
AuthTokenを介したAPIの活用：
最近、Bugcrowdでプライベートプログラムをテストしていると。
偵察プロセスで、常に手に入るAuthTokenを見つけたものの。
難しいのは、それを悪用することで。
まず第一に、プログラムはテスト用のクレデンシャルを提供せず。
サインアップする方法もないので。
インフラストラクチャが実際にどのように機能するのかわからず。
偵察で見つけたトークンは、APIが認証に使用するAuthentication Bearerトークンの。
代わりになる可能性のあるAuthToken（コードで記述された）で。
これで、トークンがAPIトークンに似ているというヒントが得られて。
しかしながら、ユーザアカウントなどにアクセスできなかったために。
APIインフラストラクチャがどのように機能するのかわからなかったので。
あきらめることに。
次に別のWebアプリケーションをテストしているときに。
ユーザ情報を更新するときにAPI呼び出しが表示されて。
このAPI呼び出しを使用することで。
昨日のAPI呼び出しを悪用できるのではないかと思ったので。
Burpを使用してそのリクエストをRepeaterに送信して。
ホストとリクエストのエンドポイントを。
偵察プロセスで見つけたものに変更すると。
POST /v3/xxxxx
Host: api.xxxxx
下記のような403 forbiddenの応答が。
これにより、どのヘッダが欠落しているかについての情報が得られて。
xxxxxAuth
次に、応答が示したヘッダー名を使用して取得したトークンを追加すると。
500 Internal Server Error応答が。
つまり、APIに接続できたということで。
下記のとおり、リクエストはPOSTであってリクエストにPOSTデータはなくて。
そのため、アプリケーションで500 Internal Server Errorが表示されていて。
さらに偵察して、エンドポイントのテストに使用できるPOSTデータを取得して。
POSTデータを追加してリクエストを再度送信してみると。
100人のクライアントのデータにアクセスできて。
Best regards, (^^ゞ
