Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization Rui Wang 1 *, Yuchen Zhou 2 * † , (*Lead authors, † Speaker) Shuo Chen 1 , Shaz Qadeer 1 , David Evans 2 and Yuri Gurevich 1 1 Microsoft Research and 2 University of Virginia 1
36
Embed
Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization
Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization. Rui Wang 1 *, Yuchen Zhou 2 * † , (*Lead authors, † Speaker) Shuo Chen 1 , Shaz Qadeer 1 , David Evans 2 and Yuri Gurevich 1 1 Microsoft Research and 2 University of Virginia. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Shuo Chen1, Shaz Qadeer1, David Evans2 and Yuri Gurevich1
1Microsoft Research and 2University of Virginia
Most modern apps are empowered by online services.
2
chart source: builtwith.com
3
Single Sign-On Service
4
The requested response type, one of code or token. Defaults to code…
If the developers follow the guides properly, will the application be secure?
Facebook documentation example
5
Possible implementation
Facebook back end
dialog/oauth…1
access_token3
access_token2
exchange user info
4
user id/email
5
Welcome, Alice!6
Foo App Client
MaliciousApp Client
Foo App Server
Possible Attack
access_token3
access_token4
Welcome Alice?!7
exchange user info
5
user id/email
6
6
Video Demo
7
Who’s to blame?
Developers?
SDK providers?
Developer guide does not explicitly state that token flow MUST not be used for server-side authentication.
8
The requested response type, one of code or token. Defaults to code…
If developers follow the guides properly, will the applications be secure?
Facebook documentation example
No.• Not because of vulnerabilities in SDKs.• Due to implicit assumptions about how
to use them.
9
Implicit Assumptions
Assumptions that are o not clearly stated in the SDK’s developer guides;o related to how the SDK should be used;o essential for application’s security property.
Goal of this project: systematically find these implicit assumptions
10
Verifier
Model AssertionsAssumptions
Model checks?
Counter-Example
RefineModel
Add necessary assumptions
More to model
N Y
EnrichModel
Add relatedassertions
Y
N
Iterative process
Iterative process
General Approach
11
General Approach
Target: Single-Sign On Systems
12
System Architecture
FooAppC
Client SDK
Client runtime
Identity Provider (IdP)
FooAppS
Service SDK
Service runtime
13
Threat model
FooAppC
Client SDK
Client runtime
Identity Provider (IdP)
FooAppS
Service SDK
Service runtime
MalApp
C
Mallory
14
Desired Security Properties
AuthenticationMallory cannot sign into Foo app as Alice.
AuthorizationMallory cannot access data that Alice have not granted permission to Mallory.
AssociationThe user identity, user’s permission (authorization result), and session identity must represent the same person.
15
Verifier
Model AssertionsAssumptions
3 security properties
assert(logged_in_user != _Alice);
16
System Architecture
FooAppC
Client SDK
Client runtime
Identity Provider (IdP)
FooAppS
Service SDK
Service runtime
17
Modeling SDKs
FooAppC
Client SDK
Client runtime
Identity Provider (IdP)
FooAppS
Service SDK
Service runtime
Concrete module with src or documentation
18
Modeling underlying system layer
FooAppC
Client SDK
FooAppS
Service SDK
Client runtime
Identity Provider (IdP)
Service runtime
Concrete module with src or documentationBlack-box concrete module
19
Modeling Foo application
Client SDK Service SDK
Client runtime
Identity Provider (IdP)
Service runtime
FooAppC FooAppS
Abstract module subject to dev guideConcrete module with src or documentationBlack-box concrete module
20
Modeling Mallory
FooAppC
Client SDK
Client runtime
Identity Provider (IdP)
FooAppS
Service SDK
Service runtime
MalApp
C
Mallory
Abstract module subject to dev guideConcrete module with src or documentationBlack-box concrete module Abstract module subject to knowledge pool
21
FooAppC
Client SDK
Client runtime
Identity Provider (IdP)
FooAppS
Service SDK
Service runtime
MalApp
C
Mallory
KnowledgePool
ConcreteModules
Test Harness
Modeling Mallory
Abstract module subject to dev guideConcrete module with src or documentationBlack-box concrete module Abstract module subject to knowledge pool
22
Verifier
Model AssertionsAssumptions
3 security properties
Basic system components
SDK documentation
SDK documentationand previously
uncovered assumptions
All relevant system
components
23
Boogie/BoogiePL: Symbolic execution engine
Supports loop invariants and function pre/post conditions to enable unbounded verification
[1]: Boogie: An Intermediate Verification Language. http://research.microsoft.com/en-us/projects/boogie/
Assumption (in plain text):getLogoutUrl() must not return an
application access token to the client.
Best outcome: Facebook fixed their SDK code so this
assumption is not needed in the newer version.
30
Example assumption from Windows Live
function saveRefreshToken($refreshToken){ // save the refresh token associated with the user id on the site.}function handleTokenResponse($token, $error = null){ $authCookie = $_COOKIE[AUTHCOOKIE]; $cookieValues = parseQueryString($authCookie);…
if (!empty($token->{ REFRESHTOKEN })) { saveRefreshToken($token->{ REFRESHTOKEN }); }…
original Live ID developer guide
associate refresh token with the user ID obtained from the global variable $_COOKIE
associate refresh token with the user ID obtained from the refresh token passed into the function
Two interpretations
procedure {:inline 1} saveRefreshToken (refresh_token_index: int, RP_Cookie_index: int)modifies RP_Refresh_Token_index;{ var user: User; //call user := get_User_ID(RP_Cookie_index); user := Refresh_Token__user_ID[refresh_token_index]; if (user == _nobody) {return;} RP_Refresh_Token_index[user] := refresh_token_index;}
function saveRefreshToken(…){ // save the refresh token associated with the user id on the site.}
31
Example assumption from Windows Live
procedure {:inline 1} saveRefreshToken (refresh_token_index: int, RP_Cookie_index: int)modifies RP_Refresh_Token_index;{ var user: User; call user := get_User_ID(RP_Cookie_index);
user := Refresh_Token__user_ID[refresh_token_index]; if (user == _nobody) {return;} RP_Refresh_Token_index[user] := refresh_token_index;}
32
Example assumption from Windows Live
function saveRefreshToken($refreshToken){ // save the refresh token and associate it with the user identified by your site credential system.}