Omash enabling secure web mashups via object abstractions
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

OMash : Enabling Secure Web Mashups via Object Abstractions PowerPoint PPT Presentation


  • 42 Views
  • Uploaded on
  • Presentation posted in: General

OMash : Enabling Secure Web Mashups via Object Abstractions. Steven Crites, Francis Hsu, Hao Chen (UC Davis) ACM Conference on Computer and Communications Security (CCS), 2008 Presenter: Fu-Chi Ao. Outline. Introduction The Same Origin Policy Design Usage Examples Implementation

Download Presentation

OMash : Enabling Secure Web Mashups via Object Abstractions

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


Omash enabling secure web mashups via object abstractions

OMash: Enabling Secure Web Mashups via Object Abstractions

Steven Crites, Francis Hsu, Hao Chen (UC Davis)

ACM Conference on Computer and Communications Security (CCS), 2008

Presenter: Fu-Chi Ao


Outline

Outline

  • Introduction

  • The Same Origin Policy

  • Design

  • Usage Examples

  • Implementation

  • Related Work

  • Conclusion and Comments


Introduction 1 2

Introduction (1/2)

  • Even before the rise of AJAX and mashups, at any given time a web browser likely contained pages from different domains

  • Same Origin Policy (SOP)

    • Used by web browsers

    • Not support secure cross-domain communication desired by web mashupdeveloper

    • Supports only 2 states

      • Full trust: third-party content runs with full privilege

      • No trust: no communication is allowed


Introduction 2 2

Introduction (2/2)

  • OMash

    • New abstraction and access control model for writing secure yet flexible mashupapplications

      • Provide mashup developers with the ability to allow safe, controlled communication and interaction between web sites, and allow for the various trust models they desire

    • Does not rely on the SOP

    • Supports backwards compatibility

    • Tested on Mozilla Firefox 2.0


The same origin policy 1 2

The Same Origin Policy (1/2)

Server

a.com

Browser

a.com

a.com

b.com


The same origin policy 2 2

The Same Origin Policy (2/2)

  • Applied to protect three browser resources:

    • Documents: Sites from one origin cannot access documents from another origin via the Document Object Model

    • Cookies: Sites can only set their own cookies and cookies are only sent to their originating site in HTTP requests.

    • Access to remote services: Only permits XMLHttpRequestto issue requests to the origin of the containing document.

      • allows a script to issue an asynchronous HTTP request to a remote server.


Problems of sop dom access

Problems of SOP: DOM Access

  • Extended to Domain Name System (DNS) domains and relies on it

  • DNS Insecurity

    • Client vulnerabilities

      • DNS rebinding (Jackson et al, CCS 07)

      • Dynamic Pharming(Karlof et al, CCS 07)

    • Server vulnerabilities

      • DNS cache poisoning (Kaminsky, BlackHat 08)


Problems of sop authentication credentials

Problems of SOP: Authentication Credentials

  • Confused Deputy

    • When a request is made, cookies matching the destination domain are added to the request

      • as well as any other form of HTTP Authentication (e.g. Basic, Digest, NTLM) information for the domain

    • Regardless of what page caused the browser to initiate this request

    • Causes Cross-Site Request Forgery (CSRF) attacks


Cross site request forgery

Cross-Site Request Forgery

Server

a.com

Browser

b.com

a.com


Trust levels

Trust Levels

  • Wang et al. in MashupOS enumerate all the possible trust levels available between integrators and providers

    • (1) isolated content that should be isolated from other domains

    • (2) access-controlled content that should be isolated but allows for mediated access via, e.g. message passing

    • (3) (and (5)) open content that any domain can access and integrate into itself 1

    • (4) unauthorized content that has no privileges of any domain.

Table 1: The Trust Model on the Web for a provider P and an integrator I as defined in MashupOS


Omash design

OMashDesign

  • Analog to OOP languages

  • Treat each web page as an object that declares public and private data and methods

    • A web page can only access its own content and the public content of another page

    • All data in the page are considered private by default

    • To enable inter-page communication, a page may declare a public interface, getPublicInterface, which all pages can access


Object abstractions

Object Abstractions

  • Java (analogy)

  • Web page object

public class FooObject {

public void publicMethod() {

}

private intprivateData;

}

<html>

<script>

function getPublicInterface() {

function Interface() {

this.publicMethod =

function () {…}

}

return new Interface();

}

varprivateData;

</script>

</html>


Page objects

Page Objects

  • A web page consists of

    • DOM tree

    • Scripts

    • Credentials (HTTP authentication token, e.g. cookies)

  • A page object can be contained in a

    • Window

    • Frame

    • Iframe


Public and private members

Public and Private Members

  • Public interface

    • Each object declares getPublicInterface()

    • Returns a closure of all public methods and data

      • An expression (typically a function) that can have free variables together with an environment that binds those variables

      • Using closures, pages can safely get and set information on other pages in a controlled manner

  • Private data

    • DOM objects (document, etc.)

    • JavaScript objects and functions

    • Credentials(HTTP authentication token, e.g. cookies)


Provider and integrator communicate via the p ublic interface

Provider and Integrator Communicate via the Public Interface

  • map.html

  • integrator.html

<html>

function getPublicInterface()

{

function Interface()

{

this.setCenter =

function (lat,long){

}

}

return new Interface();

}

</html>

<iframeid=“inner” src="map.html">

...

var win = getElementByID(“inner”).contentWindow;

varmap = win.getPublicInterface();

...

map.setCenter(lat, long);

}

integrator.html

map.html


Mediate dom access

Mediate DOM Access

  • By using the getPublicInterface function, a page’s creator can specify what they want other pages to be able to access

  • Using this approach, the mashup developer can model a variety of trust relationships

    • Isolated content

    • Access-controlled content

    • Open content

    • Unauthorized content


Isolated

Isolated

  • No access between provider and integrator

function getPublicInterface() {

function Interface()

{

}

return new Interface();

}


Access controlled

Access-controlled

  • Limited access depending on caller

    • Provide methods for the returned interface that only allow access to a site’s content based on the caller’s credentials

Provider

Integrator

function getPublicInterface() {

function Interface() {

this.auth = function(user,pass)

{ return token; }

this.do = function (token,...)

{ check(token); }

}

return new Interface();

}

varapi = win.getPublicInterface();

token =

api.auth(user, pass);

api.do (token,...)


Omash enabling secure web mashups via object abstractions

Open

  • Full access between provider and integrator

function getPublicInterface()

{

function Interface()

{

this.getDocument = function ()

{

return document;

}

}

return new Interface();

}


Unauthorized

Unauthorized

outer.html, which uses the service provided by the code in map.html

map.html, which provides a map service

outer.html

map.html

 isolate the untrusted script library (provided content) within another page


Mediate authentication credentials

Mediate Authentication Credentials

  • HTTP authentication(e.g. Basic, Digest, NTLM)

    • When authentication information (HTTP or a cookie) comes in, the browser associates this information with the page that receives it, page P

  • Cookies

    • The only cookies we want to treat this way are those that are used for authentication.

    • Modification : Add extra attribute Authentication

      • Session cookiesare associated with a page when they are set

      • Persistent cookies are associated with the first user-opened page

  • XMLHttpRequest

    • Malicious sites can no longer leverage CSRF

    • Can loggin with 2 different accounts at the same time

    • Can accomplish safe cross-domain data exchange by lifting the restriction of XHR


Browser sessions under omash

Browser Sessions under OMash

  • Each cookie

    • Belongs to a window

    • Is shared by subsequent pages from the same domain in that window

  • Each window has an independent session

    • Desirable side effect: Can log in to multiple accounts in different windows in the same browser


Cross window sessions

Cross-window Sessions

  • How to track a session across windows?

  • Cookie Inheritance

    • When page P1 loads P2, P2 inherits P1’s cookies

    • P1 and P2 now belong to the same session


Preventing csrf

Preventing CSRF

Server

a.com

Browser

a.com

b.com


Preventing csrf1

Preventing CSRF

Server

a.com

Browser

a.com

b.com


Preventing csrf2

Preventing CSRF

Server

a.com

Browser

No cookie!

a.com

b.com


Backward compatibility with the same origin policy

Backward Compatibility with the Same Origin Policy

  • If application prefers using SOP to allow inter-page communication:

  • To implement this under OMash

    • Server embeds a shared secret in all pages

    • Pages authenticate each other using this secret


Supporting sop without dns

Supporting SOP without DNS

Provider

Integrator

secret = “1234”;

function getPublicInterface() {

function Interface() {

this.foo=function (secret, … )

{ check(secret); … }

}

return new Interface();

}

<script>

secret = “1234”

api = win.getPublicInterface()

api.foo(secret, …)

</script>


Omash enabling secure web mashups via object abstractions

(a) inner.html. The function foo authenticates the caller by checking the parameter provided Secret against the embedded global variable secret.

(b) outer.html. It authenticates by providing the argument secret in the call to the provider.


Implementation

Implementation

  • Implemented and tested on Firefox 2

  • Proof of concept as Firefox add-on

    • Use Mozilla’s Configurable Security Policies(CAPS) system to allow the cross-domain access to the getPublicInterface

      • allow users to set up security policies for the browser, and also have different security policies for different Internet sites

    • Use Firefox 2’s Session store API to make each cookie private to a window

  • No changes required on the server


  • Related work

    Related Work

    • MashupOS (Wang et al, SOSP 07)

      • Rely on the Same Origin Policy for controlling DOM accesses or cross-domain data exchange

      • Requires browser writers and application developers to support and use several different abstractions

    • SMash (Keukelaere WWW 07)

      • Isolates components using the iframetag, and URL fragment identifiers allow the frames to establish communication links.

    • Google’s Caja

      • Also allows web applications of different trust domains to directly communicate with JavaScript function calls and reference passing


    Conclusion and comments

    Conclusion and Comments

    • OMashis a new browser security model

      • Allows flexible trust relation

      • Simple

      • Familiar, easy to understand

      • Backward compatible

    • Don’t rely on Same Origin Policy

      • Prevent CSRF attacks

      • Allows programmers to define “Same Origin” flexibly based on shared secrets


  • Login