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 1 2012/11/20 曾毓傑

2. Outline Introduction OAuth 2.0 Analysis Approach Evaluation and Results Discussion Recommendations Conclusion 2

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 3

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 4

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 5

6. How OAuth 2.0 Server-flow Works? 6 User(with browser)Identity ProviderRelying Party Request SSO loginResponse redirect to IdP response_type client_id redirect_uri scope (state) ins.com/fblogin Redirecting… Please wait…

7. How OAuth 2.0 Server-flow Works? 7 User(with browser)Identity ProviderRelying Party Request SSO loginResponse redirect to IdP response_type client_id redirect_uri scope (state) Redirect to IdP website for authorization Response authorization confirm pageAllow RP to access user’s data fb.com/oauth2 wants to access your personal data Allow

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

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

10. How OAuth 2.0 Client-flow Works? 10 User(with browser)Identity ProviderRelying Party JavaScript on redirected page extract access token from URL fragment Response with user’s information ins.com/redirect Extracting access token… Please wait… ins.com Welcome, Response redirect to RP using URL fragment access_token (state) Request IdP’s API with access token access_token

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 11

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 12

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 13

14. Evaluation and Results Access Token Eavesdropping Access Token Theft via XSS Impersonation Session Swapping Force-login CSRF 14

15. 1. Access Token Eavesdropping This exploit eavesdrops access token by sniffing on the unencrypted communication between the browser and RP server According to the OAuth spec, access token shouldn’t appear on network traffic between browser and RP server when using server-flow 15 User(with browser)Identity ProviderRelying Party Request for exchanging access token code client_id client_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 16

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 17 User(with browser)Identity ProviderRelying Party Request SSO login by XSS JavaScript response_type client_id redirect_uri scope (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 18

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 19

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 20 User(with browser)Identity ProviderRelying Party 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 21

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 22

23. Discussion Authentication State Gap Automatic Authorization Granting Cross-domain communication in SDK Security Implications of Stolen Tokens Vulnerability Interplays 23

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 24

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 25

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 26

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 27

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 28

29. Visualization and Analysis of Results 96 websites with discovered vulnerabilities Permission those websites wants 29

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 30

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 31