1 / 26

Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization

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)

royal
Download Presentation

Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. In Usenix Security 2013 Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization Rui Wang, Yuchen Zhou, Shuo Chen, ShazQadeer, David Evans, Yuri Gurevich

  2. 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 • …

  3. Single Sign-On Identity Provider (IDP) • Functionality provided by Token • Authentication: Authenticate end user to SP • Authorization: SP can access user’s social data on IDP Uname/passwrod e.g., Token Alice Token Service Provider (SP) e.g.,

  4. Development Paradigm IDP Development SDK-Client SDK-Server SP Client: FooAppc Server:foo.com Deployment

  5. 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!

  6. A real example: use of Microsoft Live ID ✓ • Goal of this paper • To systematically identify the assumptions required to use an SDK to produce secure applications The attacker can request a token to view public information for the victim and present it to App server. ✗

  7. Approach Overview Semantic Model

  8. 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

  9. Outline • Threat Model & Security Properties • Semantic Modeling • Modeling language • Modeling adversary • Modeling concrete modules • Results

  10. Threat Model • Malicious application • Unconstrained behavior • Only limited to functionality provided by client runtime • Unconstrained external server

  11. 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)

  12. 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

  13. Modeling SDKs --- Rewrite PHP Boogie

  14. 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

  15. 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

  16. 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

  17. 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 sessionID.

  18. Case Study #1: session hijacking Session Variables: _SESSION[‘sessionid’] = 0x01 Token FooAppS Alice

  19. How FooAppS handles the token? Session Variables: _SESSION[‘sessionid’] = 0x01 _SESSION[‘user_id’] = Alice

  20. Case Study: session hijacking Session Variables: _SESSION[‘sessionid’] = 0x01 _SESSION[‘user_id’] = Alice 0x02 Token FooAppS Alice Session Variables: _SESSION[‘sessionid’] = 0x02

  21. Attack Using Subdomains • Facebook’s developer portal : Heroku • Each service app runs in a subdomain under heroku.com Session Variables: _SESSION[‘sessionid’] = 0x01 _SESSION[‘user_id’] = Alice 0x02 FooApp.heroku.com Alice Set cookie: sessionid = 0x02 MalApp.heroku.com

  22. Case Study #2: Wrong Association Attacker’s valid signed request Session Variables: _SESSION[‘access_token’] = 0xabc _SESSION[‘user_id’] = Alice Attacker

  23. Case Study #3: token leakage http://facebook.com/logout.html?......&access_token =ao231rusd… getAccessToken()

  24. getAccessToken() Secret shared between FB and App Secret shared among FB, user and App http://facebook.com/logout.html?......&access_token =ao231rusd…

  25. Conclusion • This paper uses formal methods to identify the underlying security assumptions form web authentication/authorization. • Security of implementations relies on multiple underlying assumptions.

  26. Thank you!

More Related