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

Most modern apps are empowered by online services. 2 chart source: builtwith.com

Single Sign-On Service 3

The requested response type, one of code or token. Defaults to code… 4 If the developers follow the guides properly, will the application be secure? Facebook documentation example

Possible implementation 5 Facebook back end dialog/oauth… 1 access_token 3 2 exchange user info 4 user id/ 5 Welcome, Alice! 6 Foo App Client Malicious App Client Foo App Server Possible Attack access_token 3 4 Welcome Alice?! 7 exchange user info 5 user id/ 6

Video Demo 6

Who’s to blame? Developers? SDK providers? 7

The requested response type, one of code or token. Defaults to code… 8 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.

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 9

10 Verifier ModelAssertionsAssumptions Model checks? Counter- Example Refine Model Add necessary assumptions More to model NY Enrich Model Add related assertions Y N Iterative process General Approach

11 General Approach

System Architecture 12 FooApp C Client SDK Client runtime Identity Provider (IdP) FooApp S Service SDK Service runtime

Threat model 13 FooApp C Client SDK Client runtime Identity Provider (IdP) FooApp S Service SDK Service runtime MalApp C Mallory

Desired Security Properties Authentication Mallory cannot sign into Foo app as Alice. Authorization Mallory cannot access data that Alice have not granted permission to Mallory. Association The user identity, user’s permission (authorization result), and session identity must represent the same person. 14

15 Verifier ModelAssertionsAssumptions 3 security properties assert(logged_in_user != _Alice);

System Architecture 16 FooApp C Client SDK Client runtime Identity Provider (IdP) FooApp S Service SDK Service runtime

Modeling SDKs 17 FooApp C Client SDK Client runtime Identity Provider (IdP) FooApp S Service SDK Service runtime Concrete module with src or documentation

Modeling underlying system layer 18 FooApp C Client SDK FooApp S Service SDK Client runtime Identity Provider (IdP) Service runtime Concrete module with src or documentation Black-box concrete module

Modeling Foo application 19 Client SDK Service SDK Client runtime Identity Provider (IdP) Service runtime FooApp C FooApp S Abstract module subject to dev guide Concrete module with src or documentation Black-box concrete module

Modeling Mallory 20 FooApp C Client SDK Client runtime Identity Provider (IdP) FooApp S Service SDK Service runtime MalApp C Mallory Abstract module subject to dev guide Concrete module with src or documentation Black-box concrete module Abstract module subject to knowledge pool

21 FooApp C Client SDK Client runtime Identity Provider (IdP) FooApp S Service SDK Service runtime MalApp C Mallory Knowledge Pool Knowledge Pool Concrete Modules Test Harness Modeling Mallory Abstract module subject to dev guide Concrete module with src or documentation Black-box concrete module Abstract module subject to knowledge pool

22 Verifier ModelAssertions Assumptions 3 security properties Basic system components SDK documentation and previously uncovered assumptions SDK documentation and previously uncovered assumptions All relevant system components

Boogie/BoogiePL: Symbolic execution engine Supports loop invariants and function pre/post conditions to enable unbounded verification 23 [1]: Boogie: An Intermediate Verification Language. Verifier: Boogie [1] ModelAssertions Assumptions 3 security properties SDK documentation and previously uncovered assumptions SDK documentation and previously uncovered assumptions All relevant system components

24 Verifier ModelAssertionsAssumptions Model checks? Counter- Example Refine Model Add necessary assumptions More to model NY Enrich Model Add related assertions Y N Results

Results overview Explicated three SDKs: (6 months) Many implicit assumptions were found: 25 5 cases reported, 4 fixed, 3 bounties (3x). One case reported; documentation revised. Paragraph added to OAuth 2.0 standard. Majority of tested apps vulnerable due to failure to ensure at least one uncovered assumption. Facebook SSO PHP SDK Windows 8 SDK for modern apps Windows Live connect SDK

SDK models 26 Facebook PHP Source codeBoogie PL Model

procedure {:inline 1} dialog_oauth(IdPLoggedInUser:User, client_id: AppID, redirect_domain: Web_Domain, scope:Scope, response_type:ResponseType) returns (r:int, Response_data: int) modifies Access_Tokens__TokenValue, Access_Tokens__user_ID, Access_Tokens__Scope; modifies Codes__user_ID,Codes__App_ID,Codes__Scope; modifies … { var access_token:int, code:int, sr:int; … if (response_type==_Token || response_type==_Signed_Request){ havoc access_token; //it means "access_token := *;" … IdP_Signed_Request_signature[sr]:=ValidIdPSignature; IdP_Signed_Request_oauth_token[sr]:=access_token; IdP_Signed_Request_code[sr]:=code; IdP_Signed_Request_user_ID[sr]:= IdPLoggedInUser; IdP_Signed_Request_app_id[sr]:= client_id; } if (response_type==_Token) { Response_data:=access_token; } else if (response_type==_Code) { Response_data:=code; } else { Response_data:=sr; } r:=200; } API models 27 Facebook Dialog API documentation Boogie model procedure {:inline 1} dialog_oauth(IdPLoggedInUser:User, client_id: AppID, redirect_domain: Web_Domain, scope:Scope, response_type:ResponseType) returns (r:int, Response_data: int) modifies Access_Tokens__TokenValue, Access_Tokens__user_ID, Access_Tokens__Scope; modifies Codes__user_ID,Codes__App_ID,Codes__Scope; modifies … { var access_token:int, code:int, sr:int; … if (response_type==_Token || response_type==_Signed_Request){ havoc access_token; //it means "access_token := *;" … IdP_Signed_Request_signature[sr]:=ValidIdPSignature; IdP_Signed_Request_oauth_token[sr]:=access_token; IdP_Signed_Request_code[sr]:=code; IdP_Signed_Request_user_ID[sr]:= IdPLoggedInUser; IdP_Signed_Request_app_id[sr]:= client_id; } if (response_type==_Token) { Response_data:=access_token; } else if (response_type==_Code) { Response_data:=code; } else { Response_data:=sr; } r:=200; }

Example vulnerability from Facebook SDK

Example assumption from Facebook SDK 29 procedure {:inline 1} getLogoutUrl() returns (API_id: API_ID, …) modifies …; { var test_t:int ; call access_token := getAccessToken(); call test_t := getApplicationAccessToken(); assume(access_token != test_t); API_id := API_id_FBConnectServer_login_php; … return; } Assumption (in the model) 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.

Example assumption from Windows Live 30 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. }

Example assumption from Windows Live 31 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; }

Example assumption from Windows Live 32 function saveRefreshToken($refreshToken) { // save the refresh token and associate it with the user identified by your site credential system. } function handleTokenResponse($token, $error = null) { $authCookie = $_COOKIE[AUTHCOOKIE]; $cookieValues = parseQueryString($authCookie); if (!empty($token)) … new Live ID developer guide

Testing Popular Apps 33 Facebook showcase applications Popular Windows 8 modern applications using Facebook SSO

Testing Results 34 Test SetNumber of AppsVulnerable Illustrative example2721 (78%) Assumption A1 (in the paper)76 (86%) Assumption A6 (in the paper)2114 (67%)

Conclusion Missed implicit assumptions can lead to many vulnerabilities when integrating third-party services. What we advocate: SDK providers explicate SDKs before release. o Fix SDK Code o Develop Automated Checker o Improve SDK documentation 35

Thank you! 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 36 Models available at: Visit project website for more info: Visit project website for more info: