WPSE: F ORTIFYING W EB P ROTOCOLS VIA B ROWSER -S IDE S ECURITY M - - PowerPoint PPT Presentation

▶
wpse f ortifying w eb p rotocols
SMART_READER_LITE
LIVE PREVIEW

WPSE: F ORTIFYING W EB P ROTOCOLS VIA B ROWSER -S IDE S ECURITY M - - PowerPoint PPT Presentation

Jun 16, 2023 231 likes •590 views

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,

slide-1
SLIDE 1

WPSE: FORTIFYING WEB PROTOCOLS 


VIA BROWSER-SIDE SECURITY MONITORING

Marco Squarcina

Joint work w. Stefano Calzavara, Riccardo Focardi, Matteo Maffei, 
 Clara Schneidewind, Mauro Tempesta

4th OAuth Security Workshop 2019 March 21, 2019 - Stuttgart/Germany

slide-2
SLIDE 2

OVERVIEW OF A WEB PROTOCOL

RP IdP

slide-3
SLIDE 3

OVERVIEW OF A WEB PROTOCOL

RP IdP

slide-4
SLIDE 4

OVERVIEW OF A WEB PROTOCOL

RP IdP

slide-5
SLIDE 5

OVERVIEW OF A WEB PROTOCOL

user = lavish, pwd = ●●●●●●● RP IdP

slide-6
SLIDE 6

MOTIVATIONS

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 Traffic-

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)
  • …
slide-7
SLIDE 7

MOTIVATIONS

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 Traffic-

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?

slide-8
SLIDE 8

MOTIVATIONS

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 Traffic-

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?

The browser is not aware of the existence of web protocols and of their semantics!

slide-9
SLIDE 9

OUR PROPOSAL - WPSE

Extend the browser with a lightweight security monitor that enforces the compliance of the browser behaviors with
 respect to the web protocol specifications

slide-10
SLIDE 10

OUR PROPOSAL - WPSE

Extend the browser with a lightweight security monitor that enforces the compliance of the browser behaviors with
 respect to the web protocol specifications

Implemented as a Google Chrome extension

slide-11
SLIDE 11

OUR PROPOSAL - WPSE

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

Implemented as a Google Chrome extension

slide-12
SLIDE 12

CHALLENGES IN WEB PROTOCOLS

1 2 3

Compliance with the protocol flow

  • Preserve the intended sequence of messages

exchanged by honest participants

  • Perform integrity checks on the contents of protocol

messages Secrecy of message components

  • Enforce the confidentiality of protocol secrets like

tokens and credentials to avoid leaks to 3rd parties

slide-13
SLIDE 13

WPSE protocol specification:

  • Structure and order of messages
  • Desired security policies (confidentiality and integrity)

TACKLING THE CHALLENGES IN WPSE

slide-14
SLIDE 14

Protocol messages are blocked if

  • not in the correct order
  • integrity constraints on messages are not satisfied

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

1 2 3

TACKLING THE CHALLENGES IN WPSE

slide-15
SLIDE 15

FORTIFYING OAUTH 2.0

user = lavish, pwd = ●●●●●●● RP_id, rdr_uri, state

RP IdP U

Login form

1 2 3

auth_code, state rdr_uri

4 5

auth_code, RP_id, rdr_uri

6

access_token

7

access_token

8

resource

slide-16
SLIDE 16

FORTIFYING OAUTH 2.0

user = lavish, pwd = ●●●●●●●

RP IdP U

Login form

1 2 3 4 5

auth_code, RP_id, rdr_uri

6

access_token

7

access_token

8

resource

WPSE

Protocol Flow 2 → 3 → 4 with same rdr_uri and state in steps 2, 4

RP_id, rdr_uri, state auth_code, state rdr_uri

slide-17
SLIDE 17

FORTIFYING OAUTH 2.0

user = lavish, pwd = ●●●●●●●

RP IdP U

Login form

1 2 3 4 5

auth_code, RP_id, rdr_uri

6

access_token

7

access_token

8

resource

WPSE

Protocol Flow 2 → 3 → 4 with same rdr_uri and state in steps 2, 4 Secrecy RP < auth_code, state > IdP

RP_id, rdr_uri, state auth_code, state rdr_uri

slide-18
SLIDE 18

SESSION SWAPPING [SB12]

user = h4ckerb0y, pwd = ●●●●●●● RP_id, rdr_uri

RP IdP

Login form

1 2 3

A auth_code

8

U A

slide-19
SLIDE 19

SESSION SWAPPING [SB12]

user = h4ckerb0y, pwd = ●●●●●●● RP_id, rdr_uri

RP IdP

Login form

1 2 3

A auth_code

8

U A

Gimme torrents plz!

slide-20
SLIDE 20

SESSION SWAPPING [SB12]

user = h4ckerb0y, pwd = ●●●●●●● RP_id, rdr_uri

RP IdP

Login form

1 2 3

A auth_code rdr_uri

4 5

A auth_code, RP_id, rdr_uri

6

A access_token

7

A access_token

8

A resource

8

U A

Gimme torrents plz!

A auth_code

slide-21
SLIDE 21

SESSION SWAPPING [SB12]

user = h4ckerb0y, pwd = ●●●●●●● RP_id, rdr_uri

RP IdP

Login form

1 2 3

A auth_code rdr_uri

4 5

A auth_code, RP_id, rdr_uri

6

A access_token

7

A access_token

8

A resource

8

U A

Gimme torrents plz!

A auth_code

P r

  • t
  • c
  • l

fl

  • w

v i

  • l

a t i

  • n

! R e q u e s t b l

  • c

k e d b y W P S E

slide-22
SLIDE 22

STATE LEAK ATTACK [FKS16]

user = lavish, pwd = ●●●●●●● RP_id, rdr_uri, state

RP IdP

Login form

1 2 3

rdr_uri

4 5

auth_code, RP_id, rdr_uri

6

access_token

7

access_token

8

resource

9

U

auth_code, state

slide-23
SLIDE 23

STATE LEAK ATTACK [FKS16]

user = lavish, pwd = ●●●●●●● RP_id, rdr_uri, state

RP IdP

Login form

1 2 3

rdr_uri

4 5

auth_code, RP_id, rdr_uri

6

access_token

7

access_token

8

resource

9

U Attacker’s website

auth_code, state

Referer header auth_code, state

slide-24
SLIDE 24

STATE LEAK ATTACK [FKS16]

user = lavish, pwd = ●●●●●●● RP_id, rdr_uri, state

RP IdP

Login form

1 2 3

rdr_uri

4 5

auth_code, RP_id, rdr_uri

6

access_token

7

access_token

8

resource

9

U Attacker’s website

auth_code, state

Referer header auth_code, state

W P S E r e p l a c e s s e c r e t d a t a w i t h r a n d

  • m

p l a c e h

  • l

d e r s

?

? ?

slide-25
SLIDE 25

EXPERIMENTAL EVALUATION

  • 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

  • Leakage of sensitive data due to

tracking/ads libraries (4 RPs)

  • Lack or misuse of the state

parameter (55 RPs)

Compatibility

Problems due to security critical deviations in the protocol flow 
 (7 RPs), e.g. auth code is sent twice, second time over HTTP

slide-26
SLIDE 26

ATTACKING GOOGLE IMPLEMENTATION OF SAML 2.0

User credentials SAMLRequest, RelayState = URI

SP IdP

Login form

1 2 3

SAMLResponse, RelayState = URI

4 5 6

A resource

11

U A

URI SAMLResponse, RelayState = URI URI

Lack of contextual binding between steps 2 and 4. SAMLResponse and RelayState are sufficient to allow U to access the resource at URI.

slide-27
SLIDE 27

NEW ATTACK AGAINST GOOGLE SAML 2.0

  • Similar to the session swapping attack presented before
  • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …)
slide-28
SLIDE 28

NEW ATTACK AGAINST GOOGLE SAML 2.0

Feb 4, 2018

Report to Google

  • Similar to the session swapping attack presented before
  • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …)
slide-29
SLIDE 29

NEW ATTACK AGAINST GOOGLE SAML 2.0

Feb 4, 2018 Feb 27, 2018

Report to Google

  • Similar to the session swapping attack presented before
  • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …)
slide-30
SLIDE 30

NEW ATTACK AGAINST GOOGLE SAML 2.0

Feb 4, 2018 Feb 27, 2018 May 7, 2018

Report to Google

  • Similar to the session swapping attack presented before
  • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …)
slide-31
SLIDE 31

NEW ATTACK AGAINST GOOGLE SAML 2.0

Feb 4, 2018 Feb 27, 2018 May 7, 2018

Report to Google

  • Similar to the session swapping attack presented before
  • Login CSRF against Google Suite applications (Drive, Gmail, Keep, …)

And now?

slide-32
SLIDE 32

SUMMING UP

Lightweight policies on the client-side suffice to enforce provable security guarantees in web protocols

slide-33
SLIDE 33

SUMMING UP

  • Support for additional protocols e.g., e-payments
  • Automatic techniques to synthesize WPSE policies

from protocol specifications / browser traffic

  • Embed WPSE into real browsers

Lightweight policies on the client-side suffice to enforce provable security guarantees in web protocols

slide-34
SLIDE 34

THANK YOU!

Q&A

marco.squarcina@tuwien.ac.at https://sites.google.com/site/wpseproject/ @blueminimal