Hello there, ('ω')ノ
すべてのリクエストは理にかなっているを。
脆弱性：
権限昇格
公開されたJWT生成エンドポイント
記事：
https://akshartank.medium.com/each-and-every-request-make-sense-4572b3205382
今回は、同じ組織内および組織間ですべての管理者アカウントに。
アクセスする方法について説明することに。
これは、開発者のコミュニティで非常によく知られている会社で行われて。
誰でも他人に署名するためのドキュメントを送信できるデジタル署名Webサイトで。
アプリケーションは、適切な役割を区別して。
役割間のリーク（特権昇格）を行わないことで、アクセス制御を適切に管理して。
通常のユーザには従来のCookieを使用して。
「X-admin-token」ヘッダで送信されたJWTを使用して管理者を識別して。
これは、正しく実装されている場合、ロールを管理するためのより良い方法で。
ただ、管理者が通常のユーザになることもできるという点が1つあって。
これがどのように起こっているのかという一連の疑問を引き起こしたので。
Burpを起動した後、管理者ユーザがCookieを使用しているにもかかわらず。
JWTを取得する方法に関するすべてのリクエストを読んだものの。
下記のようにユーザから管理者へのリクエストは。
組織に公開されているIDを提供するだけで、Cookieをチェックせずに。
管理者にJWTを提供していて。
したがって、どのユーザも自分のセッションでURLを実行するだけで。
JWTを取得できるので、ユーザはこのトークンを交換して。
「X-admin-token」を取得できて。
管理APIにアクセスできるかどうかを確認するために。
このトークンを確認しましたものの、アクセス制御ポリシーが添付されているので。
トークンは、ほとんどのAPIで機能せず。
さら、このトークンを使用できるいくつかのAPIを検索し始めると。
会社のドキュメントから多くのAPIを見つけて。
そのうちの１つが組織の請求の詳細を漏らしていて。
影響：
組織内の特権の昇格。
アカウントIDを知る必要がある組織間での特権の昇格。
これは、別会社の人間が署名するドキュメントを送信した際に知ることができて。
Best regards, (^^ゞ
