WPSE: F ORTIFYING W EB P ROTOCOLS VIA B ROWSER -S IDE S ECURITY M ONITORING Marco Squarcina Joint work w. Stefano Calzavara, Riccardo Focardi, Matteo Ma ff ei, Clara Schneidewind, Mauro Tempesta 4th OAuth Security Workshop 2019 March 21, 2019 - Stuttgart/Germany
O VERVIEW OF A W EB P ROTOCOL RP IdP
O VERVIEW OF A W EB P ROTOCOL RP IdP
O VERVIEW OF A W EB P ROTOCOL RP IdP
O VERVIEW OF A W EB P ROTOCOL user = lavish, pwd = ●●●●●●● RP IdP
M OTIVATIONS Designing and implementing web protocols is HARD! • Bansal et al ., Discovering Concrete Attacks on Website Authorization by Formal Analysis ( S&P ’12 ) • Wang et al., Signing Me onto Your Accounts through Facebook and Google: A Tra ffi c- Guided Security Study of Commercially Deployed Single-Sign-On Web Services ( S&P’12 ) • Sun and Beznosov, The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems ( CCS’12 ) • Fett et al., A Comprehensive Formal Security Analysis of OAuth 2.0 ( CCS’16 ) • …
M OTIVATIONS Designing and implementing web protocols is HARD! • Bansal et al ., Discovering Concrete Attacks on Website Authorization by Formal Analysis ( S&P ’12 ) • Wang et al., Signing Me onto Your Accounts through Facebook and Google: A Tra ffi c- Guided Security Study of Commercially Deployed Single-Sign-On Web Services ( S&P’12 ) • Sun and Beznosov, The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems ( CCS’12 ) • Fett et al., A Comprehensive Formal Security Analysis of OAuth 2.0 ( CCS’16 ) • … WHY?
M OTIVATIONS Designing and implementing web protocols is HARD! • Bansal et al ., Discovering Concrete Attacks on Website Authorization by Formal Analysis ( S&P ’12 ) • Wang et al., Signing Me onto Your Accounts through Facebook and Google: A Tra ffi c- Guided Security Study of Commercially Deployed Single-Sign-On Web Services ( S&P’12 ) • Sun and Beznosov, The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems ( CCS’12 ) • Fett et al., A Comprehensive Formal Security Analysis of OAuth 2.0 ( CCS’16 ) • … The browser is not aware of the existence of WHY? web protocols and of their semantics!
O UR P ROPOSAL - WPSE Extend the browser with a lightweight security monitor that enforces the compliance of the browser behaviors with respect to the web protocol specifications
O UR P ROPOSAL - WPSE Implemented as a Google Chrome extension Extend the browser with a lightweight security monitor that enforces the compliance of the browser behaviors with respect to the web protocol specifications
O UR P ROPOSAL - WPSE Implemented as a Google Chrome extension Extend the browser with a lightweight security monitor that enforces the compliance of the browser behaviors with respect to the web protocol specifications Advantages 1. users of vulnerable websites are automatically protected against a large class of attacks 2. specifications can be written once and enforced on several sites
C HALLENGES IN W EB P ROTOCOLS Compliance with the protocol flow 1 • Preserve the intended sequence of messages 2 exchanged by honest participants • Perform integrity checks on the contents of protocol 3 messages Secrecy of message components • Enforce the confidentiality of protocol secrets like tokens and credentials to avoid leaks to 3rd parties
T ACKLING THE C HALLENGES IN WPSE WPSE protocol specification : • Structure and order of messages • Desired security policies (confidentiality and integrity)
T ACKLING THE C HALLENGES IN WPSE 1 Protocol messages are blocked if • not in the correct order 2 • integrity constraints on messages are not satisfied 3 Always allow protocol unrelated messages Secrets in incoming messages are substituted with random placeholders before they enter the DOM Placeholders in outgoing requests are replaced with secrets only if sent to origins entitled to learn them
F ORTIFYING OA UTH 2.0 1 2 RP_id, rdr_uri, state Login form 3 user = lavish, pwd = ●●●●●●● auth_code, state 4 rdr_uri auth_code, RP_id, rdr_uri 5 access_token 6 access_token 7 U resource 8 RP IdP
F ORTIFYING OA UTH 2.0 1 WPSE 2 RP_id, rdr_uri, state Protocol Flow Login form 2 → 3 → 4 3 user = lavish, pwd = ●●●●●●● with same rdr_uri and state auth_code, state in steps 2, 4 4 rdr_uri auth_code, RP_id, rdr_uri 5 access_token 6 access_token 7 U resource 8 RP IdP
F ORTIFYING OA UTH 2.0 1 WPSE 2 RP_id, rdr_uri, state Protocol Flow Login form 2 → 3 → 4 3 user = lavish, pwd = ●●●●●●● with same rdr_uri and state auth_code, state in steps 2, 4 4 Secrecy rdr_uri RP < auth_code, state > IdP auth_code, RP_id, rdr_uri 5 access_token 6 access_token 7 U resource 8 RP IdP
S ESSION S WAPPING [SB12] 1 A 2 RP_id, rdr_uri Login form 3 user = h4ckerb0y, pwd = ●●●●●●● A auth_code U RP IdP � 8
S ESSION S WAPPING [SB12] 1 A 2 RP_id, rdr_uri Login form 3 user = h4ckerb0y, pwd = ●●●●●●● Gimme A auth_code torrents plz! U RP IdP � 8
S ESSION S WAPPING [SB12] 1 A 2 RP_id, rdr_uri Login form 3 user = h4ckerb0y, pwd = ●●●●●●● Gimme A auth_code torrents plz! 4 A auth_code rdr_uri A auth_code, RP_id, rdr_uri 5 A access_token 6 U A access_token 7 A resource 8 RP IdP � 8
S ESSION S WAPPING [SB12] 1 A 2 RP_id, rdr_uri Login form 3 user = h4ckerb0y, pwd = ●●●●●●● Gimme A auth_code torrents plz! 4 A auth_code rdr_uri A auth_code, RP_id, rdr_uri ! 5 n o i t a l o i v E S w P A access_token o W fl 6 l o y U c b o d t o e k r P c o l A access_token b t 7 s e u q e R A resource 8 RP IdP � 8
S TATE L EAK A TTACK [FKS16] 1 2 RP_id, rdr_uri, state U Login form 3 user = lavish, pwd = ●●●●●●● auth_code, state 4 rdr_uri auth_code, RP_id, rdr_uri 5 access_token 6 access_token 7 resource 8 RP IdP � 9
S TATE L EAK A TTACK [FKS16] 1 2 RP_id, rdr_uri, state U Login form 3 user = lavish, pwd = ●●●●●●● auth_code, state 4 rdr_uri auth_code, RP_id, rdr_uri 5 access_token Referer header 6 auth_code, state access_token 7 resource 8 Attacker’s website RP IdP � 9
S TATE L EAK A TTACK [FKS16] 1 2 RP_id, rdr_uri, state U Login form 3 user = lavish, pwd = ●●●●●●● auth_code, state W 4 P S rdr_uri ? w E i t r h e ? p r a l a auth_code, RP_id, rdr_uri n c ? d 5 e o s m s e p access_token c l Referer header 6 r a e c t e d h auth_code, state a access_token o t a 7 l d e r s resource 8 Attacker’s website RP IdP � 9
E XPERIMENTAL E VALUATION • Manual investigation of 30 RPs for each IdP from Alexa top 100K • Analyzed both authorization code mode and implicit mode of OAuth 2.0 Security Compatibility • Leakage of sensitive data due to Problems due to security critical tracking/ads libraries (4 RPs) deviations in the protocol flow • Lack or misuse of the state (7 RPs), e.g. auth code is sent twice, parameter (55 RPs) second time over HTTP
A TTACKING G OOGLE I MPLEMENTATION OF SAML 2.0 URI 1 A 2 SAMLRequest, RelayState = URI Login form 3 User credentials SAMLResponse, RelayState = URI 4 SAMLResponse, RelayState = URI Lack of contextual binding between steps 2 and 4. 5 SAMLResponse and URI RelayState are su ffi cient to U A resource 6 allow U to access the resource at URI. SP IdP � 11
N EW A TTACK A GAINST G OOGLE SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …)
N EW A TTACK A GAINST G OOGLE SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …) Feb 4, 2018 Report to Google
N EW A TTACK A GAINST G OOGLE SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …) Feb 27, 2018 Feb 4, 2018 Report to Google
N EW A TTACK A GAINST G OOGLE SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …) Feb 27, 2018 May 7, 2018 Feb 4, 2018 Report to Google
N EW A TTACK A GAINST G OOGLE SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …) Feb 27, 2018 May 7, 2018 Feb 4, 2018 And now? Report to Google
S UMMING U P Lightweight policies on the client-side suffice to enforce provable security guarantees in web protocols
S UMMING U P Lightweight policies on the client-side suffice to enforce provable security guarantees in web protocols • Support for additional protocols e.g., e-payments • Automatic techniques to synthesize WPSE policies from protocol specifications / browser tra ffi c • Embed WPSE into real browsers
T HANK Y OU ! Q&A @blueminimal marco.squarcina@tuwien.ac.at https://sites.google.com/site/wpseproject/
Recommend
More recommend
