In Usenix Security 2013
Explicating SDKs:
Uncovering Assumptions Underlying
Secure Authentication and Authorization
Rui Wang, Yuchen Zhou, Shuo Chen,
Shaz Qadeer, David Evans, Yuri Gurevich
Web Authentication & Single Sign-On
• Web Authentication
• Single Sign-On (SSO)
– BrowserID (Mozilla)
– Facebook Connect
• 250+ Million users, 2,000,000
websites
– OpenID
• one billion users, 50,000 websites
–…
2
Single Sign-On
Identity Provider (IDP)
e.g.,
Alice
Service Provider (SP)
e.g.,
• Functionality provided by Token
– Authentication: Authenticate end user to SP
– Authorization: SP can access user’s social data on IDP
Development
Development Paradigm
IDP
SDK-Client
SP
Client: FooAppc
Deployment
SDK-Server
Server:foo.com
Motivation
• Security relies on:
– SDKs
– Underlying system
– Implicit assumptions
• undocumented
• SDK providers are unaware of them
If developers use the SDKs in a reasonable ways, will the resulting
applications be secure?
NO!
A real example: use of Microsoft Live ID
✓
✗
The attacker can request a token
to view public information for
the victim and present it to App
server.
• Goal of this paper
– To systematically identify the assumptions required to use
an SDK to produce secure applications
Approach Overview
Semantic
Model
Results
• Test three sets of applications using major
authentication/authorization SDKs
– Facebook PHP SDK, Miscrosoft Live Connect, Windows 8
Authentication Broker SDK
– 78%, 86%, 67% are vulnerable
– Lead to modification of OAuth 2.0 specification
Outline
• Threat Model & Security Properties
• Semantic Modeling
– Modeling language
– Modeling adversary
– Modeling concrete modules
• Results
Threat Model
• Malicious application
– Unconstrained behavior
– Only limited to functionality provided by client
runtime
• Unconstrained external server
Security Properties
• Secrecy
– Access tokens, codes, app secret, session ID
• Authentication
– Attacker may impersonate as victim
• Authorization
– Attacker can do whatever the FooApp can do on the IDP
• Association
– (user’s ID, user’s permission, session’s ID)
Model Checker & Modeling Language
• Corral
– Performs bounded verification on a C program with
embedded assertions
– Explores all possible execution path to check whether the
assertions can be violated
• Boogie language
– ASSERT(p): whenever the program gets to this line, p holds
– ASSUME(p): assume p holds whenever the program gets
to this line
– INVARIANT(p): p always holds
– If Boogie fails to prove an assertion or an invariant, it
reports a counter example
Modeling SDKs --- Rewrite
PHP
Boogie
Modeling Underlying Systems
• IDP’s behaviors according to different input
– Challenge: no source code
– Solution: fuzzing
• Data processing on client runtime
– 1. data redirection from one server to another
– 2. delivering data to FooAppc
– 3. attaching cookies to outgoing request
• Session, request and cookies on the server side
Modeling Security Properties---Authentication
An authentication violation occurs when an attacker acquires
some knowledge that could be used to convince FooAppS that
the knowledge holder is Alice.
• Whenever an attacker acquires a knowledge k
Modeling Security Properties---Authorization
An authorization violation occurs when an attacker acquires
some permission that allows him to do whatever the session
can do.
• Whenever an attacker acquires a Code c
Asserts that Code c is not associated with Alice on FooApp
Modeling Security Properties---Association
At the return point of every web API on FooAppS, we need to
ensure the correct association of the user ID, the permission, and
the session ID.
Case Study #1: session hijacking
Session Variables:
_SESSION[‘sessionid’] = 0x01
Alice
Token
FooAppS
How FooAppS handles the token?
Session Variables:
_SESSION[‘sessionid’] = 0x01
_SESSION[‘user_id’] = Alice
Case Study: session hijacking
Session Variables:
_SESSION[‘sessionid’] = 0x01
0x02
_SESSION[‘user_id’] = Alice
Alice
Token
FooAppS
Session Variables:
_SESSION[‘sessionid’] = 0x02
Attack Using Subdomains
• Facebook’s developer portal : Heroku
– Each service app runs in a subdomain under heroku.com
Session Variables:
_SESSION[‘sessionid’] = 0x01
0x02
_SESSION[‘user_id’] = Alice
Alice
FooApp.heroku.com
MalApp.heroku.com
Case Study #2: Wrong Association
Attacker’s valid signed request
Session Variables:
_SESSION[‘access_token’] = 0xabc
_SESSION[‘user_id’] = Alice
Attacker
Case Study #3: token leakage
http://facebook.com/logout.html?......&access_token =ao231rusd…
getAccessToken()
getAccessToken()
Secret shared between
FB and App
Secret shared among FB,
user and App
http://facebook.com/logout.html?......&access_token =ao231rusd…
Conclusion
• This paper uses formal methods to identify the
underlying security assumptions form web
authentication/authorization.
• Security of implementations relies on multiple
underlying assumptions.
Thank you!