APIsecure 2023 - Exploring Security Compliance in the OAuth 2.0 Ecosystem, Pieter Philippaerts

APIsecure 2023 - The world's first and only API security conference
March 14 & 15, 2023

Exploring Security Compliance in the OAuth 2.0 Ecosystem
Pieter Philippaerts, Research Manager at KU Leuven - DistriNet

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Transcript

1. Exploring Security Compliance in the OAuth 2.0 Ecosystem Pieter Philippaerts
2. https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth Authorization Server (AS) Resource Server Client Resource Owner
3. https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth Google Authorization Server YouTube API (Resource Server) Video Editor App (Client) End user (Resource Owner)
4. [..] OAuth clients could reduce the chance of being victimized by reviewing OAuth 2.0’s security practice guide, which could help [..] against the account hijacking risks. “ ”
5. Once you have implemented OAuth2, how do you know you have implemented it correctly?
7. The OAuch logo is based on the OAuth logo created by Chris Messina. The logo is released under the Creative Commons Attribution ShareAlike 3.0 license.
8. Testing OAuth Implementations
10. Copyright © Aaron Parecki
11. Building a test case The client MUST NOT use the authorization code more than once. OAuch tries to use the same authorization code two times and keeps track of the server’s response
12. Test case coverage › OAuch implements 113 unique test cases from 10 documents Many documents contain the same requirements If a requirement has varying requirement levels, OAuch picks the strictest one › Not all security requirements can be converted to test cases
13. Testing Process › OAuch is set up like any other client … but acts like a malicious client! › Access token validation requires an API endpoint HTTP 2xx → access token is valid HTTP 4xx/5xx → access token is invalid
14. The OAuch Tool
15. https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth Authorization Server API Server OAuch.io You
22. But what does it mean?
23. OAuth Threat Model 23 4.4.2.2. Threat: Access Token Leak in Browser History An attacker could obtain the token from the browser's history. Note that this means the attacker needs access to the particular device. Countermeasures: o Use short expiry time for tokens (see Section 5.1.5.3). Reduced scope of the token may reduce the impact of that attack (see Section 5.1.5.1). o Make responses non-cacheable. Name → Description → List of counter- measures →
24. OAuth Threat Model › OAuch integrates this threat model (+BCP) into the analysis 42 server-side threats are evaluated A threat can be full mitigated, partially mitigate or not mitigated › OAuch gives clear advice to a site owner Which threats your site might be vulnerable to Which countermeasures must be implemented to mitigate them
27. Analyzing the OAuth 2.0 Ecosystem
28. What we did › We tested 100 OAuth implementations 80 API providers, 20 OIDC providers 75 sites from Top 10000 All publicly available (so they should be secure) › We drew statistics over the sites and over the individual countermeasures/threats
29. Results – Failure Rates Overall: 33% FR Must: 20% FR Should: 56% FR May: 81% FR
30. Results – Partially Mitigated Threats
31. Results – Unmitigated Threats
32. Confirming the Results › Four attack vectors tested • Authorization Code Injection Attack • Implicit Flow Client Impersonation Attack • PKCE Downgrade Attack • Clickjacking Attack • OAuch produced highly reliable results • 1.45% false positive rate, 1.48% false negative rate
33. Is it really that bad?
34. Is it really that bad? › Yes and no. Yes, the servers do not (fully) mitigate certain threats No, the threat model assumes a powerful attacker Often complex exploitability No, OAuch assumes no client mitigations
35. Why are OAuth implementations lacking so many counter- measures?
36. Why are implementations non-compliant? › The provider knows about it, but… … wants to maintain backward compatibility … some countermeasures cannot be efficiently implemented … they have other development priorities … doesn’t care, because “it can be mitigated on the client side”
37. Why are implementations non-compliant? › The provider may not know about it, because… … the original OAuth standard is outdated … they make invalid assumptions … they assume the OAuth library handles everything … OAuth looks deceptively easy to implement
38. Concluding Thoughts
39. › It’s hard to use these results to create generally applicable advice Everyone makes different mistakes OAuch gives tailor-made advice per site Lessons Learned
40. › Do not assume that a library is safe. Verify that it is. › Update your packages regularly. Security protocols evolve. › Do not rely on clients making great security decisions. Enforce them. Lessons Learned
41. Lessons Learned › Having a formal verification of the OAuth2 protocol is great … but we also need tools to verify practical implementations › A lot of sites can benefit from implementing missing countermeasures
42. Try it! › The tool is available on https://oauch.io/ Let us know if we can improve something
43. Thank you! https://oauch.io/ https://distrinet.cs.kuleuven.be/ Pieter.Philippaerts@kuleuven.be