Successfully reported this slideshow.

Is OAuth Really Secure?

5

Share

1 of 21
1 of 21

Is OAuth Really Secure?

5

Share

Download to read offline

Slides from a talk I gave at IBWAS'10 in Lisbon, Portugal.

Abstract:
Is the OAuth protocol really secure? Even though the OAuth authorization protocol has been published as the RFC 5849 and is being widely adopted by large Internet companies, it's important to stress out its possible security vulnerabilities.
This talk will focus on the OWASP Top 10 Application Security Risks and how OAuth is affected by them.

While some of the security risks are mitigated by OAuth, developers need to take some action to prevent other risks from affecting their implementations.

Slides from a talk I gave at IBWAS'10 in Lisbon, Portugal.

Abstract:
Is the OAuth protocol really secure? Even though the OAuth authorization protocol has been published as the RFC 5849 and is being widely adopted by large Internet companies, it's important to stress out its possible security vulnerabilities.
This talk will focus on the OWASP Top 10 Application Security Risks and how OAuth is affected by them.

While some of the security risks are mitigated by OAuth, developers need to take some action to prevent other risks from affecting their implementations.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Is OAuth Really Secure?

  1. 1. IBWAS’10 Bruno Pedro 17 November 2010 Is OAuth Really Secure? http://www.flickr.com/photos/rooreynolds/2396418896/
  2. 2. Bruno Pedro A n e x p e r i e n c e d We b d e v e l o p e r a n d entrepreneur. Co-founder of tarpipe.com, a social media publishing platform. http://tarpipe.com/user/bpedro
  3. 3. Summary • What is OAuth? • Possible OWASP Top 10 threats • Possible solutions • Questions
  4. 4. What is OAuth? 1. Authorization protocol (RFC 5849)
  5. 5. What is OAuth? 2. Built on top of Google AuthSub, Flickr Auth and others http://tinyurl.com/3yhys4n
  6. 6. What is OAuth? 3. Authentication solution
  7. 7. What is OAuth? 4. Available for Web, desktop and also mobile and device applications
  8. 8. A1 - Injection ask for token consumer provider receive token
  9. 9. A1 - Injection ask for token mer provider ve rif yt receive token ok en database potential injection
  10. 10. A3 - Broken authentication consumer API call provider access token access secret • Weak or open access token and secret • Possible user impersonation
  11. 11. A5 - CSRF http://tinyurl.com/38o3r93 • End point might be open to CSRF • Possible user impersonation
  12. 12. A7 - Insecure Cryptographic Storage consumer tokens provider database database
  13. 13. A7 - Insecure Cryptographic Storage access to access to mer consumer all consumers prov users and all users database database
  14. 14. A10 - Unvalidated redirects • After authorizing, user is redirected to a callback URL • Callback might be an arbitrary value
  15. 15. Probably safe A2 — Cross Site Scripting A4 — Insecure Direct Object Reference A6 — Security Misconfiguration A8 — Failure to Restrict URL Access A9 — Insuficient Transport Layer Protection
  16. 16. Pay attention to A1 — Injection A3 — Broken Authentication A5 — Cross Site Request Forgery A7 — Insecure Cryptographic Storage A10 — Unvalidated Redirects
  17. 17. Possible solutions • Encrypt all OAuth credentials mitigates A3 and A7
  18. 18. Possible solutions • Generate verifiable consumer keys mitigates A1
  19. 19. Possible solutions • Throttle undesired usage mitigates A1 and A3
  20. 20. More information • OAuth: http://oauth.net • OWASP: http://owasp.org • OAuth Checklist: http://oauthchecklist.org
  21. 21. Questions? Thank you!

Editor's Notes

  • \n
  • \n
  • \n
  • RFC only published in April 2010\n
  • Authorization - used most of the time\nAuthentication - 2 legged OAuth, “sign in with twitter”, no to be confused with OpenID\nBuilt as an Open Protocol on top of already existing solutions (Amazon,Yahoo)\n
  • Authorization - used most of the time\nAuthentication - 2 legged OAuth, “sign in with twitter”, no to be confused with OpenID\nBuilt as an Open Protocol on top of already existing solutions (Amazon,Yahoo)\n
  • \n
  • \n
  • Possible solution: verify tokens prior to database\n
  • Possible solutions: crypto, throttle\n
  • Possible solution: any CSRF solution\n
  • \n
  • Solution: crypto and more\n
  • Possible solution: fix callback to same domain or even same page\n
  • \n
  • \n
  • A3 - Broken authentication, A7 - Insecure cryptographic storage\n
  • A1 - Injection\n
  • A1 - Injection, A3 - Broken authentication\n
  • \n
  • \n
  • ×