SlideShare a Scribd company logo

OAuth 2.0 Threat Landscape

•Download as PPTX, PDF•
•
Prabath Siriwardena
Prabath Siriwardena

The document discusses OAuth 2.0 security threats including session injection with CSRF, token leakage, token reuse/misuse, and token export. It provides details on the threats, victims, and best practices for mitigation. These include using short-lived authorization codes, TLS, proof-key-for-code-exchange, limiting grant types by client, white-listing redirect URIs, token binding, and enforcing throttle limits to prevent token misuse. The presentation encourages attendees to review their OAuth 2.0 implementations against these threats and ensure authorization servers follow security best practices.

1 of 31
SESSION ID: #RSAC Prabath Siriwardena OAUTH 2.0 THREAT LANDSCAPE IDY-W04 Senior Director of Security Architecture WSO2 @prabath
Presenter’s Company Logo – replace or delete on master slide # R S A C
#RSAC OAUTH 2.0 - A QUICK OVERVIEW
Presenter’s Company Logo – replace or delete on master slide # R S A C OAuth 2.0 4
Presenter’s Company Logo – replace or delete on master slide # R S A C Authorization Code Grant Type 5
Presenter’s Company Logo – replace or delete on master slide # R S A C Implicit Grant Type 6
Presenter’s Company Logo – replace or delete on master slide # R S A C Client Credentials Grant Type 7
Presenter’s Company Logo – replace or delete on master slide # R S A C Password Grant Type 8
#RSAC THREATS / MITIGATIONS / BEST PRACTICES
Presenter’s Company Logo – replace or delete on master slide # R S A C Session Injection with CSRF (Threats) 10
Presenter’s Company Logo – replace or delete on master slide # R S A C Session Injection with CSRF (Victims) 11 Web / Mobile application users
Presenter’s Company Logo – replace or delete on master slide # R S A C Session Injection with CSRF (Mitigation / Best Practices) 12 Short-lived authorization code Use state parameter Proof-key-for-code-exchange (PKCE)
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Threats) 13 Attacker may attempt to eavesdrop authorization code/access token/refresh token in transit. Authorization Code Flow Open Redirector OAuth 2.0 native apps can get hold of the authorization code.
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Threats) 14 Attacker may attempt a brute force attack to crack the authorization code/access token. Attacker may attempt to steal the authorization code/access token/refresh token stored in the authorization server. IdP Mix-Up / Malicious Endpoint.
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Victims) 15 Web/Mobile application users Web/Mobile application owners
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 16 Always on TLS (use TLS 1.2 or later) Address all the TLS level vulnerabilities both at the client, authorization server and the resource server. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence.
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 17 Never store tokens in clear text - but the salted hash. Short-lived tokens. LinkedIn has an expiration of 30 seconds for its authorization codes. The token expiration time would depend on the following parameters. Risk associated with token leakage Duration of the underlying access grant Time required for an attacker to guess or produce a valid token
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 18 One-time authorization code One-time access token (implicit grant type) Use PKCE (proof key for code exchange) to avoid authorization code interception attack. Have S256 as the code challenge method Enforce standard SQL injection countermeasures
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 19 Avoid using the same client_id/client_secret for each instance of a mobile app - rather use the Dynamic Client Registration API to generate a key pair per instance. Most of the time the leakage of authorization code becomes a threat when the attacker is in hold of the client id and client secret. Restrict grant types by client. Most of the authorization servers do support all core grant types. If unrestricted, leakage of client id/client secret gives the attacker the opportunity obtain an access token via client credentials grant type.
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 20 Enable client authentication via a much secured manner. JWT client assertions TLS mutual authentication Have a key of size 2048 bits or larger if RSA algorithms are used for the client authentication Have a key of size 160 bits or larger if elliptic curve algorithms are used for the client authentication
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 21 White-list callback URLs (redirect_uri) The absolute URL or a regEx pattern IdP-Mixup Use different callback URLs by IdP https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Threats) 22 A malicious resource could reuse an access token used to access itself by a legitimate client to access another resource, impersonating the original client
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Threats) 23 An evil web site gets an access token from a legitimate user, can reuse it at another web site (which trusts the same authorization server) with the implicit grant type https://target-app/callback?access_token=<access_token> A legitimate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausting server resources.
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Victims) 24 Web/Mobile application users Web/Mobile application owners
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Mitigations / Best Practices) 25 A malicious resource (an API / Microservice) could reuse an access token used to access itself by a legitimate client to access another resource, impersonating the original client. An evil web site gets an access token from a legitimate user, can reuse it at another web site (which trusts the same authorization server) with the implicit grant type https://target-app/callback?access_token=<access_token>
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Mitigations / Best Practices) 26 A legitimate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausting server resources. To avoid exhausting resources at the server side, enforce throttle limits by user by application. In case an attacker wants to misuse a token - the worst he/she can do is to eats his/her own quota.
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Export (Threats) 27 An attacker could export an access token from its originating channel and use somewhere else. A common attack vector for SPAs (Single Page Applications) A major concerns with bearer tokens.
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Export (Victims) 28 Web/Mobile application users Web/Mobile application owners
Presenter’s Company Logo – replace or delete on master slide # R S A C Token Export (Mitigations / Best Practices) 29 The use of Token Binding protects access tokens from man-in-the- middle and token export and replay attacks. https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
Presenter’s Company Logo – replace or delete on master slide # R S A C Apply What You Have Learned Today! 30 Review and test current OAuth 2.0 client applications against the threats we discussed – probably build a test suite! Build a security check-list for an OAuth 2.0 Authorization Server, and make sure what you build or what you buy, adheres to it. Be the security champion of your team!
#RSAC THANK YOU!

More Related Content

OAuth 2.0 Threat Landscape

  • 1. SESSION ID: #RSAC Prabath Siriwardena OAUTH 2.0 THREAT LANDSCAPE IDY-W04 Senior Director of Security Architecture WSO2 @prabath
  • 2. Presenter’s Company Logo – replace or delete on master slide # R S A C
  • 3. #RSAC OAUTH 2.0 - A QUICK OVERVIEW
  • 4. Presenter’s Company Logo – replace or delete on master slide # R S A C OAuth 2.0 4
  • 5. Presenter’s Company Logo – replace or delete on master slide # R S A C Authorization Code Grant Type 5
  • 6. Presenter’s Company Logo – replace or delete on master slide # R S A C Implicit Grant Type 6
  • 7. Presenter’s Company Logo – replace or delete on master slide # R S A C Client Credentials Grant Type 7
  • 8. Presenter’s Company Logo – replace or delete on master slide # R S A C Password Grant Type 8
  • 9. #RSAC THREATS / MITIGATIONS / BEST PRACTICES
  • 10. Presenter’s Company Logo – replace or delete on master slide # R S A C Session Injection with CSRF (Threats) 10
  • 11. Presenter’s Company Logo – replace or delete on master slide # R S A C Session Injection with CSRF (Victims) 11 Web / Mobile application users
  • 12. Presenter’s Company Logo – replace or delete on master slide # R S A C Session Injection with CSRF (Mitigation / Best Practices) 12 Short-lived authorization code Use state parameter Proof-key-for-code-exchange (PKCE)
  • 13. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Threats) 13 Attacker may attempt to eavesdrop authorization code/access token/refresh token in transit. Authorization Code Flow Open Redirector OAuth 2.0 native apps can get hold of the authorization code.
  • 14. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Threats) 14 Attacker may attempt a brute force attack to crack the authorization code/access token. Attacker may attempt to steal the authorization code/access token/refresh token stored in the authorization server. IdP Mix-Up / Malicious Endpoint.
  • 15. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Victims) 15 Web/Mobile application users Web/Mobile application owners
  • 16. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 16 Always on TLS (use TLS 1.2 or later) Address all the TLS level vulnerabilities both at the client, authorization server and the resource server. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence.
  • 17. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 17 Never store tokens in clear text - but the salted hash. Short-lived tokens. LinkedIn has an expiration of 30 seconds for its authorization codes. The token expiration time would depend on the following parameters. Risk associated with token leakage Duration of the underlying access grant Time required for an attacker to guess or produce a valid token
  • 18. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 18 One-time authorization code One-time access token (implicit grant type) Use PKCE (proof key for code exchange) to avoid authorization code interception attack. Have S256 as the code challenge method Enforce standard SQL injection countermeasures
  • 19. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 19 Avoid using the same client_id/client_secret for each instance of a mobile app - rather use the Dynamic Client Registration API to generate a key pair per instance. Most of the time the leakage of authorization code becomes a threat when the attacker is in hold of the client id and client secret. Restrict grant types by client. Most of the authorization servers do support all core grant types. If unrestricted, leakage of client id/client secret gives the attacker the opportunity obtain an access token via client credentials grant type.
  • 20. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 20 Enable client authentication via a much secured manner. JWT client assertions TLS mutual authentication Have a key of size 2048 bits or larger if RSA algorithms are used for the client authentication Have a key of size 160 bits or larger if elliptic curve algorithms are used for the client authentication
  • 21. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Leakage (Mitigation / Best Practices) 21 White-list callback URLs (redirect_uri) The absolute URL or a regEx pattern IdP-Mixup Use different callback URLs by IdP https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01
  • 22. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Threats) 22 A malicious resource could reuse an access token used to access itself by a legitimate client to access another resource, impersonating the original client
  • 23. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Threats) 23 An evil web site gets an access token from a legitimate user, can reuse it at another web site (which trusts the same authorization server) with the implicit grant type https://target-app/callback?access_token=<access_token> A legitimate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausting server resources.
  • 24. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Victims) 24 Web/Mobile application users Web/Mobile application owners
  • 25. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Mitigations / Best Practices) 25 A malicious resource (an API / Microservice) could reuse an access token used to access itself by a legitimate client to access another resource, impersonating the original client. An evil web site gets an access token from a legitimate user, can reuse it at another web site (which trusts the same authorization server) with the implicit grant type https://target-app/callback?access_token=<access_token>
  • 26. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Reuse/Misuse (Mitigations / Best Practices) 26 A legitimate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausting server resources. To avoid exhausting resources at the server side, enforce throttle limits by user by application. In case an attacker wants to misuse a token - the worst he/she can do is to eats his/her own quota.
  • 27. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Export (Threats) 27 An attacker could export an access token from its originating channel and use somewhere else. A common attack vector for SPAs (Single Page Applications) A major concerns with bearer tokens.
  • 28. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Export (Victims) 28 Web/Mobile application users Web/Mobile application owners
  • 29. Presenter’s Company Logo – replace or delete on master slide # R S A C Token Export (Mitigations / Best Practices) 29 The use of Token Binding protects access tokens from man-in-the- middle and token export and replay attacks. https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
  • 30. Presenter’s Company Logo – replace or delete on master slide # R S A C Apply What You Have Learned Today! 30 Review and test current OAuth 2.0 client applications against the threats we discussed – probably build a test suite! Build a security check-list for an OAuth 2.0 Authorization Server, and make sure what you build or what you buy, adheres to it. Be the security champion of your team!

Editor's Notes

  1. The attacker tries to log into the target website (OAuth 2.0 client) with his account at the corresponding identity provider. The attacker blocks the redirection to the target web site, and captures the authorization code. The target web site never sees the code. The attacker constructs the callback URL for the target site - and lets the victim, clicks on it. The victim logs into the target web site, with the account attached to the attacker - and adds credit card information. The attacker too logs into the target website with his/her valid credentials and uses victim’s credit card to buy goods.