1. THE DEVIL IS IN THE (IMPLEMENTATION) DETAILS: AN EMPIRICAL ANALYSIS OF OAUTH SSO SYSTEMS SAN-TSAI SUN & KONSTANTIN BEZNOSOV PRESENTED BY: NAZISH KHAN COMPSCI 726 SEMINAR 1

2. MOTIVATION Contribution: Uncover several critical vulnerabilities in OAuth SSO systems and relate them to a set of design decisions Problem: Previous research suggests that the protocol is secure BUT some implementation details could be inadvertently left out Sometimes developer may trade security for implementation simplicity and create some vulnerabilities Attacker can gain unauthorized access to victim user’s personal data on RP or IdP websites 2

3. WHAT IS SINGLE SIGN-ON? Session/user authentication process SSO credentials – token and authorization code Identity providers Relying parties Identity providers provide a token, which represents an user, to relying party for accessing resources as the logged in user 3

4. OAUTH 2.0: SERVER-FLOW Intended for web applications that receive access tokens from their server-side program logic 4

5. OAUTH 2.0: CLIENT-FLOW Intended for Javascript applications running in a web browser as they can’t embed a secret key 5

6. METHODOLOGY Authors treated RPs and IdPs as black-boxes and analysed HTTP messages Exploratory study vs. Confirmatory study Examined implementations of: 3 major IdPs Google Facebook Microsoft Adversary Model – Web Attacker or Passive Network Attacker 96 Facebook RPs listed on Google Top 1,000 websites 6

7. DESIGN DECISIONS OAuth 2.0 offers support for public clients that cannot keep their client secret secure Drops digital signatures in favour of SSL for RP-to-IdP communication IdPs offer an automatic authorization granting feature and SDK library 7

8. RESULTS - OVERALL Results uncover several critical vulnerabilities Confidentiality of temporary secret key can be compromised 8

9. ACCESS TOKEN EAVESDROPPING Access tokens can be eavesdropped by sniffing on unencrypted communication between browser and RP server In contrast to OAuth specification, 32% of RPs’ access tokens can be eavesdropped RPs store access token into a HTTP cookie on RP domain by default – no secured or HTTP-only attributes 9

10. ACCESS TOKEN THEFT VIA XSS Automatic authorization granting feature Theft possible by injecting a malicious script into any page of RP website Two exploits were designed to evaluate this vulnerability Exploit 1 uses current page as the redirect URI 88% of RPs are vulnerable to this exploit Exploit 2 dynamically loads the SDK Successful on all RPs except those that use different HTTP domain for receiving authorization responses 10

11. IMPERSONATION This vulnerability works by sending a stolen or guessed SSO credential to RP’s sign-in endpoint through an attacker-controller user agent 9% of RPs use user’s IdP profile as an SSO credential Successfully carried out if: Attacker can obtain or guess a copy of victim’s SSO credentials SSO credentials are not limited to one-time use RP in question does not do proper checking 11

12. SESSION SWAPPING Exploiting the lack of contextual binding vulnerability A successful exploit allows an attacker to stealthily log victim user into RP as the attacker to spoof victim’s personal data or mount an XSS attack Intercepts SSO credential from IdP, embedding it in an HTML construct 12

13. FORCE-LOGIN CSRF Allows an attacker to stealthily force a victim user to sign into the RP Attack URL is usually embossed in an HTML construct causing automatic issue of malicious request After a successful attack, an adversary can use CSRF attacks to alter user’s profile information of 21% of evaluated RPs It can also actively carry out subsequent attacks without waiting for the user due to the automatic authorization granting feature 13

14. RECOMMENDATIONS For IdPs Explicit authorization flow registration Whitelist redirect URLs Support token refresh mechanism Enforce single-use of authorization code Avoid saving access token to cookie Explicit user content Explicit user authentication For RPs SSO Domain separation Confidentiality of SSO credentials Authenticity of SSO credentials 14

15. CRITICISM Restriction to systems using English Study concentrates on specific attacks OAuth protocol concerning mobile devices? Only examined high profile IdPs and RPs found in 1,000 most-visited websites Realistic vulnerabilities? Who takes the responsibility? IdPs or RPs or both? 15

16. REALISTIC VULNERABILITIES? Study does not explore the root causes of these vulnerabilities in depth The extent to which these vulnerabilities exist in the wild has not been shown As a result, authors advise mitigations that may be ineffective in practice 16

17. TRUSTING RPS? Authors recommend a range of mitigation techniques for RPs to implement secure systems Can we trust RPs with correctly managing their implementations? No Instead, IdPs should force proper implementations through: Providing correct and complete developer tools Forcing correct RP implementations Mandating the use of state parameter Providing proper documentation 17

18. SUMMARY OAuth 2.0 favours simplicity over security Authors believe that OAuth 2.0 at the hand of most developers is likely to produce insecure implementations Critical vulnerabilities discussed are caused by a set of design decisions 18

19. Questions? 19