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

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, …

• Financial data

• Health data

• Personal data

• Financial data

• Health data

• Personal data

• Financial data

• Health data

• Personal data

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

Same Origin Policy

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

c.com b.coma.com

postMessage

✓JSON

Same Origin Policy

c.com b.coma.com

postMessage

✓JSON

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✓

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

Sandboxing

a.coma.com

Sandboxing

a.coma.com

Sandboxing

a.coma.com

Sandboxing

a.coma.com✓

a.coma.com

Sandboxing

a.coma.com✓

a.coma.com

Sandboxing

a.coma.com✓

a.coma.com

Sandboxing

a.coma.com✓

a.coma.com

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

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

Where this falls short…

Third-party APIs

Mashups

Third-party APIs

Mashups

Third-party APIs

Mashups

Third-party mashups

Third-party APIs

Mashups

Third-party mashups

Extensions

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

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 b.ru

public b.ru?

a.com b.ru

public b.ru

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

publicpublic b.ru

a.com ?

publicpublic b.ru

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

publicpublic b.ru

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

publicpublic b.ru

{level: “a.com”}

publicpublic b.ru

SWAPI.label = event.data.level;

public b.ru

public b.rua.com

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

public b.rua.com

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

?{pass: ...}

public b.rua.com

{pass: ...}

public b.rua.com

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

public b.rua.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

Transcript of New Protecting Users by Confining JavaScript with SWAPI · 2015. 1. 21. · execute JavaScript...

Avoiding Regressions in 3rd Party JavaScript

Physics-Intuition-Applications Corp. marty@p-i-a.com p-i-a.com p-i-a.edu

jQuery Datatables Part IV: A New HopeDOM Document Object Model jQuery Third-party JavaScript library ... Arguably the most popular JavaScript library in use today Excels at DOM manipulation,

WTP Unit 4 JavaScript and DHTML. Javascript: – Client side scripting, – What is Javascript, – How to develop Javascript, – Simple Javascript, – Variables,

JavaScript for Beginners - Daniel Wintersteinwinterstein.me.uk/javascript/JavaScript Course Notes.pdf · 4 A Tour of JavaScript ... JavaScript for Beginners 8 o An example of a server-side

Http:// rl= usels/carousel-04-bigvenetian- 01.jpg&imgrefurl= a.com/carousel-05-

Cookie Blocking and Privacy: First Parties Remain a Risk · blocking of third-party cookies. Setting third-party cookies in JavaScript allows for the cookie to be set at run time

Name · Name_____ Cyrano de Bergerac Background EDMOND ROSTAND a.com/biography/Ed mond-Rostand

JavaScript Programmingdept-info.labri.fr/~beurton/Enseignement/JavaScript/2018-2019/mai… · JavaScript Today All conﬁgurations and materials have a JavaScript “runtime” .

JavaScript for · PDF file“JavaScript,nottobeconfusedwithJava ... Whenthereisduplicationinthetestssetup,wecanextractitoutusingthe“beforeEach” function ... JavaScript for Testers

2004os gpcar 4c - sun-a.com

What is JavaScript? Embedding JavaScript with HTML JavaScript conventions Variables in JavaScript

Supporting Dynamic, Third-Party Code Customizations in JavaScript Using Aspects

DigiD vs. JavaScript: the risk of using third party JavaScript on ... · BSN (Burgerservicenummer) of the user, a unique 9-digit number assigned to each Dutch citizen. A user’s

JavaScript (JS) 3.pdfFull Stack JavaScript (หร อ Isomorphic JavaScript) • ในบทน จะ ล าวเฉพาะ JavaScript ท ประมวลผลบน Browser

JAVASCRIPT - kaverikar.files.wordpress.com · •Control Statements •Try ... A JavaScript engine is a program or interpreter which executes JavaScript code. A JavaScript engine

Measuring JavaScript Performance, JavaScript Games

Javascript session 01 - Introduction to Javascript

NYC & Company - NYCgo.com · NYC Company Digital Ad Specs 3 Banner Creatives Standard.gif, .jpg Rich Media HTML5, JavaScript, iFrame third-party tags Third-Party Rich Media Accepted

10-Choice Associative Remote Viewing (ARV) Marty Rosenblatt Physics-Intuition-Applications Corp marty@p-i-a.com p-i-a.com p-i-a.edu Edited from the presentation.