1 / 31

The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems

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 曾毓傑. Outline. Introduction OAuth 2.0

Download Presentation

The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems

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. 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 Redirecting…Please wait… Response redirect to IdP response_typeclient_idredirect_uriscope(state)

  7. How OAuth 2.0 Server-flow Works? User(with browser) Relying Party Identity Provider fb.com/oauth2 Request SSO login wants to access your personal data Response redirect to IdP response_typeclient_idredirect_uriscope(state) Allow Redirect to IdP website for authorization Response authorization confirm page Allow RP to access user’s data

  8. How OAuth 2.0 Server-flow Works? User(with browser) Relying Party Identity Provider ins.com/redirect Response redirect to RP code(state) Retrivingaccess token…Please wait… Redirect to RP login page Request for exchanging access token codeclient_idclient_secret redirect_uri Response with access token access_token

  9. How OAuth 2.0 Client-flow Works? User(with browser) Relying Party Identity Provider ins.com/fblogin fb.com/oauth2 Request SSO login, JavaScript trigger redirect response_typeclient_idredirect_uriscope(state) wants to access your personal data Redirecting…Please wait… Allow Redirect to IdP website for authorization Response authorization confirm page Allow RP to access user’s data

  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) Extractingaccess token…Please wait… JavaScript on redirected page extract access tokenfrom URL fragment Request IdP’s API with access token access_token Welcome, Response with user’s information

  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 • According to theOAuth spec, access tokenshouldn’t appear onnetwork traffic between browser and RP serverwhen using server-flow User(with browser) Relying Party Identity Provider Request for exchanging access token codeclient_idclient_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_typeclient_idredirect_uriscope(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 SSL-protected

  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 • postMessage method, Flash, cookies are used for cross-domain communication(CDC) • 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

More Related