OAuth 2.0 Threat Landscapes Prabath Siriwardena (@prabath) Cloud Identity Summit, 2017.
ABOUT ME
2
▪ The Senior Director of Security Architecture, WSO2 ▪ Authored the book Advanced API Security - and three more
▪ 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
▪ 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
▪ Use Proof Key for Code Exchange (PKCE) ○ https://tools.ietf.org/html/rfc7636
12
MITIGATIONS / BEST PRACTICES
SESSION INJECTION
▪ 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
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
▪ 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
▪ 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
▪ 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.
○ LinkedInhasanexpirationof30secondsforitsauthorizationcodes.
17
MITIGATIONS / BEST PRACTICES
TOKEN LEAKAGE
▪ The token expiration time would depend on the following parameters. ○ Riskassociatedwithtokenleakage○ Durationoftheunderlyingaccessgrant○ Timerequiredforanattackertoguessorproduceavalidtoken
▪ 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
▪ 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
▪ 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
▪ 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
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
▪ 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
▪ 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