Skip this Video
Download Presentation
Web-based SSO schemes are being deployed by more and more commercial websites

Loading in 2 Seconds...

play fullscreen
1 / 30

Web-based SSO schemes are being deployed by more and more commercial websites - PowerPoint PPT Presentation

  • Uploaded on

Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services. Web-Based Single Sign On (SSO). Web-based SSO schemes are being deployed by more and more commercial websites

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Web-based SSO schemes are being deployed by more and more commercial websites ' - minda

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services


Web-Based Single Sign On (SSO)

  • Web-based SSO schemes are being deployed by more and more commercial websites
    • incorporating Facebook logon
    • incorporating Google ID logon
    • Many major companies are providing SSO schemes
  • A majority of web users (77%) prefer SSO to be offered by websites

Three parties in SSO

Browser representing a user (who already signed into the IdP as Alice)

  • Goal of SSO scheme: to convince the RP that the IdPbelieves that this particular browser is representing Alice


ID Provider (IdP), e.g., Facebook, Google, etc

Relying party (RP), e.g.,, etc.


Previous research and our motivation

A “formalized model”

  • Research about SSO in the protocol verification community
    • To build tools for SSO protocol verification
    • To show effectiveness of the tools in verifying security properties of formalized protocols or discovering protocol flaws.
  • Our focus
    • To report our broad “field study” of commercially deployed SSO systems in the wild.
    • To understandto what extent and why they are vulnerable.

A real-world system


Challenge in analysis of real-world SSO

  • Detailed server logic and server-server communication are invisible to us.
  • We can only see contents in browser traffic.
  • Positive side: making our findings more serious
    • No reason why attackers with real malicious intents cannot discover whatever we discover in this study.


Invisible to us




Vulnerabilities reported in this paper

  • In most cases, a vulnerability was confirmed on many RP websites.
  • Every vulnerability allowed an attacker to sign in as the victim. [video]

Browser relayed message (BRM)



  • Two equivalent views of browser traffic: round trips vs. BRMs

















A round trip = a browser request + its response

A BRM = a response + the next browser request

  • We reason about an SSO process as a sequence of BRMs
    • Because a BRM naturally describes how the SSO process transitions from one step to the next.

An example BRM

Set-cookies: sessionID=6739485

Arguments: x=123 & user=john

Cookies: fbs=a1b2c3 & foo=43da2c2a


When Bob is involved

Alice’s browser


  • There are four “SSO triangles”
    • Alice-IdP-Bob, Bob-IdP-RP, Alice-IdP-RP and Alice-Bob-RP
    • We do not consider Alice-Bob-RP, which would require Bob to act as an IdP




The three adversary scenarios corresponding to three SSO triangles

(A) Bob as a client

(B) Bob as another relying party





(C) Bob as a parasite page in Alice’s browser




The BRM analyzer

  • An online tool that we built to derive abstract traces from concrete traffic traces
    • URL:
  • How to use the analyzer
    • Collect three traffic traces. (An example trace)
    • Submit them to the BRM analyzer
    • The analyzer will automatically generate abstract traces for adversary scenarios (A) (B) (C) as explained earlier.
    • Example: scenario (A) of smartsheet’s integration of Google ID.
    • An abstract trace shows the readability and the writability of each element, and how the element propagates between BRMs.
  • How the analyzer works is described in the paper.

BRM1:src=RP dst=http://IdP/accounts/o8/ud


openid.ns[WORD] & openid.claimed_id[UU]  & openid.identity[UU]  &openid.return_to[URL]{RP/b/openid}  &

openid.realm[URL]{RP/b/openid}  &

openid.assoc_handle[BLOB]  & openid.openid.ns.ext1[WORD]  &[WORD]  & openid.ext1.type.firstname[WORD]  &

openid.ext1.type.lastname[WORD]  & openid.ext1.required[LIST] 


Arguments: st[MU][SEC] 

BRM3: src=!IdPdst=https://RP/b/openid


openid.ns[WORD]  & openid.mode[WORD] &

openid.response_nonce[SEC] & openid.return_to[URL]  & openid.assoc_handle[BLOB]  &

openid.identity[UU] & openid.claimed_id[UU]&

openid.sig[SIG] &

openid.signed[LIST]  & openid.opEndpoint[URL]{IdP/accounts/o8/ud}&

openid.ext1.type.firstname[WORD]  &

openid.ext1.value.firstname[UU] &[WORD]  &[UU] &

openid.ext1.type.lastname[WORD]  &


protected by openid.sig

Deployment of Google ID

  • Google ID is based on OpenID.
  • Abstract trace for scenario (A) is shown here.
  • Important elements
    • Openid.ext1.required in BRM1
    • Openid.sig in BRM3
    • Openid.signed in BRM3
    • Openid.ext1.required is propagate to Openid.signed

Deployment of Google ID (cont.)

  • A simplified illustration of the SSO scheme

Alice’s browser

(BRM2: unimportant, ignored in this talk)

BRM1: realm= the RP’s identityrequired=(email,firstname,lastname)

BRM3: signed=(email,firstname,lastname)email=“[email protected]”firstname=“Alice”lastname=“Smith”signature=“HRU436ETQ95TR939”

Google ID service

Relying party website


The attack

  • BRM3: signed=(firstname,lastname)signature=“HRU436ETQ95TR939”firstname=“Bob”lastname=“Johnson”email=“[email protected]
  • Reality: many RP websites use email address to identify users.
  • Suppose Bob knows Alice’s email address.

BRM1: realm= the RP’s domainrequired=(email,firstname,lastname)

Bob’s browser

  • BRM3: signed=(firstname,lastname)signature=“HRU436ETQ95TR939”firstname=“Bob”lastname=“Johnson”

BRM1: realm= the RP’s domainrequired=(email,firstname,lastname)

Relying party website

Google ID service

Google’s signature verified.

Welcome, user “[email protected]”!


Facebook Connect (Facebook’s SSO)

  • Abstract trace for scenario (B) is shown here.
  • app_id, representing the RP’s identity, is writable by Bob.
  • result, the secret for authentication is sent to Bob in BRM3.
  • Isn’t there an obvious vulnerability?
    • In BRM1, set app_id value to be the app_id of the target RP;
    • In BRM3, Bob will receive the result corresponding to the target RP
    • Now, Bob would be able to login to the target RP.
  • Does this obvious attack work?

Hi Facebook,

I am


Arguments: app_id[BLOB] & cb[SEC][BG] &



origin[BLOB]  & transport[WORD] 

} & … & … & … (other 13 elements )

Facebook generates result to allow login to


Arguments: origin[BLOB]& transport[WORD]&

result[SEC]& … & … (other 4 elements)


Arguments: origin[BLOB]& transport[WORD]&

result[SEC]& … & … (other 3 elements )

result is passed to


How Facebook SSO really works

  • The naïve attack did not succeed, because Facebook relies on the client-side same-origin-policy to pass the secret securely.
  • One of the client-side mechanisms is Adobe Flash
  • Below is the benign scenario
    • Both Flash A and Flash B are loaded from Facebook (
    • The secret is sent from Flash A to B (the same-domain communication)
    • Flash B makes sure that the secret is only sent to an HTML DOM in the intended domain (corresponding to the previous declared app_id)


The vulnerability

  • Adobe Flash can only do same domain communication? A wrong assumption
    • “Unpredictable domain communication”
    • As long as Flash A is willing to send, and Flash B is willing to receive, they can communicate in different domains.
    • So Flash B can come from, and thus obtain the secret from Flash A.

Unpredictable domain comm.



  • The most complicated case in our study
  • Over 365,000 websites use Janrain
  • It is a “wrapper” SSO service, similar to Azure ACS.
      • A website can just integrate Janrain to enable many SSO schemes altogether.
      • For a real IdP, the Janrain service acts as an RP; for the real RP website, Janrainservice acts as an IdP. Two SSO triangles here.



The real IdP

Janrain’s user interface

The real RP


A TOCTTOU (time-to-check-to-time-to-use) attack against Janrain

  • The flaw (in the browser-Janrain-RP triangle)
    • Domain whitelisting is a crucial basis for Janrain’s security
      • E.g., the whitelist of *, *
    • The main task of our attack is to bypass the whitelist-checking of an URL
    • A TOCTTOU (time-to-check-to-time-to-use) attack is feasible
      • Many details in the paper

Bob’s browser


Normal SSO: BRM1 – BRM7 (claiming the identity of (intentionally whitelisting’sdomain)



BRM1 to satisfy the whitelist checking BRM2- BRM7 to steal the secret



  • Acknowledgements from many companies
  • Security advisories published
  • News coverage

any many others


Summery of the studied cases

  • Commonalities in our investigations
    • Only two types of tokens: secret token or authentic token.
    • Only three adversary scenarios.
    • Investigation focus: how a secret token is propagated and how an authentic token is protected by a signature.
  • Variations in the discovered vulnerabilities
    • Variations are in the details of individual systems.
      • How a signature’s coverage is determined
      • How the browser protects the secrecy of a token
      • How BRM destinations are checked or whitelisted by servers
      • How accounts are linked
      • Many others …

protocols vs. real systems

  • Real-world integration is through APIs.
    • Through integrating web APIs, SDKs and sample code offered by ID providers
    • A protocol serves merely as a loose guideline – many grey areas.
  • The underlying runtime systems matter.
    • A logically correct protocol can be insecure if its designers or its integrators did not fully understand the underlying runtime systems.
  • Some protocol results are so confusing that even reasonable developers misunderstand and misuse them.
    • How to call APIs securely can be very challenging.
      • Similar situation in C/C++: strcpy, setuid, seteuid, setguid. Very tricky to call.

So, what kind of analysis tools do we need?

  • The main value is to help a security analyst understand the system
    • We spent more effort was on understanding than on pure logic thinking
  • A tool to support an adaptive and iterative investigation process
    • Our investigation experience:
      • start with partial knowledge of the system
      • design new tests to probe
      • reason about the test results to improve our understanding
      • Repeat until a viable path is found.
    • A tool assuming our complete knowledge is less useful
      • “Tell me everything upfront, and I will tell you everything I find” – not very useful for real-world system analysis.


  • Logic flaws exist in many commercially deployed SSO websites
    • Every one of the flaws allows attackers to get into victims’ accounts.
    • They can be discovered using browser traffic without insider knowledge.
    • They are issues in real-world deployments, not protocol designs.
  • IdP developers and RP developers should work together for secure integrations
    • ID providers: simplify the APIs provided to RP websites; anticipate all reasonable interpretations of your API specs.
    • RP developers: do not blindly count on ID providers for security, as each integration scenario is different; you must perform an end-to-end testing after your integration is done.


  • Martín Abadi
  • Manuel Caballero
  • Alex Halderman
  • Cormac Herley
  • Zhou Li
  • ShazQadeer
  • David Ross
  • NikSwamy
  • Helen Wang
  • Yi-Min Wang