oauth 2.0 threat landscapes

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

OAUTH 2.0 RECAP

OAUTH 2.0

4

AUTHORIZATION CODE

5

IMPLICIT

6

CLIENT CREDENTIALS

7

RESOURCE OWNER PASSWORD

8

THREATS / MITIGATIONS / BEST PRACTICES

▪  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


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


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


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


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


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


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


TOKEN REUSE/MISUSE

OPEN TECHNOLOGY FOR YOUR AGILE DIGITAL BUSINESS

THANK YOU

oauth 2.0 threat landscapes

Technology