Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Cloud Identity Summit 2017] Oauth 2.0 Threat Landscapes


Published on

Prabath Siriwardena, Senior Director of Security Architecture at WSO2 spoke at Cloud Identity Summit 2017 on how threat landscapes in OAuth 2.0 is essential in building a secured identity infrastructure. His talk guided many through the multiple attacks that took place over the last few years exploiting security vulnerabilities in various OAuth 2.0 implementations, their root causes and how to mitigate any future security exploits by following the best practices.

Prabath's blog on same topic -
Prabath on Linkedin -

Published in: Technology
  • Be the first to comment

[Cloud Identity Summit 2017] Oauth 2.0 Threat Landscapes

  1. 1. OAuth 2.0 Threat Landscapes Prabath Siriwardena (@prabath) Cloud Identity Summit, 2017.
  2. 2. ABOUT ME 2 ▪  The Senior Director of Security Architecture, WSO2 ▪  Authored the book Advanced API Security - and three more
  3. 3. OAUTH 2.0 RECAP
  4. 4. OAUTH 2.0 4
  6. 6. IMPLICIT 6
  10. 10. ▪  CSRF (Cross Site Request Forgery) ○  The attacker tries to log into the target website (OAuth 2.0 client) with his account at the corresponding identity provider. ○  The attacker blocks the redirection to the target web site, and captures the authorization code. The target web site never sees the code. ○  The attacker constructs the callback URL for the target site - and lets the victim, clicks on it. ○  The victim logs into the target web site, with the account attached to the attacker - and adds credit card information. ○  The attacker too logs into the target website with his/her valid credentials and uses victim’s credit card to buy goods. 10 SESSION INJECTION THREATS
  11. 11. ▪  Short-lived authorization code ▪  Use the state parameter as defined in the OAuth 2.0 specification. ○  Generate a random number and pass it to the authorization server along with the grant request. ○  Before redirecting to the authorization server, add the generated value of the state to the current user session. ○  Authorization server has to return back the same state value with the authorization code to the return_uri. ○  The client has to validate the state value returned from the authorization server with the value stored in the user’s current session - if mismatches - reject moving forward. 11 MITIGATIONS / BEST PRACTICES SESSION INJECTION
  12. 12. ▪  Use Proof Key for Code Exchange (PKCE) ○ 12 MITIGATIONS / BEST PRACTICES SESSION INJECTION
  13. 13. ▪  The OAuth 2.0 client app generates a random number (code_verifier) and finds the SHA256 hash of it - which is called the code_challenge ▪  Send the code_challenge along with the hashing method in the authorization grant request to the authorization server. ▪  Authorization server records the code_challenge and replies back with the code. ▪  The client sends the code_verifier along with the authorization code to the token endpoint. 13 PROOF KEY FOR CODE EXCHANGE
  14. 14. TOKEN LEAKAGE ▪  Attacker may attempt to eavesdrop authorization code/access token/ refresh token in transit from the authorization server to the client. ○  Malware installed in the browser (public clients) ○  Browser history (public clients / URI fragments) ○  Intercept the TLS communication between the client (confidential) and the authorization server (exploiting vulnerabilities at the TLS layer) ▪  Heartbleed ▪  Logjam ▪  Authorization Code Flow Open Redirector 14 THREATS
  15. 15. ▪  A malicious app can register itself as a handler for the same custom scheme as of a legitimate OAuth 2.0 native app, can get hold of the authorization code. ▪  Attacker may attempt a brute force attack to crack the authorization code/access token. ▪  Attacker may attempt to steal the authorization code/access token/ refresh token stored in the authorization server. ▪  IdP Mix-Up / Malicious Endpoint 15 THREATS TOKEN LEAKAGE
  16. 16. ▪  The OAuth 2.0 app provides multiple IdP options to login. ▪  The victim picks foo.idp from the browser - the attacker intercepts the request and change the selection to evil.idp. ▪  The client thinks it’s evil.idp and redirects the user to evil.idp. ▪  The attacker intercepts the redirection and modify the redirection to go to the foo.idp. ▪  The client gets either the code or the token (based on the grant type) and now will talk to the evil.idp to validate. ▪  The evil.idp gets hold of user’s access token or the authorization code from the foo.idp. 16 IDP MIXUP
  17. 17. ▪  Always on TLS (use TLS 1.2 or later) ▪  Address all the TLS level vulnerabilities both at the client, authorization server and the resource server. ▪  The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence. ▪  Never store tokens in clear text - but the salted hash. ▪  Short-lived tokens. ○  LinkedIn has an expiration of 30 seconds for its authorization codes. 17 MITIGATIONS / BEST PRACTICES TOKEN LEAKAGE
  18. 18. ▪  The token expiration time would depend on the following parameters. ○  Risk associated with token leakage ○  Duration of the underlying access grant ○  Time required for an attacker to guess or produce a valid token ▪  One-time authorization code ▪  One-time access token (implicit grant type) ▪  Use PKCE (proof key for code exchange) to avoid authorization code interception attack. ○  Have S256 as the code challenge method ▪  Enforce standard SQL injection countermeasures 18 MITIGATIONS / BEST PRACTICES TOKEN LEAKAGE
  19. 19. ▪  Avoid using the same client_id/client_secret for each instance of a mobile app - rather use the Dynamic Client Registration API to generate a key pair per instance. ○  Most of the time the leakage of authorization code becomes a threat when the attacker is in hold of the client id and client secret. ▪  Restrict grant types by client. ○  Most of the authorization servers do support all core grant types. If unrestricted, leakage of client id/client secret gives the attacker the opportunity obtain an access token via client credentials grant type. 19 MITIGATIONS / BEST PRACTICES TOKEN LEAKAGE
  20. 20. ▪  Enable client authentication via a much secured manner. ○  JWT client assertions ○  TLS mutual authentication ○  Have a key of size 2048 bits or larger if RSA algorithms are used for the client authentication ○  Have a key of size 160 bits or larger if elliptic curve algorithms are used for the client authentication ▪  White-list callback URLs (redirect_uri) ○  The absolute URL or a regEx pattern 20 MITIGATIONS / BEST PRACTICES TOKEN LEAKAGE
  21. 21. ▪  IdP-Mixup ○  Use different callback URLs by IdP ○ ▪  Token Binding ○ ○ ○ ○ 21 MITIGATIONS / BEST PRACTICES TOKEN LEAKAGE
  22. 22. TOKEN REUSE/MISUSE ▪  A malicious resource (an API / Microservice) could reuse an access token used to access itself by a legitimate client to access another resource, impersonating the original client. ▪  An evil web site gets an access token from a legitimate user, can reuse it at another web site (which trusts the same authorization server) with the implicit grant type ○  https://target-app/callback?access_token=<access_token> ▪  A legitimate user misuses an access token (issued under implicit grant type/SPA) to access a set of backend APIs in a way, exhausting server resources. 22 THREATS
  23. 23. ▪  Use scoped access tokens. Qualify the scope name, with a namespace unique to the resource (resource server). ▪  The client obtains the access token for a given audience - by passing the audience information (representing the resource server) to the token endpoint - as per audience-00.html. ▪  Use OAuth for authorization not for authentication. ○  Use OpenID Connect for authentication 23 MITIGATIONS / BEST PRACTICES TOKEN REUSE/MISUSE
  24. 24. ▪  To avoid exhausting resources at the server side, enforce throttle limits by user by application. In case an attacker wants to misuse a token - the worst he/she can do is to eat his/her own quota. 24 MITIGATIONS / BEST PRACTICES TOKEN REUSE/MISUSE