WPSE: F ORTIFYING W EB P ROTOCOLS VIA B ROWSER -S IDE S ECURITY M ONITORING Stefano Calzavara Mauro Tempesta Matteo Ma ff ei Riccardo Focardi Marco Squarcina Clara Schneidewind August 17, 2018 - 27 th Usenix Security Symposium
O VERVIEW OF A W EB P ROTOCOL RP IdP � 2
O VERVIEW OF A W EB P ROTOCOL RP IdP � 2
O VERVIEW OF A W EB P ROTOCOL RP IdP � 2
O VERVIEW OF A W EB P ROTOCOL user = MrStorm, pwd = ●●●●●●● RP IdP � 2
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 ) • … � 3
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? � 3
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! � 3
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 � 4
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 � 4
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 � 4
S ECURITY 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 � 5
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 • Always allow protocol unrelated messages 3 • 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 = MrStorm, pwd = ●●●●●●● auth_code, state 4 rdr_uri 5 auth_code, RP_id, rdr_uri access_token 6 access_token 7 U resource 8 RP IdP � 7
F ORTIFYING OA UTH 2.0 1 WPSE 2 RP_id, rdr_uri, state Protocol Flow Login form 2 → 3 → 4 3 user = MrStorm, pwd = ●●●●●●● with same rdr_uri and state in steps 2, 4 auth_code, state 4 rdr_uri 5 auth_code, RP_id, rdr_uri access_token 6 access_token 7 U resource 8 RP IdP � 7
F ORTIFYING OA UTH 2.0 1 WPSE 2 RP_id, rdr_uri, state Protocol Flow Login form 2 → 3 → 4 3 user = MrStorm, pwd = ●●●●●●● with same rdr_uri and state in steps 2, 4 auth_code, state 4 Secrecy rdr_uri RP < auth_code, state > IdP 5 auth_code, RP_id, rdr_uri access_token 6 access_token 7 U resource 8 RP IdP � 7
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 � 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 � 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 � 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 o A access_token W fl 6 l o y U b c o d t o e r k P c o l b A access_token t 7 s e u q e R A resource 8 RP IdP � 8 � 8
S TATE L EAK A TTACK [FKS16] 1 2 RP_id, rdr_uri, state U Login form 3 user = MrStorm, 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 � 9
S TATE L EAK A TTACK [FKS16] 1 2 RP_id, rdr_uri, state U Login form 3 user = MrStorm, 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 � 9
S TATE L EAK A TTACK [FKS16] 1 2 RP_id, rdr_uri, state U Login form 3 user = MrStorm, 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 Referer header l 6 r a e c t e d h a auth_code, state access_token o t a 7 l d e r s resource 8 Attacker’s website RP IdP � 9 � 9
F ORMAL R ESULTS (H1) The protocol fulfills safety property P with a benign webpage (H2) WPSE allows only a subset of the I/O sequences performed by the browser in a honest protocol run (H3) Secrets are not leaked and securely stored by the browser � 10
F ORMAL R ESULTS (H1) The protocol fulfills safety property P with a benign webpage (H2) WPSE allows only a subset of the I/O sequences performed by the browser in a honest protocol run (H3) Secrets are not leaked and securely stored by the browser The protocol fulfills P with a compromised browser monitored by WPSE � 10
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 advertisement libraries (4 RPs) deviations in the protocol flow (7 • Lack or misuse of the state RPs), e.g. auth code is sent twice, parameter (55 RPs) second time over HTTP � 11
A N EW A TTACK A GAINST G OOGLE I MPLEMENTATION OF SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Google Drive, GMail, …) � 12
A N EW A TTACK A GAINST G OOGLE I MPLEMENTATION OF SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Google Drive, GMail, …) Feb 4 Report to Google � 12
A N EW A TTACK A GAINST G OOGLE I MPLEMENTATION OF SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Google Drive, GMail, …) Feb 27 Feb 4 Report to Google � 12
A N EW A TTACK A GAINST G OOGLE I MPLEMENTATION OF SAML 2.0 • Similar to the session swapping attack presented before • Login CSRF against Google Suite applications (Google Drive, GMail, …) Feb 27 Apr 25 Feb 4 Report to Google � 12
S UMMING U P Lightweight policies on the client-side suffice to enforce provable security guarantees in web protocols � 13
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 � 13
T HANK Y OU ! Q UESTIONS ? tempesta@unive.it https://sites.google.com/site/wpseproject/
Recommend
More recommend
