Is OAuth Really Secure?
5 likes3,269 views
The document discusses OAuth, an authorization protocol, and outlines potential OWASP Top 10 security threats associated with it, such as injection attacks and broken authentication. It suggests possible solutions like encrypting OAuth credentials and generating verifiable consumer keys to mitigate risks. The document emphasizes the importance of addressing these vulnerabilities to enhance security in OAuth implementations.
Is OAuth Really Secure?
- 1. IBWAS’10 Bruno Pedro 17 November 2010 Is OAuth Really Secure? http://www.flickr.com/photos/rooreynolds/2396418896/
- 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. Summary • What is OAuth? • Possible OWASP Top 10 threats • Possible solutions • Questions
- 4. What is OAuth? 1. Authorization protocol (RFC 5849)
- 5. What is OAuth? 2. Built on top of Google AuthSub, Flickr Auth and others http://tinyurl.com/3yhys4n
- 6. What is OAuth? 3. Authentication solution
- 7. What is OAuth? 4. Available for Web, desktop and also mobile and device applications
- 8. A1 - Injection ask for token consumer provider receive token
- 9. A1 - Injection ask for token mer provider ve rif yt receive token ok en database potential injection
- 10. A3 - Broken authentication consumer API call provider access token access secret • Weak or open access token and secret • Possible user impersonation
- 11. A5 - CSRF http://tinyurl.com/38o3r93 • End point might be open to CSRF • Possible user impersonation
- 12. A7 - Insecure Cryptographic Storage consumer tokens provider database database
- 13. A7 - Insecure Cryptographic Storage access to access to mer consumer all consumers prov users and all users database database
- 14. A10 - Unvalidated redirects • After authorizing, user is redirected to a callback URL • Callback might be an arbitrary value
- 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. Pay attention to A1 — Injection A3 — Broken Authentication A5 — Cross Site Request Forgery A7 — Insecure Cryptographic Storage A10 — Unvalidated Redirects
- 17. Possible solutions • Encrypt all OAuth credentials mitigates A3 and A7
- 18. Possible solutions • Generate verifiable consumer keys mitigates A1
- 19. Possible solutions • Throttle undesired usage mitigates A1 and A3
- 20. More information • OAuth: http://oauth.net • OWASP: http://owasp.org • OAuth Checklist: http://oauthchecklist.org
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: RFC only published in April 2010\n
- #6: 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
- #7: 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
- #8: \n
- #9: \n
- #10: Possible solution: verify tokens prior to database\n
- #11: Possible solutions: crypto, throttle\n
- #12: Possible solution: any CSRF solution\n
- #13: \n
- #14: Solution: crypto and more\n
- #15: Possible solution: fix callback to same domain or even same page\n
- #16: \n
- #17: \n
- #18: A3 - Broken authentication, A7 - Insecure cryptographic storage\n
- #19: A1 - Injection\n
- #20: A1 - Injection, A3 - Broken authentication\n
- #21: \n
- #22: \n