1
The Devil is in the (Implementation)
Details: An Empirical Analysis of OAuth
SSO Systems
San-Tsai Sun and Konstantin Beznosov
University of British Columbia
Vancouver, Canada
ACM Conference on Computer and Communications
Security 2012
2012/11/20 曾毓傑
2
Outline
• Introduction
• OAuth 2.0
• Analysis Approach
• Evaluation and Results
• Discussion
• Recommendations
• Conclusion
3
Introduction
• Single Sign-On(SSO) allows applications access to their
web resources without sharing their login credentials or
the full context of their data
• Facebook login to other sides for enhancing user experience
• OAuth SSO scheme makes it simple for developers to
implement the protocol
4
Introduction (Cont.)
• Previous researches suggests that the protocol is secure
• Some implementation details could be inadvertently left
out
• We need to find out:
• Well-known web vulnerabilities could be leveraged to compromise
OAuth SSO system
• The fundamental enabling causes and consequences
• How to prevent them in a practical way
5
OAuth 2.0 Background
• Identity Providers(IdP) provide a token, which
represents an user, to Relying Party(RP) for accessing
resources as logged in user
• Token, authorization code, or something to identify the
current SSO user, is called SSO credentials
• Two main types of working flows OAuth supports:
• Server-flow: use server-side programs to retrieve access token at
server side, call IdP’s API at server side
• Client-flow: user client-side programs (JavaScript) to retrieve
access token within browser, call IdP’s API within browser
6
How OAuth 2.0 Server-flow Works?
User(with browser)
Relying Party
Identity Provider
ins.com/fblogin
Request SSO login
Response redirect to IdP
response_type
client_id
redirect_uri
scope
(state)
Redirecting…
Please wait…
7
How OAuth 2.0 Server-flow Works?
User(with browser)
Relying Party
Identity Provider
fb.com/oauth2
Request SSO login
Response redirect to IdP
response_type
client_id
redirect_uri
scope
(state)
Redirect to IdP website for authorization
Response authorization confirm page
Allow RP to access user’s data
wants to
access your
personal data
Allow
8
How OAuth 2.0 Server-flow Works?
User(with browser)
Relying Party
Identity Provider
ins.com/redirect
Response redirect to RP
code
(state)
Retriving
access token…
Please wait…
Redirect to RP login page
Request for exchanging access token
code
client_id
client_secret
redirect_uri
Response with access token
access_token
9
How OAuth 2.0 Client-flow Works?
User(with browser)
Relying Party
Identity Provider
Request SSO login, JavaScript trigger redirect
response_type
client_id
redirect_uri
scope
(state)
Redirect to IdP website for authorization
Response authorization confirm page
Allow RP to access user’s data
ins.com/fblogin
fb.com/oauth2
wants to
Redirecting…
access
your
Please
wait…
personal data
Allow
10
How OAuth 2.0 Client-flow Works?
User(with browser)
Relying Party
Identity Provider
ins.com/redirect
ins.com
Response redirect to RP using URL fragment
access_token
(state)
JavaScript on redirected page extract access token
from URL fragment
Request IdP’s API with access token
access_token
Response with user’s information
Extracting
Welcome,
access token…
Please wait…
11
OAuth 2.0 Problems
• Many papers have examine this protocol and found that
this is secure
• But sometimes developer may trade security for
implementation simplicity, and create some vulnerabilities
12
Analysis Approach
• We examine Google’s Top 1000 websites, and chose 96
websites that support the use of Facebook accounts for
login
• We examine Facebook, Google, Microsoft OAuth 2.0
implementations
• Treat RP and IdP as black boxes, and record unencrypted
HTTP requests/responses between browser to those
websites
13
Threat Model
• Attacker can gain unauthorized access to victim user’s
personal data on RP or IdP websites
• Attacker may:
• Craft a website which can cause the browser to issue HTTP
request
• Sniff unencrypted network traffic between the browser and RP
14
Evaluation and Results
• Access Token Eavesdropping
• Access Token Theft via XSS
• Impersonation
• Session Swapping
• Force-login CSRF
15
1. Access Token Eavesdropping
• This exploit eavesdrops access token by sniffing on the
unencrypted communication between the browser and RP
server
User(with browser)
• According to the
OAuth spec, access token
shouldn’t appear on
network traffic between
browser and RP server
when using server-flow
Relying Party
Identity Provider
Request for exchanging access token
code
client_id
client_secret
redirect_uri
Response with access token
access_token
16
1. Access Token Eavesdropping
• Client-flow –
Facebook and Microsoft SDKs store the access token into
an HTTP cookie, without secure and HTTPonly attributes
• Server-flow (mixing Client-flow) –
Transfer access token as parameter to RP server as user
authorization
17
2. Access Token Theft via XSS
• Using IdP’s “automatic authorization granting” feature, RP
can automatically get an access token without the user’s
intervention
• Attacker can steal access token by injecting script to any
page of an RP website, and trigger the client-flow login
flow
User(with browser)
Relying Party
Identity Provider
Request SSO login by XSS JavaScript
response_type
client_id
redirect_uri
scope
(state)
Response redirect to RP using URL fragment
access_token
(state)
18
2. Access Token Theft via XSS
• Attacker trigger JavaScript OAuth flow on RP’s website
and send out the access token out
• Attacker build a page to trigger browser bugs to get
access token from cross-domain sites
• IE 7 image rendering bug
• onerror
event handling behaviors
19
3. Impersonation
• Attacker send a stolen or guessed SSO credential to the
RP server through an attacker-controlled browser, and RP
server accept this credential
• Some websites use public information as user credential
for login, if attacker can find or guess those information
out, attacker may successfully log into RP server
• Information such as Facebook account identifier
20
4. Session Swapping
• RP server doesn’t provide a state parameter in an
authorization request
• Attacker can forge a request with stored code to trigger
RP server to login as attacker’s accout
User(with browser)
Relying Party
Identity Provider
Attacker forge this response with stored code
code
(state)
Redirect to RP login page
21
4. Session Swapping
• When victim may unwittingly use attacker’s account and
spoof victim’s personal data
• E.g. sharing photos or personal information
• Attacker can lure victim to custom page that trigger the
RP server’s login flow
22
5. Force-login CSRF
• CSRF requires the victim has already an authentication
session with the RP website
• Because there is no alarm when using OAuth IdP’s
“automatic authorization granting” feature, we can trigger
login URL to force user to login, called force-login attack
• This eliminates the requirement of CSRF attack
23
Discussion
• Authentication State Gap
• Automatic Authorization Granting
• Cross-domain communication in SDK
• Security Implications of Stolen Tokens
• Vulnerability Interplays
24
1. Authentication State Gap
• What OAuth get the user’s credentials
• Which RP server thinks the user is
• This gap enabling impersonation and session swapping
event when RP and IdP communications are SSLprotected
25
2. Automatic Authorization Granting
• Give access token to RP without user’s intervention
• Without this feature, user may need to grant the
authorization to RP every time user use RP’s service
• It’s indeed useful, but it can be harmful as well
26
3. Cross-domain communication in SDK
• When using OAuth client-flow, two domains need to
exchange some information such as access token
method, Flash, cookies are used for crossdomain communication(CDC)
• postMessage
• The lack of a thorough security analysis for CDC
mechanisms might lead to severe security compromises
27
4. Security Implications of Stolen Tokens
• OAuth provides offline permission, which grant permanent
permission to RP, until user explicitly revoke it
• And the access token becomes very crucial for user’s
personal data
28
5. Vulnerability Interplays
• Attacker can use session swapping or force-login to make
user login as attacker’s account
• RP’s website may has some XSS vulnerabilities, so
attacker can inject malicious script into his personal page
• Attacker’s account may contains malicious script that may
lead to other attacks, such as drive-by download
29
Visualization and Analysis of Results
• 96 websites with discovered vulnerabilities
• Permission those websites wants
30
Recommendations
• For IdPs
• Explicit authorization flow registration
• Whitelist redirect URIs
• Support token refresh mechanism
• Enforce single-use of authorization code
• Avoid saving access token to cookie
• Explicit user consent
• Explicit user authentication
• For RPs
• SSO Domain Separation
• Confidentiality of SSO credentials
• Authenticity of SSO credentials
31
Conclusion
• The first empirical investigation of the security of a
representative sample of most-visited OAuth SSO
implementations
• An evaluation of the discovered vulnerabilities and an
assessment of their prevalence across RP
implementations
• A development of practical recommendations for IdPs and
RPs to secure their implementations