A Comprehensive Formal Security Analysis of OAuth 2.0

# A Comprehensive Formal Security Analysis of OAuth 2.0

D. Fett, R. Küsters, G. Schmitz  
(University of Trier, Germany)

Presented by Kamila Součková  
*Current topics in information security*, 2016

???

Before we even start, let's look at what we will be talking [NEXT] about...

---

# What is OAuth?

.floatleft.half[![Sample OAuth request screen](oauthsample.png)]

???

you've probably all seen something that looks like this

---

# What is OAuth?

.floatleft.half[![Sample OAuth request screen](oauthsample.png)]

3 parties:

- **_user_**  
  (you)
- **_relying party_**  
  (app)
- **_identity provider_**  
  (knows who you are)

???

*Note*: talking about OAuth 2.0 (different from old & ugly OAuth 1.0)

[NEXT] as you have probably noticed...

---

# What is OAuth?

.floatleft.half[![Sample OAuth request screen](oauthsample.png)]

used all over the place:

- SSO (esp. in OpenID Connect)
- access to personal data

???

Amazon, Facebook, Google, Microsoft, Yahoo, GitHub, LinkedIn, PayPal, StackExchange, and Dropbox
...therefore it must be secure, [NEXT] i.e. we need to protect...
---

# What We Need to Protect

- **authorization**: only legitimate RPs can access the user's data
- **authentication**: an attacker is not able to login at an (honest) RP under the identity of a user
- **session integrity**: RP can access user's resources *only* with the users's consent; resources are always the *correct user's* resources

???

- authorization: ... unless the IdP or the user's browser is corrupted
- authentication: ... also except IdP or browser corruption
- session integrity: the correct user's resources, not some other stuff -- if a user starts the OAuth flow, then it is never completed with a different identity

---

# Contributions

- first OAuth analysis in a comprehensive formal model of the web
- attacks against the OAuth *standard* discovered  
  (not specific implementations)
- conditions under which OAuth is secure established

???

or what this paper is about

secure with respect to the three properties mentioned (authorization, authentication, session integrity)

And this is exactly [NEXT] what we will talk about:

---

# Overview

1. OAuth flow(s) explained;  
   model overview
2. attacks against the OAuth standard  
   (flaws in the OAuth design)
3. conditions under which OAuth is secure

---

# Overview

1. **OAuth flow(s) explained;  
   model overview**
2. attacks against the OAuth standard  
   (flaws in the OAuth design)
3. conditions under which OAuth is secure

---

# OAuth overview

4 grant types ("modes"):

- authorization code grant
- implicit grant
- resource owner password credentials grant
- client credentials grant

+ many options

???

Together with [NEXT] the complexity of the web....

---

# OAuth overview

4 grant types ("modes"):

- authorization code grant
- implicit grant
- resource owner password credentials grant
- client credentials grant

+ many options  
 + complexity of the web  
 ⇒ complicated!

???

... this ends up being complicated, as we are going to see in the following slides.

[NEXT] Before we get to them, I unfortunately need to mention the official terminology

---

# OAuth overview

## Terminology

- ***resource owner***: user
- ***client***: relying party .light[(sorry)]
- ***authorization server, resource server***: identity provider

---

# OAuth Flow

## Authorization Code Mode

---

<span class="small" style="position: absolute; left: 1em; bottom: 0.2em;">image from source article</span>

???

state is a token to prevent CSRF attacks
IdP creates a nonce, the *code* parameter, and...

---

# OAuth Flow: Other Modes

- **implicit mode**: skip *code*, directly grant access token
- **Resource Owner Password Credentials Mode**: used for highly trusted RPs
- **Client Credentials Mode**: RP talks to IdP for management

???

- implicit mode: access token is put into the #fragment

Now that we hopefully have an idea about how OAuth works, [NEXT] we can look at what attacks the authors found.

---

# Tracking User Intention

if RP supports multiple IdP: must know which one the user chose

⇒ options:
- *naive:* different redirection URIs
- *explicit:* make a session right from the start, store it there

???

As you can see, this is pretty complex. This article is the first to [NEXT] tackle this complexity with a comprehensive model...

---

# Formal Model overview

*FKS* model: Dolev-Yao model with stuff for the web
- symbolic
- attacker model:
  - network attacker: sees and can manipulate everything
  - any process can become corrupted at any time
- models processes: browsers, servers, Javascript...
- models communication: HTTP(S) requests + responses (incl. headers, cookies, ...)

???

[NEXT] Thanks to the model, the authors were able to...

Fett, Küsters, and Schmitz (the same guys)

---

# Overview

1. OAuth flow(s) explained;  
   model overview
2. **attacks against the OAuth standard  
   (flaws in the OAuth design)**
3. conditions under which OAuth is secure

???

...discover 4 previously unknown attacks against OAuth (the standard, not the implementation).

Note: Many more attacks are possible against specific OAuth implementations, or when the deployment practices are not optimal.

Here the authors assumed a perfect implementation of the standard, and state of the art security (security
recommendations (RFC6819 [26]), additional RFCs and OAuth
Working Group drafts (e.g., RFC7662 [30], [8]) and current web
best practices (e.g., regarding session handling)).

Still, they found 4 practically applicable attacks. Let us now look at those.

---

# 307 Redirect Attack

1. attacker runs an RP that the user wants to log in to
2. IdP redirects immediately after the user entered her credentials
3. IdP uses the 307 HTTP status code for the redirect back to RP (standard does not specify)

(2) happens in the wild (e.g. on Github)  
(3) is explicitly permitted in the standard

???

I like this one, because the idea is very simple; yet it has not been noticed before. This is why we need formal models.

[article published in August 2016 :D]

---

# 307 Redirect Attack

1. attacker runs an RP that the user wants to log in to
2. IdP redirects immediately after the user entered her credentials
3. IdP uses the 307 HTTP status code for the redirect back to RP

307 redirect means "repeat this request, including the HTTP method and data". So, .red[you'll just re-send your credentials to RP].

???

breaks the authorization and authentication properties, as the RP now has your credentials and can do whatever they want with it

---

# IdP Mix-Up Attack

1. attacker runs AIdP, RP allows both AIdP and honest HIdP
2. attacker able to manipulate the "user sends chosen IdP" request + response (steps 1, 2)
3. RP tracks user-chosen IdP in temporary session (naive user intention tracking)

???

2. reasonable because this is between the user and an RP, so e.g. ARP spoofing on local network is fine; and (more importantly) it is not obvious that HTTPS would be a good idea in this step; and OAuth standard does not suggest HTTPS
3. if RP supports multiple IdPs, it needs to track this somehow; here we assume that it is tracked server-side in a session (called "explicit mode")

---

<span class="small" style="position: absolute; left: 1em; bottom: 0.2em;">image from source article</span>

???

Breaking authorization: now you can use that code for accessing stuff at HIdP

Breaking authentication: start a new flow, ignore the code you got for yourself, give the one you stole before

There are also some more variants of this attack.

---

# IdP Mix-Up Attack

**The Problem:** no reliable information in the redirect

**Suggested Fix:** add issuer information e.g. as a URL parameter, so that the RP can check whether the IdP matches

???

fix: as this is HTTPS, the attacker cannot spoof it

this they proved to be sufficient

---

# State Leak Attack

use an attacker's resource instead of the user's (session swapping): breaks integrity

**Attack:** get your link into the RP's landing/code-redeeming page, and when the browser happens to follow it, .red[pick *state* or *code* from the `Referer` header]

???

*state* is used to prevent CSRF; so now CSRF is not prevented

---

# State Leak Attack

use an attacker's resource instead of the user's (session swapping): breaks integrity

**Attack:** get your link into the RP's landing/code-redeeming page, and when the browser happens to follow it, .red[pick *state* or *code* from the `Referer` header]

**Even better:** if the IdP's page contains an external resource (like a CDN-hosted script, for example...), it is loaded without user interaction, and also gets the `Referer` header!

---

# State Leak Attack

use an attacker's resource instead of the user's (session swapping): breaks integrity

**Attack:** get your link into the RP's landing/code-redeeming page, and when the browser happens to follow it, .red[pick *state* or *code* from the `Referer` header]

**Fix:** make *state* single-use; use *referrer policies* to prevent the leak

???

Referrer policies proven to be an effective fix

---

# Naive RP Session Integrity Attack

1. RP does not explicitly track chosen IdP -- only looks at the URL (no session)
2. attacker starts session with HIdP to get his account's *code* or *access_token*
3. user wants to log in at RP via AIdP (controlled by attacker)
4. AIdP redirects user to HIdP, sticking **the attacker's** *code/access_token* in there

**Fix:** use explicit tracking (server-side)

---

# Attacks: Wrap-Up

**307 Redirect Attack**: IdPs end up forwarding user credentials → .red[breaks authorization, authentication]

**IdP Mix-Up Attack**: network attacker acting as an IdP can impersonate user → .red[breaks authorization, authentication]

**State Leak Attack, Naive RP Session Integrity Attack**: session swapping → .red[breaks session integrity]

???

verified all four attacks on actual
implementations of OAuth and OpenID Connect. + came up with fixes + notified the respective working groups, who confirmed the at-
tacks and that changes to the standards/recommendations are needed.
The IdP mix-up attack already resulted in a draft of a new RFC [22]

---

# Overview

1. OAuth flow(s) explained;  
   model overview
2. attacks against the OAuth standard  
   (flaws in the OAuth design)
3. **conditions under which OAuth is secure**

???

The discovered attacks led to the mentioned fixes. To get a secure OAuth deployment...

---

# If...

- fixes from the previous sections applied
  - referrer policies
  - correctly used HTTP status codes
  - explicit (server-side) tracking of chosen IdP

???

... we need to apply [these] in addition to [NEXT]
sticking to the OAuth recommendations and best practices

the usual security considerations, like CSRF prevention, , 
---

# And...

- OAuth best practices used:
  - OAuth standard
  - all Working Drafts
  - fixes against all known attacks
  - access tokens to prevent impersonation used

---

# And...

- standard security measures implemented:
  - use HTTPS (+ `secure` cookies)
  - do not include 3<sup>rd</sup> party resources
  - no open redirectors
  - CSRF prevention (nonces)

???

[NEXT] Then...

---

# Then...

OAuth .green[**proven secure**] w.r.t.

???

This is the first proof which
establishes central security properties of OAuth in a comprehensive
and expressive web model

---

# Conclusion

???

established good grounds for future work: analyzing OpenID Connect

---

# Conclusion

- first OAuth analysis in a comprehensive formal model of the web **.green[   :-)]**
- attacks against the OAuth *standard* **.green[   :-)]**
- conditions under which OAuth is secure established **.green[   :-)]**
- analysis not explained well enough (and explained too well in the TR) **.red[   :-(]**
- intimate knowledge of HTTP assumed **.red[   :-(]**

???

- did not give much insight into the model -- almost nothing in this article, full TR too ugly -- could have provided some middle ground
- knowledge of HTTP assumed: e.g. talked about 302 redirects being a problem, but never said why -- one sentence about the difference between the redirect types would have spared me from some confusion
- presentation order: model could have been introduced at the beginning
- overall a nice article (glad to have had the chance to read it & present it to you)

---

# .blue[Thank you for your attention!]

---

# Appendix

---