Upgrade to Pro — share decks privately, control downloads, hide ads and more …

APIsecure 2023 - Exploring Security Compliance ...

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/

apidays

March 21, 2023
Tweet

More Decks by apidays

Other Decks in Programming

Transcript

  1. [..] 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. “ ”
  2. 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.
  3. 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
  4. 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
  5. 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
  6. 17

  7. 18

  8. 19

  9. 20

  10. 21

  11. 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 →
  12. 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
  13. 25

  14. 26

  15. 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
  16. 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
  17. 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
  18. 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”
  19. 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
  20. › 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
  21. › 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
  22. 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