SlideShare a Scribd company logo

OAuth 2.0 Threat Landscapes

•
•
Priyanka Aash
Priyanka Aash

OAuth 2.0 is at the heart of OpenID Connect, Mobile Connect, UMA and many other popular standards. Understanding the threat landscapes in OAuth 2.0 is essential in building a secured identity infrastructure. This talk will guide you through multiple attacks that took place over last couple of years, their root causes and how to mitigate any future security exploits by following best practices. Learning Objectives: 1: Learn OAuth 2.0 fundamentals. 2: Understand what can go wrong with OAuth 2.0 implementation. 3: Explore security best practices and guidelines. (Source: RSA Conference USA 2018)

1 of 31
Download to read offline
SESSION ID: #RSAC Prabath Siriwardena OAUTH 2.0 THREAT LANDSCAPES IDY-W04 Senior Director of Security Architecture WSO2 @prabath
Presenter’s Company Logo – replace or delete on master slide #RSAC
#RSAC OAUTH 2.0 - A QUICK OVERVIEW
Presenter’s Company Logo – replace or delete on master slide #RSAC OAuth 2.0 4
Presenter’s Company Logo – replace or delete on master slide #RSAC AuthorizaAon Code Grant Type 5
Presenter’s Company Logo – replace or delete on master slide #RSAC Implicit Grant Type 6
Presenter’s Company Logo – replace or delete on master slide #RSAC Client CredenAals Grant Type 7
Presenter’s Company Logo – replace or delete on master slide #RSAC Password Grant Type 8
#RSAC THREATS / MITIGATIONS / BEST PRACTICES
Presenter’s Company Logo – replace or delete on master slide #RSAC Session InjecAon with CSRF (Threats) 10
Presenter’s Company Logo – replace or delete on master slide #RSAC Session InjecAon with CSRF (VicAms) 11 Web / Mobile applicaAon users
Presenter’s Company Logo – replace or delete on master slide #RSAC Session InjecAon with CSRF (MiAgaAon / Best PracAces) 12 Short-lived authorizaAon code Use state parameter Proof-key-for-code-exchange (PKCE)
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (Threats) 13 A[acker may a[empt to eavesdrop authorizaAon code/access token/ refresh token in transit. AuthorizaAon Code Flow Open Redirector OAuth 2.0 naAve apps can get hold of the authorizaAon code.
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (Threats) 14 A[acker may a[empt a brute force a[ack to crack the authorizaAon code/access token. A[acker may a[empt to steal the authorizaAon code/access token/ refresh token stored in the authorizaAon server. IdP Mix-Up / Malicious Endpoint.
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (VicAms) 15 Web/Mobile applicaAon users Web/Mobile applicaAon owners
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 16 Always on TLS (use TLS 1.2 or later) Address all the TLS level vulnerabiliAes both at the client, authorizaAon 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 #RSAC Token Leakage (MiAgaAon / Best PracAces) 17 Never store tokens in clear text - but the salted hash. Short-lived tokens. LinkedIn has an expiraAon of 30 seconds for its authorizaAon codes. The token expiraAon Ame would depend on the following parameters. Risk associated with token leakage DuraAon of the underlying access grant Time required for an a[acker to guess or produce a valid token
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 18 One-Ame authorizaAon code One-Ame access token (implicit grant type) Use PKCE (proof key for code exchange) to avoid authorizaAon code intercepAon a[ack. Have S256 as the code challenge method Enforce standard SQL injecAon countermeasures
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 19 Avoid using the same client_id/client_secret for each instance of a mobile app - rather use the Dynamic Client RegistraAon API to generate a key pair per instance. Most of the Ame the leakage of authorizaAon code becomes a threat when the a[acker is in hold of the client id and client secret. Restrict grant types by client. Most of the authorizaAon servers do support all core grant types. If unrestricted, leakage of client id/client secret gives the a[acker the opportunity obtain an access token via client credenAals grant type.
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 20 Enable client authenAcaAon via a much secured manner. JWT client asserAons TLS mutual authenAcaAon Have a key of size 2048 bits or larger if RSA algorithms are used for the client authenAcaAon Have a key of size 160 bits or larger if ellipAc curve algorithms are used for the client authenAcaAon
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 21 White-list callback URLs (redirect_uri) The absolute URL or a regEx pa[ern IdP-Mixup Use different callback URLs by IdP h[ps://tools.iej.org/html/drak-iej-oauth-mix-up-miAgaAon-01
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (Threats) 22 A malicious resource could reuse an access token used to access itself by a legiAmate client to access another resource, impersonaAng the original client
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (Threats) 23 An evil web site gets an access token from a legiAmate user, can reuse it at another web site (which trusts the same authorizaAon server) with the implicit grant type h[ps://target-app/callback?access_token=<access_token> A legiAmate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausAng server resources.
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (VicAms) 24 Web/Mobile applicaAon users Web/Mobile applicaAon owners
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (MiAgaAons / Best PracAces) 25 A malicious resource (an API / Microservice) could reuse an access token used to access itself by a legiAmate client to access another resource, impersonaAng the original client. An evil web site gets an access token from a legiAmate user, can reuse it at another web site (which trusts the same authorizaAon server) with the implicit grant type h[ps://target-app/callback?access_token=<access_token>
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (MiAgaAons / Best PracAces) 26 A legiAmate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausAng server resources. To avoid exhausAng resources at the server side, enforce thro[le limits by user by applicaAon. In case an a[acker 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 #RSAC Token Export (Threats) 27 An a[acker could export an access token from its originaAng channel and use somewhere else. A common a[ack vector for SPAs (Single Page ApplicaAons) A major concerns with bearer tokens.
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Export (VicAms) 28 Web/Mobile applicaAon users Web/Mobile applicaAon owners
Presenter’s Company Logo – replace or delete on master slide #RSAC Token Export (MiAgaAons / Best PracAces) 29 The use of Token Binding protects access tokens from man-in-the- middle and token export and replay a[acks. h[ps://tools.iej.org/html/drak-jones-oauth-token-binding-00
Presenter’s Company Logo – replace or delete on master slide #RSAC Apply What You Have Learned Today! 30 Review and test current OAuth 2.0 client applicaAons against the threats we discussed – probably build a test suite! Build a security check-list for an OAuth 2.0 AuthorizaAon 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 Landscapes

  • 1. SESSION ID: #RSAC Prabath Siriwardena OAUTH 2.0 THREAT LANDSCAPES IDY-W04 Senior Director of Security Architecture WSO2 @prabath
  • 2. Presenter’s Company Logo – replace or delete on master slide #RSAC
  • 3. #RSAC OAUTH 2.0 - A QUICK OVERVIEW
  • 4. Presenter’s Company Logo – replace or delete on master slide #RSAC OAuth 2.0 4
  • 5. Presenter’s Company Logo – replace or delete on master slide #RSAC AuthorizaAon Code Grant Type 5
  • 6. Presenter’s Company Logo – replace or delete on master slide #RSAC Implicit Grant Type 6
  • 7. Presenter’s Company Logo – replace or delete on master slide #RSAC Client CredenAals Grant Type 7
  • 8. Presenter’s Company Logo – replace or delete on master slide #RSAC Password Grant Type 8
  • 9. #RSAC THREATS / MITIGATIONS / BEST PRACTICES
  • 10. Presenter’s Company Logo – replace or delete on master slide #RSAC Session InjecAon with CSRF (Threats) 10
  • 11. Presenter’s Company Logo – replace or delete on master slide #RSAC Session InjecAon with CSRF (VicAms) 11 Web / Mobile applicaAon users
  • 12. Presenter’s Company Logo – replace or delete on master slide #RSAC Session InjecAon with CSRF (MiAgaAon / Best PracAces) 12 Short-lived authorizaAon code Use state parameter Proof-key-for-code-exchange (PKCE)
  • 13. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (Threats) 13 A[acker may a[empt to eavesdrop authorizaAon code/access token/ refresh token in transit. AuthorizaAon Code Flow Open Redirector OAuth 2.0 naAve apps can get hold of the authorizaAon code.
  • 14. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (Threats) 14 A[acker may a[empt a brute force a[ack to crack the authorizaAon code/access token. A[acker may a[empt to steal the authorizaAon code/access token/ refresh token stored in the authorizaAon server. IdP Mix-Up / Malicious Endpoint.
  • 15. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (VicAms) 15 Web/Mobile applicaAon users Web/Mobile applicaAon owners
  • 16. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 16 Always on TLS (use TLS 1.2 or later) Address all the TLS level vulnerabiliAes both at the client, authorizaAon 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 #RSAC Token Leakage (MiAgaAon / Best PracAces) 17 Never store tokens in clear text - but the salted hash. Short-lived tokens. LinkedIn has an expiraAon of 30 seconds for its authorizaAon codes. The token expiraAon Ame would depend on the following parameters. Risk associated with token leakage DuraAon of the underlying access grant Time required for an a[acker to guess or produce a valid token
  • 18. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 18 One-Ame authorizaAon code One-Ame access token (implicit grant type) Use PKCE (proof key for code exchange) to avoid authorizaAon code intercepAon a[ack. Have S256 as the code challenge method Enforce standard SQL injecAon countermeasures
  • 19. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 19 Avoid using the same client_id/client_secret for each instance of a mobile app - rather use the Dynamic Client RegistraAon API to generate a key pair per instance. Most of the Ame the leakage of authorizaAon code becomes a threat when the a[acker is in hold of the client id and client secret. Restrict grant types by client. Most of the authorizaAon servers do support all core grant types. If unrestricted, leakage of client id/client secret gives the a[acker the opportunity obtain an access token via client credenAals grant type.
  • 20. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 20 Enable client authenAcaAon via a much secured manner. JWT client asserAons TLS mutual authenAcaAon Have a key of size 2048 bits or larger if RSA algorithms are used for the client authenAcaAon Have a key of size 160 bits or larger if ellipAc curve algorithms are used for the client authenAcaAon
  • 21. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Leakage (MiAgaAon / Best PracAces) 21 White-list callback URLs (redirect_uri) The absolute URL or a regEx pa[ern IdP-Mixup Use different callback URLs by IdP h[ps://tools.iej.org/html/drak-iej-oauth-mix-up-miAgaAon-01
  • 22. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (Threats) 22 A malicious resource could reuse an access token used to access itself by a legiAmate client to access another resource, impersonaAng the original client
  • 23. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (Threats) 23 An evil web site gets an access token from a legiAmate user, can reuse it at another web site (which trusts the same authorizaAon server) with the implicit grant type h[ps://target-app/callback?access_token=<access_token> A legiAmate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausAng server resources.
  • 24. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (VicAms) 24 Web/Mobile applicaAon users Web/Mobile applicaAon owners
  • 25. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (MiAgaAons / Best PracAces) 25 A malicious resource (an API / Microservice) could reuse an access token used to access itself by a legiAmate client to access another resource, impersonaAng the original client. An evil web site gets an access token from a legiAmate user, can reuse it at another web site (which trusts the same authorizaAon server) with the implicit grant type h[ps://target-app/callback?access_token=<access_token>
  • 26. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Reuse/Misuse (MiAgaAons / Best PracAces) 26 A legiAmate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausAng server resources. To avoid exhausAng resources at the server side, enforce thro[le limits by user by applicaAon. In case an a[acker 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 #RSAC Token Export (Threats) 27 An a[acker could export an access token from its originaAng channel and use somewhere else. A common a[ack vector for SPAs (Single Page ApplicaAons) A major concerns with bearer tokens.
  • 28. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Export (VicAms) 28 Web/Mobile applicaAon users Web/Mobile applicaAon owners
  • 29. Presenter’s Company Logo – replace or delete on master slide #RSAC Token Export (MiAgaAons / Best PracAces) 29 The use of Token Binding protects access tokens from man-in-the- middle and token export and replay a[acks. h[ps://tools.iej.org/html/drak-jones-oauth-token-binding-00
  • 30. Presenter’s Company Logo – replace or delete on master slide #RSAC Apply What You Have Learned Today! 30 Review and test current OAuth 2.0 client applicaAons against the threats we discussed – probably build a test suite! Build a security check-list for an OAuth 2.0 AuthorizaAon Server, and make sure what you build or what you buy, adheres to it. Be the security champion of your team!