Browser code isolation John Mitchell CS 155 Spring 2016.

Slides:



Advertisements
Similar presentations
Nick Feamster CS 6262 Spring 2009
Advertisements

Protecting Browser State from Web Privacy Attacks Collin Jackson, Andrew Bortz, Dan Boneh, John Mitchell Stanford University.
Enabling Secure Internet Access with ISA Server
ForceHTTPS: Protecting High-Security Web Sites from Network Attacks Collin Jackson and Adam Barth.
JavaScript FaaDoOEngineers.com FaaDoOEngineers.com.
Copyright Justin C. Klein Keane HTML 5 Security Philadelphia OWASP August, 2013.
4.01 How Web Pages Work.
Building web applications on top of encrypted data using Mylar Presented by Tenglu Liang Tai Liu.
I'll see your cross site scripting and raise you a Content Security Policy Lou Leone :: Rochester OWASP.
17 th ACM CCS (October, 2010).  Introduction  Threat Model  Cross-Origin CSS Attacks  Example Attacks  Defenses  Experiment  Related Work 2 A Presentation.
Georgios Kontaxis, Michalis Polychronakis Angelos D. Keromytis, Evangelos P. Markatos Siddhant Ujjain (2009cs10219) Deepak Sharma (2009cs10185)
1 Configuring Internet- related services (April 22, 2015) © Abdou Illia, Spring 2015.
An Evaluation of the Google Chrome Extension Security Architecture
By Philipp Vogt, Florian Nentwich, Nenad Jovanovic, Engin Kirda, Christopher Kruegel, and Giovanni Vigna Network and Distributed System Security(NDSS ‘07)
EECS 354 Network Security Cross Site Scripting (XSS)
Site and user security concerns for real time content serving Chris Mejia, IAB Sean Snider, Yahoo! Prabhakar Goyal, Microsoft.
The Most Dangerous Code in the Browser Stefan Heule, Devon Rifkin, Alejandro Russo, Deian Stefan Stanford University, Chalmers University of Technology.
Warning Ahead: Security Storms are Brewing in Your JavaScript Maty Siman.
Beware of Finer-Grained Origins
Topics in this presentation: The Web and how it works Difference between Web pages and web sites Web browsers and Web servers HTML purpose and structure.
Happy Hacking HTML5! Group members: Dongyang Zhang Wei Liu Weizhou He Yutong Wei Yuxin Zhu.
Internet Basics.
Frame isolation and the same origin policy Collin Jackson CS 142 Winter 2009.
Phu H. Phung Chalmers University of Technology JSTools’ 12 June 13, 2012, Beijing, China Joint work with Lieven Desmet (KU Leuven)
Security and JavaScript. Learning Objectives By the end of this lecture, you should be able to: – Describe what is meant by JavaScript’s same-origin security.
1 Subspace: Secure Cross Domain Communication for Web Mashups Collin Jackson and Helen J. Wang Mamadou H. Diallo.
Subspace: Secure Cross-Domain Communication for Web Mashups Collin Jackson Stanford University Helen J. Wang Microsoft Research ACM WWW, May, 2007 Presenter:
Subspace: Secure Cross-Domain Communication for Web Mashups In Proceedings of the 16th International World Wide Web Conference. (WWW), 2007 Collin Jackson,
Introduction to InfoSec – Recitation 10 Nir Krakowski (nirkrako at post.tau.ac.il) Itamar Gilad (itamargi at post.tau.ac.il)
1 Web Developer & Design Foundations with XHTML Chapter 6 Key Concepts.
Towards a Formal Foundation of Web Security devdatta akhawe / adam barth / peifung eric lam john mitchell / dawn song.
Copyright © cs-tutorial.com. Introduction to Web Development In 1990 and 1991,Tim Berners-Lee created the World Wide Web at the European Laboratory for.
Origins, Cookies and Security – Oh My! John Kemp, Nokia Mobile Solutions.
Prevent Cross-Site Scripting (XSS) attack
Comp2513 Forms and CGI Server Applications Daniel L. Silver, Ph.D.
WEB SECURITY WEEK 3 Computer Security Group University of Texas at Dallas.
JavaScript, Fourth Edition
November 13, 2008 Ohio Information Security Forum Attack Surface of Web Applications James Walden Northern Kentucky University
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
CNIT 133 Interactive Web Pags – JavaScript and AJAX JavaScript Environment.
Krishna Mohan Koyya Glarimy Technology Services
Top Five Web Application Vulnerabilities Vebjørn Moen Selmersenteret/NoWires.org Norsk Kryptoseminar Trondheim
CSCE 201 Web Browser Security Fall CSCE Farkas2 Web Evolution Web Evolution Past: Human usage – HTTP – Static Web pages (HTML) Current: Human.
SMash : Secure Component Model for Cross- Domain Mashups on Unmodified Browsers WWW 2008 Frederik De Keukelaere et al. Presenter : SJ Park.
Lecture 16 Page 1 CS 236 Online Web Security CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
Vitaliy Tarnavskyy Jun 26, 2013 Using Web workers in Javascript.
University of Central Florida The Postman Always Rings Twice: Attacking & Defending postMessage in HTML5 Websites Ankur Verma University of Central Florida,
Vaibhav Rastogi and Yi Yang.  SOP is outdated  Netscape introduced this policy when most content on the Internet was static  Differences amongst different.
Protecting Browsers from Extension Vulnerabilities Paper by: Adam Barth, Adrienne Porter Felt, Prateek Saxena at University of California, Berkeley and.
Web Security Lesson Summary ●Overview of Web and security vulnerabilities ●Cross Site Scripting ●Cross Site Request Forgery ●SQL Injection.
1 Isolating Web Programs in Modern Browser Architectures CS6204: Cloud Environment Spring 2011.
 Web pages originally static  Page is delivered exactly as stored on server  Same information displayed for all users, from all contexts  Dynamic.
JavaScript and Ajax (JavaScript Environment) Week 6 Web site:
By Collin Donaldson. Hacking is only legal under the following circumstances: 1.You hack (penetration test) a device/network you own. 2.You gain explicit,
The Postman Always Rings Twice: Attacking and Defending postMessage in HTML5 Websites Paper by Sooel Son and Vitaly Shmatikov, The University of Texas.
Redmond Protocols Plugfest 2016 Tarun Chopra Accessing APIs through Add-Ins Sr. Escalation Engineer.
SlideSet #20: Input Validation and Cross-site Scripting Attacks (XSS) SY306 Web and Databases for Cyber Operations.
Web Security (cont.) 1. Referral issues r HTTP referer (originally referrer) – HTTP header that designates calling resource  Page on which a link is.
What mobile ads know about mobile users
Data Virtualization Tutorial… CORS and CIS
Subbu Allamaraju BEA Systems Inc
Web Caching? Web Caching:.
CSC 495/583 Topics of Software Security Web Browser Security (2)
Password Managers: Attacks and Defenses
Browser code isolation
HTTP GET vs POST SE-2840 Dr. Mark L. Hornick.
Protecting Browsers from Extension Vulnerabilities
Cross-Site Scripting Attack (XSS)
Cross Site Request Forgery (CSRF)
Presentation transcript:

Browser code isolation John Mitchell CS 155 Spring 2016

Modern web sites are complex

Modern web “site” Code from many sources Combined in many ways

Sites handle sensitive information Financial data Online banking, tax filing, shopping, budgeting, … Health data Genomics, prescriptions, … Personal data , messaging, affiliations, … Goal: prevent malicious web content from stealing information.

Basic questions How do we isolate code from different sources Protecting sensitive information in browser Ensuring some form of integrity Allowing modern functionality, flexible interaction

More specifically How do we protect page from ads/services? How to share data with cross-origin page? How to protect one user from another’s content? How do we protect the page from a library? How do we protect page from CDN? How do we protect extension from page?

Recall Same-Origin Policy (SOP) Idea: Isolate content from different origins Restricts interaction between compartments Restricts network request and response

Recall Same-Origin Policy (SOP)

XmlHttpRequest follows same-origin policy

Recall Same-Origin Policy (SOP)

Same-origin policy summary Isolate content from different origins E.g., can’t access document of cross-origin page E.g., can’t inspect responses from cross-origin

Example:Library Library included using tag No isolation Runs in same frame, same origin as rest of page May contain arbitrary code Library developer errors or malicious trojan horse Can redefine core features of JavaScript May violate developer invariants, assumptions jQuery used by 78% of the Quantcast top 10,000 sites, over 59% of the top million

Second example: advertisement 14 “ “ Read password using the DOM API var c = document.getElementsByName(“password”)[0] Send it to evil location (not subject to SOP) Directly embedded third-party JavaScript poses a threat to critical hosting page resources

Second example: Ad vs Ad “ “ $1 Buy Now Attack the other ad: Change the price ! var a = document.getElementById(“sonyAd”) a.innerHTML = “$1 Buy Now”; Directly embedded third-party JavaScript poses a threat to other third-party components

Same-Origin Policy Limitations: Some DOM objects leak data  Image size can leak whether user logged in Data exfiltration is trivial  Can send data in image request  Any XHR request can contain data from page Cross-origin scripts run with privilege of page  Injected scripts can corrupt and leak user data!

In some ways, too strict Can’t read cross-origin responses What if we want to fetch data from provider.com? JSONP  To fetch data, insert new script tag:  To share data, reply back with script wrapping data: f({...data...}) Why is this dangerous? Provider data can easily be leaked (CSRF) Page is not protected from provider (XSS)

Goal: Password-strength checker Strength checker can run in a separate frame Communicate by postMessage But we give password to untrusted code! Is there any way to make sure untrusted code does not export our password?

Useful concept: browsing context A browsing context may be A frame with its DOM A web worker (thread), which does not have a DOM Every browsing context Has an origin, determined by  protocol, host, port  Is isolated from others by same-origin policy May communicate to others using postMessage Can make network requests using XHR or tags (, …)

Modern Structuring Mechanisms HTML5 iframe Sandbox Load with unique origin, limited privileges Content Security Policy (CSP) Whitelist instructing browser to only execute or render resources from specific sources HTML5 Web Workers Separate thread; isolated but same origin Not originally intended for security, but helps SubResource integrity (SRI) Cross-Origin Resource Sharing (CORS) Relax same-origin restrictions

HTML5 Sandbox Idea: restrict frame actions Directive sandbox ensures iframe has unique origin and cannot execute JavaScript Directive sandbox allow-scripts ensures iframe has unique origin

HTML5 Sandbox Idea: restrict frame actions Directive sandbox ensures iframe has unique origin and cannot execute JavaScript Directive sandbox allow-scripts ensures iframe has unique origin

HTML5 Sandbox Idea: restrict frame actions Directive sandbox ensures iframe has unique origin and cannot execute JavaScript Directive sandbox allow-scripts ensures iframe has unique origin

Sandbox example Twitter button in iframe Sandbox: remove all permissions and then allow JavaScript, popups, form submission, and twitter.com cookies <iframe sandbox="allow-same-origin allow-scripts allow-popups allow-forms" src=" style="border: 0; width:130px; height:20px;"> <iframe src= " style="border: 0; width:130px; height:20px;">

Sandbox permissions allow-forms allows form submission allow-popups allows popups allow-pointer-lock allows pointer lock (mouse moves) allow-same-origin allows the document to maintain its origin; pages loaded from will retain access to that origin’s data. allow-scripts allows JavaScript execution, and also allows features to trigger automatically (as they’d be trivial to implement via JavaScript) allow-top-navigation allows the document to break out of the frame by navigating the top-level window

Modern Structuring Mechanisms HTML5 iframe Sandbox Load with unique origin, limited privileges Content Security Policy (CSP) Whitelist instructing browser to only execute or render resources from specific sources HTML5 Web Workers Separate thread; isolated but same origin Not originally intended for security, but helps SubResource integrity (SRI) Cross-Origin Resource Sharing (CORS) Relax same-origin restrictions

Content Security Policy (CSP) Goal: prevent and limit damage of XSS XSS attacks bypass the same origin policy by tricking a site into delivering malicious code along with intended content Approach: restrict resource loading to a white-list Prohibits inline scripts embedded in script tags, inline event handlers and javascript: URLs Disable JavaScript eval(), new Function(), … Content-Security-Policy HTTP header allows site to create whitelist, instructs the browser to only execute or render resources from those sources

Content Security Policy (CSP) Goal: prevent and limit damage of XSS attacks Approach: restrict resource loading to a white-list E.g., default-src ‘self’ img-src *

Content Security Policy (CSP) Goal: prevent and limit damage of XSS attacks Approach: restrict resource loading to a white-list E.g., default-src ‘self’ img-src *

Content Security Policy (CSP) Goal: prevent and limit damage of XSS attacks Approach: restrict resource loading to a white-list E.g., default-src ‘self’ img-src *

Content Security Policy (CSP) Goal: prevent and limit damage of XSS attacks Approach: restrict resource loading to a white-list E.g., default-src ‘self’ img-src *

Content Security Policy (CSP) Goal: prevent and limit damage of XSS attacks Approach: restrict resource loading to a white-list E.g., default-src ‘self’ img-src *

Content Security Policy (CSP) Goal: prevent and limit damage of XSS attacks Approach: restrict resource loading to a white-list E.g., default-src ‘self’ img-src *

Content Security Policy (CSP) Goal: prevent and limit damage of XSS attacks Approach: restrict resource loading to a white-list E.g., default-src ‘self’ img-src *

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?

CSP resource directives script-src limits the origins for loading scripts connect-src limits the origins to which you can connect (via XHR, WebSockets, and EventSource). font-src specifies the origins that can serve web fonts. frame-src lists origins can be embedded as frames img-src lists origins from which images can be loaded. media-src restricts the origins for video and audio. object-src allows control over Flash, other plugins style-src is script-src counterpart for stylesheets default-src define the defaults for any directive not otherwise specified

CSP source lists Specify by scheme, e.g., https: Host name, matching any origin on that host Fully qualified URI, e.g., Wildcards accepted, only as scheme, port, or in the leftmost position of the hostname: 'none‘ matches nothing 'self' matches the current origin, but not subdomains 'unsafe-inline' allows inline JavaScript and CSS 'unsafe-eval' allows text-to-JavaScript mechanisms like eval

Modern Structuring Mechanisms HTML5 iframe Sandbox Load with unique origin, limited privileges Content Security Policy (CSP) Whitelist instructing browser to only execute or render resources from specific sources HTML5 Web Workers Separate thread; isolated but same origin Not originally intended for security, but helps SubResource integrity (SRI) Cross-Origin Resource Sharing (CORS) Relax same-origin restrictions

Web Worker Run in an isolated thread, loaded from separate file Same origin as frame that creates it, but no DOM Communicate using postMessage var worker = new Worker('task.js'); worker.postMessage(); // Start the worker. var worker = new Worker('doWork.js'); worker.addEventListener('message', function(e) { console.log('Worker said: ', e.data); }, false); worker.postMessage('Hello World'); // Send data to worker self.addEventListener('message', function(e) { self.postMessage(e.data); // Return message it is sent }, false); main thread doWork

Modern Structuring Mechanisms HTML5 iframe Sandbox Load with unique origin, limited privileges Content Security Policy (CSP) Whitelist instructing browser to only execute or render resources from specific sources HTML5 Web Workers Separate thread; isolated but same origin Not originally intended for security, but helps SubResource integrity (SRI) Cross-Origin Resource Sharing (CORS) Relax same-origin restrictions

Motivation for SRI Many pages pull scripts and styles from a wide variety of services and content delivery networks. How can we protect against downloading content from a hostile server (via DNS poisoning, or other such means), or modified file on the Content Delivery Network (CDN) Won’t using HTTPS address this problem?

Subresource integrity Idea: page author specifies hash of (sub)resource they are loading; browser checks integrity E.g., integrity for scripts  E.g., integrity for link elements 

What happens when check fails? Case 1 (default): Browser reports violation and does not render/ execute resource Case 2: CSP directive with integrity-policy directive set to report Browser reports violation, but may render/execute resource

Multiple hash algorithms Authors may specify multiple hashes E.g., <script src="hello_world.js" integrity=“sha sha "> Browser uses strongest algorithm Why support multiple algorithms?

Modern Structuring Mechanisms HTML5 iframe Sandbox Load with unique origin, limited privileges Content Security Policy (CSP) Whitelist instructing browser to only execute or render resources from specific sources HTML5 Web Workers Separate thread; isolated but same origin Not originally intended for security, but helps SubResource integrity (SRI) Cross-Origin Resource Sharing (CORS) Relax same-origin restrictions

Cross-Origin Resource Sharing (CORS) Amazon has multiple domains E.g., amazon.com and aws.com Problem: amazon.com can’t read cross-origin aws.com With CORS amazon.com can whitelist aws.com

How CORS works Browser sends Origin header with XHR request E.g., Origin: Server can inspect Origin header and respond with Access-Control-Allow-Origin header E.g., Access-Control-Allow-Origin: E.g., Access-Control-Allow-Origin: *

Modern Structuring Mechanisms HTML5 iframe Sandbox Load with unique origin, limited privileges Content Security Policy (CSP) Whitelist instructing browser to only execute or render resources from specific sources HTML5 Web Workers Separate thread; isolated but same origin Not originally intended for security, but helps SubResource integrity (SRI) Cross-Origin Resource Sharing (CORS) Relax same-origin restrictions

Recall: Password-strength checker Strength checker can run in a separate frame Communicate by postMessage But we give password to untrusted code! Is there any way to make sure untrusted code does not export our password?

Confining the checker with COWL Express sensitivity of data Checker can only receive password if its context label is as sensitive as the password Use postMessage API to send password Source specifies sensitivity of data at time of send

Modern web site Code from many sources Combined in many ways

Challenges

Basic questions How do we isolate code from different sources Protecting sensitive information in browser Ensuring some form of integrity Allowing modern functionality, flexible interaction

Acting parties on a site Page developer Library developers Service providers Data provides Ad providers Other users CDNs Extension developers

Specifically How do we protect page from ads/services? How to share data with cross-origin page? How to protect one user from another’s content? How do we protect the page from a library? How do we protect page from CDN? How do we protect extension from page?