SOMA: Mutual Approval for Included Content in Web Pages

Terri Oda, Glenn Wurster, P.C. van Oorschot, Anil Somayaji

Carleton Computer Security LabCarleton University, Canada

In Proc. 15th ACM CCS, 2008

Presenter: Fu-Chi, Ao

2009/05/19 2

Outline

• Introduction

• Background and Motivation

• SOMA Design

• Design Evaluation

• Prototype

• Related Work

• Conclusion and Comments

2009/05/19 3

Introduction

• Unrestricted information flows are a key security weakness of current web design

• Proposes a policy for improving the same origin policy by imposing further constraints upon external inclusions and thus external communications in web pages, called Same Origin Mutual Approval (SOMA)

• Requires the browser to check that both site operator of the page and the third party content provider approve of the inclusion before any communication is allowed (including adding anything to the page)

• Implemented as an add-on for Mozilla Firefox 2 and 3

2009/05/19 4

Background and Motivation

• While the sandbox and same origin policy protect the host and prevent many types of network communication, opportunities allow for considerable scope for security vulnerabilities.

• Requires that information be sent or retrieved from arbitrary, often malicious, web servers – Cross-site scripting, cross-site request forgery, and

other attacks

2009/05/19 5

SOMA Design

• Security policy should be decided by site operators, who have a vested interest in doing it correctly and the knowledge necessary to create secure policies, rather than end users.– Browsers have to make minimal code changes and web sites

must create small, simple policy files• Same Origin policy restricts read and modify access• Fetching of content is unrestricted

2009/05/19 6

Threat Model

• Assume: attacker controls arbitrary web servers and some of the content on legitimate servers (but not their policy files or their server software)

• Do not address: – Attacker compromises a web server to change policy f

iles– Compromises a web browser to circumvent policy che

cks– Performs intruder-in-the-middle attacks to intercept an

d modify communications– User visiting malicious web site directly, say as phishi

ng attack

2009/05/19 7

Manifest Files

• A text file containing a list of domains from which the origin domain wishes to allow included content.

• Always stored in the root directory and will have the name soma-manifest– The manifest file for maps.google.com would be found at http://

maps.google.com/soma-manifest• Each location definition includes protocol, domain and op

tionally port• : A is the origin (the outer cup) and B is a content

provider web site for that origin (the inner circle)• :The browser will not allow anything in the pages

from A to contact the domain C, thus code, images, iframes, or any other content will not be loaded from C

• Trust is not transitive

2009/05/19 8

Approval Files• Provide the other side of the mutual approval by allowing

domains to indicate sites which are allowed to include content from them.

• it is a script that provides a YES/NO response given a domain as input.– Prevent easy disclosure of the list of approved domains

• Could be used in a XSRF attack or to determine business relationships

– Provide a modest performance increase on the client side

Simple soma-approval script written in PHP

Uses an array to store policy information

Defaults to NO if no policy has been defined

2009/05/19 9

Approval Files

• : B.org provides a script in the web server root directory with the filename soma-approval which returns NO when invoked through http://B.org/soma-approval?d=C.com– The browser will refuse to allow the page from C to co

ntact B in anyway• No scripts, images, iframes or other content from B.org will b

e loaded for the web page at C.com

• Trust is not transitive• Content is only loaded if both parties agree

– i.e.

2009/05/19 10

Process of Approval

Inclusions allowed with SOMAThe mutual approval procedure

2009/05/19 11

Compatibility with Existing Sites

• Defaults to a permissive mode if the manifest or approval files do not exist.– Reflect current web page behavior where all inclusion

s are allowed• If the soma-manifest file does not exist on the ori

gin, all inclusions are considered to be permitted by the origin site

• If the content provider has no soma-approval file, then any site is allowed to include content from this provider

• These checks are independent

2009/05/19 12

Design Evaluation

• Incremental Deployment– The full benefits are available when origins and

content providers both provide SOMA-related files– But it is possible for either side to start providing files

without needing extensive coordination to ensure that both are provided at the same time

• Security Benefits– Recursive Script Inclusion– Unrestricted Outbound Communication– Cross-site Request Forgery (XSRF/CSRF)– Cross-Site Scripting (XSS)– Bandwidth Stealing

2009/05/19 13

Recursive Script Inclusion

• A page creator could choose to include content only from sources they deem trustworthy– Does not mean that all content included will be

directly from those sources

• Any script loaded from a “trustworthy” domain can subsequently load content from any domain.

• Trust is not transitive– Intentionally malicious script loads additional,

dangerous code – “Trustworthy” domain inadvertently loading malicious

content

2009/05/19 14

Security Benefits - Recursive Script Inclusion

• Script inclusion is only allowed from mutually approved domains– This rule applies even if a script is included

recursively

• Use Manifest to constrain all inclusions – Attackers will no longer be able to store attack

code on external domains unless they are mutually approved

2009/05/19 15

Unrestricted Outbound Communication

• The SOP does not stop any content from other domains from being requested and loaded into the origin page.

• These requests for content can be abused to send information out to any arbitrary domain.– user’s session, credit card infor

mation, personal emails, or username and password pairs.

2009/05/19 16

Security Benefits - Unrestricted Outbound Communication

• Any script can read content from the document origin• Transmission blocked by SOMA Manifest• Blocks cookie-stealing, similar information theft attacks,

and timing attacks based upon cached content– Web caching, DNS caching, cached cookies

• E. W. Felten and M. A. Schneider. Timing attacks on web privacy. In Proc. 7th ACM CCS, pages 25–32, 2000

2009/05/19 17

Cross-site Request Forgery (XSRF/CSRF)

• Tricks the victim into loading a page that contains a malicious request, which inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf– Change the victim's e-mail address, home address, or

password, or purchase something

• For most sites, browsers will automatically include with such requests any credentials associated with the site– User’s session cookie, authentication credential, IP address– If the user is currently authenticated to the site, the site will have

no way to distinguish this from a legitimate user request.

2009/05/19 18

Security Benefits - Cross-site Request Forgery (XSRF/CSRF)

• A script can make requests to any domain• Request blocked by SOMA Approval

– Approval limit the possible attack vectors for a CSRF– Manifest ensures that an origin site cannot be used in an attack o

n another arbitrary site

• Leaks less information to site than the current Referrer HTML header– J. Kyrnin. Are you invading your customers’ privacy?

2009/05/19 19

Cross-Site Scripting (XSS)

• An attacker inserts code onto a page returned by an unsuspecting web server– No precise definition seems to be universally accepted

• Typically involves JavaScript code engaging in cross-domain communication with malicious web servers

• User-supplied data is not sufficiently sanitized before being stored and/or displayed to other users– Steal information associated with that domain or perform actions

on behalf of the user

• The authors note that no current proposal targets the cross-domain communication involved in most JavaScript exploits

2009/05/19 20

Security Benefits - Cross-Site Scripting (XSS)

• Any script can include other scripts (from any site)

• Inclusion blocked by SOMA Manifest– Blocks the “cross” part of cross-site scripting, since inf

ormation can no longer be loaded from or sent to external, unapproved domains

2009/05/19 21

Security Benefits - Bandwidth Stealing

• A document can include content from anywhere– Someone is including images or other content from a

(non-consenting) content provider into their page using a direct link to the original file

– Exceeding bandwidth cap and being charged extra hosting fees or having site shut down

• Inclusion blocked by SOMA Approval

2009/05/19 22

Deployment Costs (1/2)

• In the Browser– A prototype add-on for Mozilla Firefox 2 and 3.– Standard XPI package: 16kB– Icon in statusbar indicates that SOMA is running

• On Origin Sites– Needs to provide a soma-manifest file– Could be automated using a web crawler, or done by

an admin who is willing to set policy– Manifests for common sites would be relatively small

• Used the PageStats to load the home page for the global top 500 sites as reported by Alexa

– Avg: 5.45 domains (5.3 stdev); maximum: 32• Traversed large sections of a major news site (www.cbc.ca)

– Domains# needed in the manifest: approximately 45

2009/05/19 23

Deployment Costs (2/2)

• On Content Provider– Need to provide either a file or script which can handl

e requests to soma-approval– The time needed to create this policy script depends h

eavily upon the needs of the site in question– Data being transferred

• YES/NO response (around 4 bytes of data) plus any necessary headers

– The additional network load on content providers due to SOMA is negligible

• Using data from the top 500 Alexa• Avg request size: 10459 bytes (118197 bytes stdev); medi

an: 2528 bytes– Estimate probably overstated

2009/05/19 24

Prototype - Performance• Primary overhead in running SOMA

– request a soma-manifest or soma-approval from each domain referenced on a web page

• The manifest can be loaded in parallel – Not affect total page load times

• Time to retrieve a soma-approval from a given domain– Avg HTTP request round-trip time for each of 40 representative web s

ites on a per-domain basis (use PageStats)• Page load times: Increase the time to request all content from each

accessed domain by the soma-approval request estimate for that domain. The time of the last response from any domain then serves as our final page load time.

• The avg additional network latency overhead – Non-cached: Increased page load time from 2.9 to 3.3 sec (or 13.28%) – Can drop to 5.58% (58% of revisited page loads)

2009/05/19 25

Related Work

• SOMA breaks client-side mashups which use unapproved code.– In order for a mashup to work with SOMA, every web

site involved must explicitly allow participation.

• Compared to Subspace and MashupOS– SOMA restricts communication between the web pag

e (browser) and servers • Focuses on interactions with external servers

– Mashup solutions restrict local communication between elements on the page

• Focuses on interactions within the page

2009/05/19 26

Related Work: Mozilla's Content Security Policy

• First version (“Site Security Policy”) similar to SOMA

• Most recent version has only manifest– Does not protect against cross site request for

gery

• Other major differences:– policy is per-resource– more complex syntax required

2009/05/19 27

Conclusion and Comments

• Incrementally deployable (with incremental benefit)• No configuration/usage burden on end users• Required changes/configuration are done by site operato

rs• Changes are relatively simple to understand and easy to

implement• Gives server operators the ability to specify which sites c

an interact with their content• Good idea, but still has limitations (does not stop attacks

to or from mutually approved partners, etc.)