Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
1
OAuth 2.0 Security Considerations
for Client Applications
Kasun Dharmadasa
https://www.linkedin.com/in/kasundharmadasa
h...
Recent security breaches at
Facebook and Google
2
Facebook access token leak
• September 25, facebook had a breach affecting over 50 million user
accounts.
3
• The vulnerab...
“View As” feature
Allows us to view our profile as someone else.
4
Source : https://auth0.com/blog/facebook-access-token-d...
Birthday video upload feature
• Allows to upload a video into the friend’s profile on their Birthday
• Generates an access...
Alice’s Profile
Bob
Vulnerable flow
6
1. View her
profile as bob
2. Upload a birthday video
to Alice
Generates an
access t...
What was the impact?
Access tokens were revoked
• Over 90 million user’s access tokens have been revoked and users had to
...
Is my Facebook account impacted?
Facebook help center has provided a link to check whether your account was
affected with ...
Google+ People API Vulnerability
• This vulnerability allowed third party apps the access to profile fields that
were shar...
Facebook and Google do take security
seriously
• Facebook and Google has large security teams.
• They perform continuous s...
Still the vulnerabilities are
there!
Why? 11
Conventional security scans
and penetration testing
efforts will not be enough
12
Integrate proper Threat Modeling
OWASP categorizes threat modeling in to following four questions.
• What are we working o...
Recent efforts on identifying the
security flows in design
• Facebook Bug Bounty Program for Reports About Access Token Ex...
Common security threats in
OAuth landscape
15
Threat :
Cross Site Request Forgery
(CSRF) attack
16
Threat :
Cross Site Request Forgery (CSRF) attack
• Cross-Site Request Forgery is an attack that forces an end user to
exe...
Attacker Scenario
• The attacker authenticates to the authorization server using his credentials
and generates and authori...
Authorization Code flow
19
Client App
Authorization
Server
Resource Server
3. Authz response (code)
4. Authz
response
(cod...
Attack Scenario
20
code
Attacker
Client App
User
Resource Server
Authorization
Server
code
code
Attack scenario
21
Client App
1. code
2. code
3. access token
4. access token
Victim
Resource Server
Authorization
Server
Countermeasures:
Use the “state” parameter
22
Use the “state” parameter
• Generate a state parameter value and sent to the authorization server
during the authorization...
Using the “state” parameter
24
Client App
Authorization
Server
5. code, state=xyz2. Authz request
+
state=xyz
4. code, sta...
Threat :
Token export and replay
attacks
25
Threat : Token export and replay attacks
• OAuth uses bearer tokens which are similar to cash.
• The ownership of the toke...
Countermeasures:
Token Binding
27
Token Binding
• Token Binding cryptographically binds security tokens to the TLS layer.
• Client can generate a public and...
Reducing Token Lifetime can also help
to avoid replay attacks
29
Threat :
Authorization Code
interception attacks
30
Threat : Authorization code
interception attacks
• OAuth 2.0 authorization requests from native apps should only be made
t...
Threat : Authorization code interception
attacks
But, the danger here is, there can be multiple apps get registered for th...
Threat : Authorization code interception
attacks
Authorization
Server
1. Authz
Request
2. Authz Request
3. Authz code
4. A...
Countermeasures:
Proof of Key Code Exchange
(PKCE)
34
Proof of Key Code Exchange (PKCE)
• The client creates and records a secret named the "code_verifier" and
derives a hash “...
Using PKCE
36
1. code verifier
2. code challenge
SHA256
(method)
4. authz code +
code challenge
5. authz code
7. code veri...
Other important security considerations
To be kept in mind
• Validate the permissions (scopes) assigned for tokens.
• Neve...
References
[1] https://tools.ietf.org/html/rfc6749
[2] https://tools.ietf.org/id/draft-ietf-oauth-security-topics-05.html
...
Thank You
39
Nächste SlideShare
Wird geladen in …5
×

Oauth 2.0 Security Considerations for Client Applications

OAuth 2.0 specification describes the security considerations that need to be taken into account when using OAuth in web/mobile applications. This presentation explains the common OAuth security considerations and the way that they can be mitigated in secure software development lifecycle. Since these kind of vulnerabilities cannot be detected with automated security scans, threat modeling aspects that should be followed when designing critical systems are explained through the presentation.

  • Als Erste(r) kommentieren

Oauth 2.0 Security Considerations for Client Applications

  1. 1. 1 OAuth 2.0 Security Considerations for Client Applications Kasun Dharmadasa https://www.linkedin.com/in/kasundharmadasa http://www.meetup.com/Colombo-White-Hat-Security/ https://www.facebook.com/colombowhitehat https://twitter.com/ColomboWhiteHat
  2. 2. Recent security breaches at Facebook and Google 2
  3. 3. Facebook access token leak • September 25, facebook had a breach affecting over 50 million user accounts. 3 • The vulnerability occurred due to combination of two features in facebook. – “View as” feature – Birthday video upload feature Source : https://www.instahow.net/check-recover-hacked-facebook-account/
  4. 4. “View As” feature Allows us to view our profile as someone else. 4 Source : https://auth0.com/blog/facebook-access-token-data-breach-early-look/
  5. 5. Birthday video upload feature • Allows to upload a video into the friend’s profile on their Birthday • Generates an access token to use the video upload API. • Facebook uses ajax requests to upload the video. Therefore the generated access token is visible in the HTML web page. 5
  6. 6. Alice’s Profile Bob Vulnerable flow 6 1. View her profile as bob 2. Upload a birthday video to Alice Generates an access token Alice xxxxxxxx_token_for_bob Bob
  7. 7. What was the impact? Access tokens were revoked • Over 90 million user’s access tokens have been revoked and users had to re-login. GDPR implications • Facebook could be liable for up to $1.63 billion in fines, or 4 percent of its annual global revenue, if the EU determines it didn’t do enough to protect the security of its users. 7
  8. 8. Is my Facebook account impacted? Facebook help center has provided a link to check whether your account was affected with their latest access token vulnerability. https://www.facebook.com/help/securitynotice?ref=sec 8
  9. 9. Google+ People API Vulnerability • This vulnerability allowed third party apps the access to profile fields that were shared with the user, but not marked as public. https://developers.google.com/+/web/api/rest/latest/people • Google only keeps the API logs upto two weeks. Within this two weeks, nearly 500,000 user accounts have been accessed by third party apps 9
  10. 10. Facebook and Google do take security seriously • Facebook and Google has large security teams. • They perform continuous security scans on each of their deployments. • They are on the bug bounty programs such as hackerone and bugcrowd. • Pentesters around the globe are continuously pentesting to achieve huge rewards. 10
  11. 11. Still the vulnerabilities are there! Why? 11
  12. 12. Conventional security scans and penetration testing efforts will not be enough 12
  13. 13. Integrate proper Threat Modeling OWASP categorizes threat modeling in to following four questions. • What are we working on? • What can go wrong? • What are we going to do about it? • Did we do a good job? 13
  14. 14. Recent efforts on identifying the security flows in design • Facebook Bug Bounty Program for Reports About Access Token Exposure https://www.facebook.com/notes/facebook-bug-bounty/introducing-rewar ds-for-reports-about-access-token-exposure/2247351778612369/ • Project Strobe by Google https://www.blog.google/technology/safety-security/project-strobe/ 14
  15. 15. Common security threats in OAuth landscape 15
  16. 16. Threat : Cross Site Request Forgery (CSRF) attack 16
  17. 17. Threat : Cross Site Request Forgery (CSRF) attack • Cross-Site Request Forgery is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. • During the authorization code grant flow, the attacker has the ability to trick a victim to receive an access token using an authorization code received for an attacker. 17
  18. 18. Attacker Scenario • The attacker authenticates to the authorization server using his credentials and generates and authorization code. • The authorization code response from the authorization server is intercepted before reaching the client app. • The intercepted response is now send to the victim such that the authorization code (generated for the attacker) reaches the client app through the victim’s browser. • The client app gets an access token using the attacker’s authorization code and accesses the attacker’s resources. • The victim being under the assumption that this is his own account, will upload his personal resources in to the attacker’s account. 18
  19. 19. Authorization Code flow 19 Client App Authorization Server Resource Server 3. Authz response (code) 4. Authz response (code) 5. Token request (code) 6. Token response (access token) 7. access token User 1. Authz request 2. Authz request
  20. 20. Attack Scenario 20 code Attacker Client App User Resource Server Authorization Server code code
  21. 21. Attack scenario 21 Client App 1. code 2. code 3. access token 4. access token Victim Resource Server Authorization Server
  22. 22. Countermeasures: Use the “state” parameter 22
  23. 23. Use the “state” parameter • Generate a state parameter value and sent to the authorization server during the authorization code request. • Authorization server will return this state parameter along with the callback. • Validate the received state value with the value that was sent and drop the flow during a mismatch. 23
  24. 24. Using the “state” parameter 24 Client App Authorization Server 5. code, state=xyz2. Authz request + state=xyz 4. code, state=xyz 1. state=xyz User 3. Authz request + state=xyz
  25. 25. Threat : Token export and replay attacks 25
  26. 26. Threat : Token export and replay attacks • OAuth uses bearer tokens which are similar to cash. • The ownership of the token is not being validated upon presenting the token. • There needs to be a way to validate the proof of the possession of the token. 26 Source : https://www.rpmalamo.com/cash-for-kindness
  27. 27. Countermeasures: Token Binding 27
  28. 28. Token Binding • Token Binding cryptographically binds security tokens to the TLS layer. • Client can generate a public and a private key pair and send the public key to the authorization server to bind to the token. • Attacker cannot use such bounded token as it is impossible to proof the possession of the corresponding private key. 28
  29. 29. Reducing Token Lifetime can also help to avoid replay attacks 29
  30. 30. Threat : Authorization Code interception attacks 30
  31. 31. Threat : Authorization code interception attacks • OAuth 2.0 authorization requests from native apps should only be made through user browser (not embedded web views) • Once the authorization code is returned back to the redirect_uri (from the authorization server) on the browser, there should be a way to pass it over to the native app. • Each app has to register for a URL scheme. When the request comes to that particular URL, the mobile OS will pass its control to the corresponding native app. 31
  32. 32. Threat : Authorization code interception attacks But, the danger here is, there can be multiple apps get registered for the same URL scheme and there is a chance a malicious native could get hold of the authorization code. Hence, leaking of the authorization code. 32
  33. 33. Threat : Authorization code interception attacks Authorization Server 1. Authz Request 2. Authz Request 3. Authz code 4. Authz code 4. Authz code Legitimate App Malicious App Mobile Browser
  34. 34. Countermeasures: Proof of Key Code Exchange (PKCE) 34
  35. 35. Proof of Key Code Exchange (PKCE) • The client creates and records a secret named the "code_verifier" and derives a hash “code_challange” which is then sent along (including hashing method) with the Authorization Request. • The Authorization Endpoint responds as usual but records “code_challange” and the hashing method. • The client then sends the authorization code in the Access Token Request as usual but includes the "code_verifier" secret generated. • The authorization server transforms "code_verifier" and compares it to “code_challange”. Access is denied if they are not equal. 35
  36. 36. Using PKCE 36 1. code verifier 2. code challenge SHA256 (method) 4. authz code + code challenge 5. authz code 7. code verifier 8. code challenge SHA256 3. Authz request (code challenge + method) 6. Token request (authz code + code verifier) Client Authorization Server authz code + code challenge stored validate
  37. 37. Other important security considerations To be kept in mind • Validate the permissions (scopes) assigned for tokens. • Never write access/refresh tokens into logs. • Disable grant types that are not in use. 37
  38. 38. References [1] https://tools.ietf.org/html/rfc6749 [2] https://tools.ietf.org/id/draft-ietf-oauth-security-topics-05.html [3] https://tools.ietf.org/html/rfc6819 [4] https://auth0.com/blog/oauth-2-best-practices-for-native-apps/ [5] https://medium.facilelogin.com/what-went-wrong-d09b0dc24de4 [6] https://medium.facilelogin.com/oauth-2-0-token-binding-e84cbb2e60 [7] https://medium.facilelogin.com/oauth-2-0-threat-landscapes-9756e5bc44ee [8] https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08 [9] https://tools.ietf.org/html/rfc7636 [10] https://www.owasp.org/index.php/Application_Threat_Modeling [11] https://www.wsj.com/articles/facebook-faces-potential-1-63-billion-fine-in-europe-over-data-breach-1538330906 38
  39. 39. Thank You 39

×