1

THE DEVIL IS IN THE (IMPLEMENTATION) DETAILS: AN EMPIRICAL ANALYSIS OF OAUTH SSO SYSTEMS

SAN-TSAI SUN & KONSTANTIN BEZNOSOV

PRESENTED BY: NAZISH KHAN

COMPSCI 726 SEMINAR

2

MOTIVATION

• Contribution: Uncover several critical vulnerabilities in OAuth SSO systems and relate them to a set of design decisions

• Problem:

• Previous research suggests that the protocol is secure

• BUT some implementation details could be inadvertently left out

• Sometimes developer may trade security for implementation simplicity and create some vulnerabilities

• Attacker can gain unauthorized access to victim user’s personal data on RP or IdP websites

3

WHAT IS SINGLE SIGN-ON?

• Session/user authentication process

• SSO credentials – token and authorization code

• Identity providers

• Relying parties

• Identity providers provide a token, which represents an user, to relying party for accessing resources as the logged in user

4

OAUTH 2.0: SERVER-FLOW

Intended for web applications that receive access tokens from their server-side program logic

5

OAUTH 2.0: CLIENT-FLOW

Intended for Javascript applications running in a web browser as they can’t embed a secret key

6

METHODOLOGY

• Authors treated RPs and IdPs as black-boxes and analysed HTTP messages

• Exploratory study vs. Confirmatory study

• Examined implementations of:

• 3 major IdPs• Google

• Facebook

• Microsoft

• Adversary Model – Web Attacker or Passive Network Attacker

• 96 Facebook RPs listed on Google Top 1,000 websites

7

DESIGN DECISIONS

• OAuth 2.0 offers support for public clients that cannot keep their client secret secure

• Drops digital signatures in favour of SSL for RP-to-IdP communication

• IdPs offer an automatic authorization granting feature and SDK library

8

RESULTS - OVERALL

• Results uncover several critical vulnerabilities

• Confidentiality of temporary secret key can be compromised

9

ACCESS TOKEN EAVESDROPPING

• Access tokens can be eavesdropped by sniffing on unencrypted communication between browser and RP server

• In contrast to OAuth specification, 32% of RPs’ access tokens can be eavesdropped

• RPs store access token into a HTTP cookie on RP domain by default – no secured or HTTP-only attributes

10

ACCESS TOKEN THEFT VIA XSS

• Automatic authorization granting feature

• Theft possible by injecting a malicious script into any page of RP website

• Two exploits were designed to evaluate this vulnerability Exploit 1 uses current page as the redirect URI

88% of RPs are vulnerable to this exploit

Exploit 2 dynamically loads the SDK

Successful on all RPs except those that use different HTTP domain for receiving authorization responses

11

IMPERSONATION

• This vulnerability works by sending a stolen or guessed SSO credential to RP’s sign-in endpoint through an attacker-controller user agent

• 9% of RPs use user’s IdP profile as an SSO credential

• Successfully carried out if:

• Attacker can obtain or guess a copy of victim’s SSO credentials

• SSO credentials are not limited to one-time use

• RP in question does not do proper checking

12

SESSION SWAPPING

• Exploiting the lack of contextual binding vulnerability

• A successful exploit allows an attacker to stealthily log victim user into RP as the attacker to spoof victim’s personal data or mount an XSS attack

• Intercepts SSO credential from IdP, embedding it in an HTML construct

13

FORCE-LOGIN CSRF

• Allows an attacker to stealthily force a victim user to sign into the RP

• Attack URL is usually embossed in an HTML construct causing automatic issue of malicious request

• After a successful attack, an adversary can use CSRF attacks to alter user’s profile information of 21% of evaluated RPs

• It can also actively carry out subsequent attacks without waiting for the user due to the automatic authorization granting feature

15

CRITICISM

• Restriction to systems using English

• Study concentrates on specific attacks

• OAuth protocol concerning mobile devices?

• Only examined high profile IdPs and RPs found in 1,000 most-visited websites

• Realistic vulnerabilities?

• Who takes the responsibility? IdPs or RPs or both?

16

REALISTIC VULNERABILITIES?

• Study does not explore the root causes of these vulnerabilities in depth

• The extent to which these vulnerabilities exist in the wild has not been shown

• As a result, authors advise mitigations that may be ineffective in practice

17

TRUSTING RPS?

• Authors recommend a range of mitigation techniques for RPs to implement secure systems

• Can we trust RPs with correctly managing their implementations? No

• Instead, IdPs should force proper implementations through:

• Providing correct and complete developer tools

• Forcing correct RP implementations

• Mandating the use of state parameter

• Providing proper documentation

18

SUMMARY

• OAuth 2.0 favours simplicity over security

• Authors believe that OAuth 2.0 at the hand of most developers is likely to produce insecure implementations

• Critical vulnerabilities discussed are caused by a set of design decisions

19

Questions?