Introduction
As the internet evolves, so does the complexity of ensuring secure access and user authentication. Two widely-adopted standards that have come to the forefront are OAuth and OpenID Connect (OIDC). However, as with all technologies, they are not immune to vulnerabilities. This guide will delve into what these standards are, common security pitfalls associated with them, and how penetration testers can identify these issues.
Understanding OAuth and OpenID Connect
- OAuth: This is an open standard for access delegation, often utilized for token-based authentication. Essentially, OAuth provides client applications a ‘secure delegated access’ to server resources on behalf of the resource owner.
- OpenID Connect (OIDC): A simple identity layer built on top of the OAuth 2.0 protocol, OIDC allows clients to verify the identity of the user based on the authentication performed by an authorization server, and to obtain basic profile information about the user in an interoperable and REST-like manner.
Common Security Pitfalls and How to Identify Them
Insecure Implementation of Redirect URIs:
OAuth 2.0 relies on callback URLs or redirect URIs to return the user to the client application after successful authentication. If these URIs are insecurely implemented, an attacker can intercept or modify the authorization code or tokens.
Penetration testers should check if a system accepts wildcard redirect URIs or if it can be manipulated to redirect to a malicious site.
1. Acceptance of Wildcard Redirect URIs:
Identification Method: Check the OAuth client configuration to see if it accepts wildcard patterns (e.g., https://*.legitSite.com). If so, an attacker could register a domain that matches the pattern and intercept the authorization code or token.
Testing: Initiate an OAuth flow, and see if you can redirect to subdomains of an already approved domain.
2. Open Redirect Vulnerability:
Identification Method: If the application takes a user-provided URL and redirects the user to this URL after the OAuth flow, it might be susceptible to open redirect attacks. An attacker can craft a link that redirects users to a malicious site after the OAuth process.
Testing: Insert a third-party URL as the redirect URI. If the system accepts it and redirects the user to this third-party URL post-authentication, it’s vulnerable.
3. Domain Confusion attacks:
Identification Method: If the authorization server is vulnerable to domain confusion attacks on the redirect_uri parameter, then it might be possible to leak tokens outside of the allow list of redirect domains. For example, assuming the domain https://legit.com/* is configured in the allow list of of redirection, then supplying the value redirect_uri=https://[email protected] might be approved by the authorization server, but cause the browser to send the victim’s browser to evil.com thereby leaking the code.
Testing: Modify the redirect_uri to value that might cause domain confusion. checkout this list for some interesting payloads.
4. Lack of Strict Matching:
Identification Method: If the authorization server does not strictly match the provided redirect URI against a whitelist of previously registered URIs, there’s a risk. Some systems may only match a part of the URI or ignore certain parameters, which can be exploited.
Testing: Modify the redirect URI slightly (e.g., adding parameters or changing the case) and see if the system still accepts it. If it does, the system isn’t strictly verifying the redirect URIs.
5. Use of Non-HTTPS URIs:
Identification Method: If applications accept non-HTTPS (plain HTTP) redirect URIs, it can expose tokens to man-in-the-middle attacks.
Testing: Use an HTTP redirect URI during the OAuth process. If the system doesn’t raise errors and proceeds, it’s a security concern.
Cross-Site Request Forgery (CSRF) in OAuth:
Pitfall: Without the implementation of anti-CSRF tokens (like the state parameter in OAuth), attackers can trick a user into initiating an OAuth flow, potentially granting access to malicious apps.
Identification: Testers can initiate an OAuth flow and check if the state parameter is either missing or static across multiple requests. Additionaly, testers should try to change the value of the state parameter after the authorization sequence, and see if the client validates it. If no validation occurs, the client is likely susceptible the attack.
Lack of Token Bound to Audience:
Pitfall: Tokens not bound to a specific audience (or client) can be misused if intercepted.
Identification: Capture tokens during tests and attempt to use them for different clients or applications than originally intended.
Insufficient Token Scope Limitation:
Pitfall: Tokens that grant broad or unnecessary permissions expose more data or functionality if compromised.
Identification: Review the scope of tokens issued and attempt operations outside of the intended permission boundaries.
Misconfigured OIDC Tokens:
Pitfall: If OIDC tokens (like ID tokens) are misconfigured or not validated correctly, they could be spoofed or reused.
Identification: Try reusing ID tokens after logging out, or manipulate token claims to observe if the system blindly trusts the token.
Support of less secure 2.0 grant types
One significant pitfall that organizations often encounter is the support for outdated or less secure OAuth 2.0 grant types, notably the Implicit and Password (Resource Owner Password Credentials) flows.
Support of Implicit Flow:
Pitfall: In the Implicit flow, access tokens are directly passed through the URL fragment, increasing the risk of token exposure. Modern applications should favor the Authorization Code flow with Proof Key for Code Exchange (PKCE) instead.
Identification: During the authentication flow, penetration testers should observe if the access tokens are delivered directly to the user-agent without an intermediate authorization code. If found, this signals the use of the Implicit flow.
Support for Password Grant Flow:
Pitfall: This flow requires users to provide their credentials directly to clients, which can inadvertently train users to be susceptible to phishing attacks. Additionally, this practice doesn’t embrace token-based approaches and may expose user credentials to higher risks.
Identification: Testers should check if client applications directly request and handle user credentials. If clients handle and send usernames and passwords to the OAuth server and receive tokens in response, this indicates the use of the Password Grant flow.
Conclusion
OAuth and OpenID Connect offer robust frameworks for secure authentication and authorization, but their security is heavily reliant on correct implementation. For businesses, regularly conducting penetration testing and ensuring adherence to best practices is crucial to maintaining the integrity of these systems.
Want to learn more? Here are a few good sources that will help you get started:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
https://www.youtube.com/watch?v=ZV5yTm4pT8g&pp=ygUOb2F1dGggc2VjdXJpdHk%3D
https://www.youtube.com/watch?v=996OiexHze0&pp=ygUOb2F1dGggc2VjdXJpdHk%3D
https://www.youtube.com/watch?v=PfvSD6MmEmQ
https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660