new protecting users by confining javascript with swapi · 2015. 1. 21. · execute javascript...

Protecting Users by Confining JavaScript with SWAPI

Deian Stefan, Petr Marchenko, Brad Karp, David Mazières, Dave Herman, and John C. Mitchell

Modern websites are complex


Page code


Page code Ad code


Page code Ad code

Third-party APIs


Page code

Third-party libraries

Ad code

Third-party APIs


Page code


Ad code

Third-party APIs

Extensions

Modern websites handle sensitive information

• Financial data

➤ Online banking, tax filing, shopping, budgeting, …

• Health data

➤ Genomics, prescriptions, …

• Personal data

➤ Email, messaging, affiliations, …

Many parties are interested in the sensitive data

• Financial data

➤ Black-hat hackers, …

• Health data

➤ Insurance companies, …

• Personal data

➤ Ad companies, big governments, …

How do we protect sensitive data?

Non requirements!

… information exchange is still more important than secrecy.Tim Berners-Lee, 1989


Non requirements!


still somewhat true…


Non requirements!


still somewhat true…

but this was before the Web became the platform…

What is the state of the art in web security?

• Same Origin Policy

• Content Security Policy

• Sandboxing

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page

➤ E.g., can’t inspect responses from cross-origin

c.com b.coma.com

Same Origin Policy




c.com b.coma.com

postMessage

Same Origin Policy




c.com b.coma.com

postMessage

✓

Same Origin Policy




c.com b.coma.com

postMessage

✓JSON

Same Origin Policy

Limitations:

➤ Some DOM objects leak data

- E.g., image size can leak if user is logged in

➤ Data exfiltration is trivial

- E.g., any XHR request can contain data form page

➤ Cross-origin scripts run with privilege of page

➠ Injected scripts can corrupt and leak user data!

Content Security Policy

Goal: prevent and limit damage of XSS attacksIdea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *

c.com a.com




c.com b.coma.com




c.com b.coma.com✓




c.com b.coma.com✓

JSON

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts ensures iframe has unique origin

➤ E.g., directive sandbox ensures iframe has unique origin and cannotexecute JavaScript

a.coma.com

a.coma.com

Sandboxing




a.coma.com

a.coma.com

unq0

Sandboxing




a.coma.com✓

a.coma.com

unq0

Sandboxing




a.coma.com✓

a.coma.com

unq0

unq1

Content Security Policy & Sandboxing

Limitations:

➤ Data exfiltration is only partly contained

- Can leak to origins we can load resources from, and sibling frames or child Workers (via postMessage)

➤ Scripts still run with privilege of page

- Can we reason about security of jQuery-sized lib?




• Sandboxing




• Sandboxing

All-or-nothing discretionary access control: access data ➠ ability to leak it

Where this falls short…


Third-party APIs


Third-party APIs

Mashups


Third-party APIs


Mashups


Third-party APIs


Mashups

Third-party mashups


Third-party APIs


Mashups

Third-party mashups

Extensions

Guarantee: checker cannot leak password

➤ At worst: checker lies about strength of password

Password-strength checker

b.ru/chk.htmla.com

Confining the checker using existing mechanisms

• Host the checker code on a.com

• CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts

➤ Restrict all communication: default-src ‘none’ ‘unsafe-inline’

a.com/chk.htmla.com b.ru







p45s







Actually can leak to iframes, so need to use also Workers…

Why is this unsatisfactory?

• Functionality of library is limited

➤ E.g., library cannot fetch resources from network

• Requires server-side support to set policy

• Security policy is not first-class

➤ Library cannot use code it itself doesn’t trust

• Security policy is not symmetric

➤ Library cannot consider parent untrusted

A new approach: Secure Web API

Idea (a): Provide means for associating security label with data

➤ E.g., password is sensitive to a.com

Idea (b): Ensure code is confined to obey labels by associating labels with browsing contexts

➤ E.g., password can only be sent to entities that are as sensitive as a.com (via XHR, postMessage, storage, …)

Confining the checker with SWAPI

• Express sensitivity of data

➤ Checker can only receive password if its context label is as sensitive as the password

• Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send

a.com b.rua.com






a.com b.ru

public b.ru

a.com

a.com






a.com b.ru

public b.ru?

a.com

a.com






a.com b.ru

public b.ru

a.com

a.com






a.com b.ru/chk.html b.ru

publicpublic b.ru

a.com

a.com







publicpublic b.ru

a.com

a.com ?







publicpublic b.ru

a.com

a.com







publicpublic b.ru

postMessage({level: “a.com”}, “b.ru” , Label())

?

a.com

a.com







publicpublic b.ru

postMessage({level: “a.com”}, “b.ru” , Label())

a.com

a.com







publicpublic b.ru

{level: “a.com”}

a.com

a.com







publicpublic b.ru


a.com

a.com

SWAPI.label = event.data.level;







public b.ru


a.com

a.com

a.com

SWAPI.label = event.data.level;







public b.rua.com

a.com

a.com







public b.rua.com

a.com

a.com

postMessage({pass: ...}, “b.ru” , Label(“a.com”))

?







public b.rua.com

a.com

a.com

postMessage({pass: ...}, “b.ru” , Label(“a.com”))

?{pass: ...}







public b.rua.com

a.com

a.com

{pass: ...}







public b.rua.com

a.com

a.com







public b.rua.com

a.com

a.comCan leak password to a.com Fix: create fresh labels to ensure checker is fully confined







public b.rua.com

a.com

a.com

What can we do with this?

Third-party APIs


Mashups

Third-party mashups

Extensions

Rest of SWAPI• Privileges

➤ Origin can use privilege to exfiltrate its own data

• Labeled DOM (light-weight) workers ➤ Extensions: Untrusted code executed in unprivileged worker

Like Chrome-extension model, but uses confinement

➤ Third-party libs: Worker contains page TCB and page privilege Confined page contains untrusted jQuery

• Labeled XHR constructor ➤ Allow reading cross-origin responses, but restrict context

from writing it arbitrarily


Third-party APIs


Mashups

Third-party mashups

Extensions


Third-party APIs


Mashups

Third-party mashups

Extensions

And more…

Implementation

• A minimally intrusive implementation

➤ Set CSP & iframe sandbox dynamically, according to context label

➤ Restrict postMessage and object access according to context label (even for same origin contexts!)

➤ Opt-in: enabled when using any SWAPI feature

• Implemented in Firefox and Chromium

➤ Negligible performance impact

Summary• Client-side security mechanism

• Security policy is first-class

➤ Any code can impose restrictions oh what the receiver can do with the data before sending it

• Security policy is symmetric

➤ Iframes and workers can impose restrictions on parent code when sending messages

★ Consequence: don’t need to trade off functionality and security

Thanks. Stay tuned…

Many thanks to Edward Z. Yang, Stefan Heule, Bobby Holley, Blake Kaplan, Garrett Robinson, and Brian Smith.

that can only talk to your friendsthat can only talk to your friends

————-———-—————-———-—————-———-—————-———-—

new protecting users by confining javascript with swapi · 2015. 1. 21. · execute javascript...

Documents