Oauth 2.0 Security Considerations for Client Applications

1
OAuth 2.0 Security Considerations
for Client Applications
Kasun Dharmadasa
https://www.linkedin.com/in/kasundharmadasa
http://www.meetup.com/Colombo-White-Hat-Security/
https://www.facebook.com/colombowhitehat
https://twitter.com/ColomboWhiteHat

Recent security breaches at
Facebook and Google
2

Facebook access token leak
• September 25, facebook had a breach affecting over 50 million user
accounts.
3
• The vulnerability occurred due to
combination of two features in
facebook.
– “View as” feature
– Birthday video upload feature
Source : https://www.instahow.net/check-recover-hacked-facebook-account/

“View As” feature
Allows us to view our profile as someone else.
4
Source : https://auth0.com/blog/facebook-access-token-data-breach-early-look/

Birthday video upload feature
• Allows to upload a video into the friend’s profile on their Birthday
• Generates an access token to use the video upload API.
• Facebook uses ajax requests to upload the video. Therefore the generated
access token is visible in the HTML web page.
5

Alice’s Profile
Bob
Vulnerable flow
6
1. View her
profile as bob
2. Upload a birthday video
to Alice
Generates an
access token
Alice
xxxxxxxx_token_for_bob
Bob

What was the impact?
Access tokens were revoked
• Over 90 million user’s access tokens have been revoked and users had to
re-login.
GDPR implications
• Facebook could be liable for up to $1.63 billion in fines, or 4 percent of its
annual global revenue, if the EU determines it didn’t do enough to protect
the security of its users.
7

Is my Facebook account impacted?
Facebook help center has provided a link to check whether your account was
affected with their latest access token vulnerability.
https://www.facebook.com/help/securitynotice?ref=sec
8

Google+ People API Vulnerability
• This vulnerability allowed third party apps the access to profile fields that
were shared with the user, but not marked as public.
https://developers.google.com/+/web/api/rest/latest/people
• Google only keeps the API logs upto two weeks. Within this two weeks,
nearly 500,000 user accounts have been accessed by third party apps
9

Facebook and Google do take security
seriously
• Facebook and Google has large security teams.
• They perform continuous security scans on each of their deployments.
• They are on the bug bounty programs such as hackerone and bugcrowd.
• Pentesters around the globe are continuously pentesting to achieve huge
rewards.
10

Still the vulnerabilities are
there!
Why? 11

Conventional security scans
and penetration testing
efforts will not be enough
12

Integrate proper Threat Modeling
OWASP categorizes threat modeling in to following four questions.
• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Did we do a good job?
13

Recent efforts on identifying the
security flows in design
• Facebook Bug Bounty Program for Reports About Access Token Exposure
https://www.facebook.com/notes/facebook-bug-bounty/introducing-rewar
ds-for-reports-about-access-token-exposure/2247351778612369/
• Project Strobe by Google
https://www.blog.google/technology/safety-security/project-strobe/
14

Common security threats in
OAuth landscape
15

Threat :
Cross Site Request Forgery
(CSRF) attack
16

Threat :
Cross Site Request Forgery (CSRF) attack
• Cross-Site Request Forgery is an attack that forces an end user to
execute unwanted actions on a web application in which they're
currently authenticated.
• During the authorization code grant flow, the attacker has the ability
to trick a victim to receive an access token using an authorization
code received for an attacker.
17

Attacker Scenario
• The attacker authenticates to the authorization server using his credentials
and generates and authorization code.
• The authorization code response from the authorization server is
intercepted before reaching the client app.
• The intercepted response is now send to the victim such that the
authorization code (generated for the attacker) reaches the client app
through the victim’s browser.
• The client app gets an access token using the attacker’s authorization
code and accesses the attacker’s resources.
• The victim being under the assumption that this is his own account, will
upload his personal resources in to the attacker’s account.
18

Authorization Code flow
19
Client App
Authorization
Server
Resource Server
3. Authz response (code)
4. Authz
response
(code)
5. Token request
(code)
6. Token response
(access token)
7. access token
User
1. Authz
request
2. Authz request

Attack Scenario
20
code
Attacker
Client App
User
Resource Server
Authorization
Server
code
code

Attack scenario
21
Client App
1. code
2. code
3. access token
4. access token
Victim
Resource Server
Authorization
Server

Countermeasures:
Use the “state” parameter
22

Use the “state” parameter
• Generate a state parameter value and sent to the authorization server
during the authorization code request.
• Authorization server will return this state parameter along with the
callback.
• Validate the received state value with the value that was sent and drop
the flow during a mismatch.
23

Using the “state” parameter
24
Client App
Authorization
Server
5. code, state=xyz2. Authz request
+
state=xyz
4. code, state=xyz
1. state=xyz
User
3. Authz request
+
state=xyz

Threat :
Token export and replay
attacks
25

Threat : Token export and replay attacks
• OAuth uses bearer tokens which are similar to cash.
• The ownership of the token is not being validated upon presenting the
token.
• There needs to be a way to validate the proof of the possession of the
token.
26
Source : https://www.rpmalamo.com/cash-for-kindness

Countermeasures:
Token Binding
27

Token Binding
• Token Binding cryptographically binds security tokens to the TLS layer.
• Client can generate a public and a private key pair and send the public key
to the authorization server to bind to the token.
• Attacker cannot use such bounded token as it is impossible to proof the
possession of the corresponding private key.
28

Reducing Token Lifetime can also help
to avoid replay attacks
29

Threat :
Authorization Code
interception attacks
30

Threat : Authorization code
interception attacks
• OAuth 2.0 authorization requests from native apps should only be made
through user browser (not embedded web views)
• Once the authorization code is returned back to the redirect_uri (from the
authorization server) on the browser, there should be a way to pass it over
to the native app.
• Each app has to register for a URL scheme. When the request comes to
that particular URL, the mobile OS will pass its control to the
corresponding native app. 31

Threat : Authorization code interception
attacks
But, the danger here is, there can be multiple apps get registered for the same
URL scheme and there is a chance a malicious native could get hold of the
authorization code.
Hence, leaking of the authorization code.
32

Threat : Authorization code interception
attacks
Authorization
Server
1. Authz
Request
2. Authz Request
3. Authz code
4. Authz
code
4. Authz
code
Legitimate App Malicious App
Mobile Browser

Countermeasures:
Proof of Key Code Exchange
(PKCE)
34

Proof of Key Code Exchange (PKCE)
• The client creates and records a secret named the "code_verifier" and
derives a hash “code_challange” which is then sent along (including
hashing method) with the Authorization Request.
• The Authorization Endpoint responds as usual but records
“code_challange” and the hashing method.
• The client then sends the authorization code in the Access Token Request
as usual but includes the "code_verifier" secret generated.
• The authorization server transforms "code_verifier" and compares it to
“code_challange”. Access is denied if they are not equal. 35

Using PKCE
36
1. code verifier
2. code challenge
SHA256
(method)
4. authz code +
code challenge
5. authz code
7. code verifier
8. code challenge
SHA256
3. Authz request (code challenge + method)
6. Token request (authz code + code verifier)
Client Authorization Server
authz code + code
challenge
stored
validate

Other important security considerations
To be kept in mind
• Validate the permissions (scopes) assigned for tokens.
• Never write access/refresh tokens into logs.
• Disable grant types that are not in use.
37

References
[1] https://tools.ietf.org/html/rfc6749
[2] https://tools.ietf.org/id/draft-ietf-oauth-security-topics-05.html
[4] https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
[5] https://medium.facilelogin.com/what-went-wrong-d09b0dc24de4
[6] https://medium.facilelogin.com/oauth-2-0-token-binding-e84cbb2e60
[7] https://medium.facilelogin.com/oauth-2-0-threat-landscapes-9756e5bc44ee
[8] https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08
[10] https://www.owasp.org/index.php/Application_Threat_Modeling
[11] https://www.wsj.com/articles/facebook-faces-potential-1-63-billion-fine-in-europe-over-data-breach-1538330906
38

Oauth 2.0 Security Considerations for Client Applications

More Related Content

What's hot (20)

Similar to Oauth 2.0 Security Considerations for Client Applications (20)

Recently uploaded (20)

Oauth 2.0 Security Considerations for Client Applications