IDOR Vulnerability in OAuth Flow

[22521661-ship-it]

Problem

• The findOAuthProvider function only checks if an OAuth provider exists and is enabled.
• It does not verify if the current user is authorized to use that specific OAuth provider
• Any authenticated or unauthenticated user can manipulate the id parameter in /oauth/{id} to access any configured OAuth provider

Location

-Line 177, file: "/modules/restserver/src/main/scala/sharry/restserver/routes/LoginRoutes.scala"

Exploitability

If system has multiple OAuth providers configured:

• google (public, meant for all users)
• github-enterprise (internal, for developers only)
• okta-admin (admin-only provider) An attacker can initiate an OAuth flow with the admin provider (okta-admin) despite the user having no authorization

Impact

-Privilege escalation: Regular users can access admin-only authentication flows -Account enumeration: Attackers can probe for valid OAuth provider IDs

[eikek]

Hi @22521661-ship-it thanks for the report. I think I can't follow, though. The configured providers are ways you could possibly login to sharry. It's for having multiple buttons "login via google", "login via github" etc. Do you mind explaining how the exploit can be done? How would you list accounts on say "okta-admin" if you are a random google user? Also, you don't need to do extra effort probing for oauth provider ids - you can just use the appconfig endpoint.

[vien2024]

**The Vulnerability: The findOAuthProvider function only checks if a provider exists and is enabled - it doesn't verify if the current user is authorized to use that specific provider.

**The Attack Flow: A regular user visits /oauth/google - this works as intended The same user (or an attacker) changes the URL to /oauth/okta-admin The findOAuthProvider function finds the okta-admin provider and confirms it's enabled The OAuth flow begins with the admin-only provider, even though the user shouldn't have access to it

Without this check, users can potentially: Trigger authentication flows they shouldn't have access to Potentially access systems or identity providers meant for different user classes Create unintended security paths in your authentication system

[eikek]

The OAuth flow begins with the admin-only provider, even though the user shouldn't have access to it

I don't understand the problem. The "admin only" provider takes care to only validate admins. Same way google takes care to only authenticate valid google users. Everyone can initiate an oauth flow, only the provider then tells whether someone could actually successfully authenticate there.

Without this check, users can potentially: Trigger authentication flows they shouldn't have access to

How can you tell which user is using which provider? How would you implement this check?

Potentially access systems or identity providers meant for different user classes

Please show me an example how this is done. Which systems do you mean?

Create unintended security paths in your authentication system

I don't understand what this means. What paths can you create?

I still don't understand the issue. Perhaps you can create a video or something that shows how a regular google user is successfully authenticated on a different provider without being registered there or have valid credentials.