Is OAuth Really Secure?
•Télécharger en tant que KEY, PDF•
5 j'aime•3,263 vues
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.
Recommandé
Recommandé
Contenu connexe
Similaire à Is OAuth Really Secure?
Similaire à Is OAuth Really Secure? (20)
Plus de Bruno Pedro
Plus de Bruno Pedro (20)
Dernier
Dernier (20)
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
Notes de l'éditeur
- \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