[Cloud Identity Summit 2017] Oauth 2.0 Threat Landscapes
6 likes854 views
This document summarizes OAuth 2.0 threat landscapes and best practices for mitigation. It discusses threats such as CSRF, session injection, token leakage, IDP mix-up, and token reuse/misuse. Recommended mitigations include using the state parameter, PKCE, short-lived tokens, TLS, white-listing callback URLs, scoped tokens, audience restriction, OpenID Connect, and throttling. The document provides technical details on various OAuth 2.0 flows and threats as well as references to relevant IETF draft specifications.
[Cloud Identity Summit 2017] Oauth 2.0 Threat Landscapes
- 1. OAuth 2.0 Threat Landscapes Prabath Siriwardena (@prabath) Cloud Identity Summit, 2017.
- 2. ABOUT ME 2 ▪ The Senior Director of Security Architecture, WSO2 ▪ Authored the book Advanced API Security - and three more
- 4. OAUTH 2.0 4
- 6. IMPLICIT 6
- 9. THREATS / MITIGATIONS / BEST PRACTICES
- 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. ▪ 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. ▪ Use Proof Key for Code Exchange (PKCE) ○ https://tools.ietf.org/html/rfc7636 12 MITIGATIONS / BEST PRACTICES SESSION INJECTION
- 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. 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. ▪ 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. ▪ 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. ▪ 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. ▪ 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. ▪ 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. ▪ 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. ▪ IdP-Mixup ○ Use different callback URLs by IdP ○ https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01 ols.ietf.org/html/draft-ietf-oauth-mix-up-mitigaon-01 ▪ Token Binding ○ https://tools.ietf.org/html/draft-ietf-tokbind-protocol ○ https://tools.ietf.org/html/draft-ietf-tokbind-negotiation ○ https://tools.ietf.org/html/draft-ietf-tokbind-https ○ https://tools.ietf.org/html/draft-ietf-oauth-token-binding 21 MITIGATIONS / BEST PRACTICES TOKEN LEAKAGE
- 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. ▪ 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 https://tools.ietf.org/id/draft-tschofenig-oauth- audience-00.html. ▪ Use OAuth for authorization not for authentication. ○ Use OpenID Connect for authentication 23 MITIGATIONS / BEST PRACTICES TOKEN REUSE/MISUSE
- 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
- 25. OPEN TECHNOLOGY FOR YOUR AGILE DIGITAL BUSINESS THANK YOU