Hidetake Jo

A security policy for the web Access from

http://www.example.com/dir/test.html

Meant to prevent cross-site issues Evil.com can’t access content from bank.com

Simple enough, right?

SOP is implemented everywhere Browser features, RIA plugins, etc.

SOP is implemented differently Neat but dangerous

Makes web developers life very interesting

High level overview of.. Same Origin Policies by technology▪ Browsers, Javascript, Cookies, RIA, etc

Summary of deltasHow this affects usConclusion

Get/Post request can be made from one domain to another.

Get/Post response can only be read under the following conditions: If the ports match on both sites. If the domain + subdomain match on both

sites.

Exceptions If two different subdomains (different origin) is

under the same domain.. And one is performing domain lowering.▪ Clock.live.com vs Vulnerable.live.com▪ Clock.live.com setting document.domain to live.com.▪ Vulnerable.live.com is owned then attacker can set

domain to live.com and access clock.live.com!▪ Threats: All eggs in one basket (*.google.com or

*.live.com). Cross-subdomain communication.

Domain Lowering Putting all the eggs in one basket

Cross-Site Request Forgery Netflix▪ http://www.webappsec.org/lists/websecurity/

archive/2006-10/msg00063.html Get/Post request for adding movie to

queue Get/Post works cross-domain…

If you’re including or exposing resource cross-domain such as JSON, SCRIPT, etc Script▪ Forfeit trust to site exposing the script resource

XML/JSON▪ Risk information disclosure if you’re exposing resource▪ E.g. Read content of script, access JSON array, retrieve XML

data.▪ JSON: var data = { "social": "11-22-3333", "name": "Joe"};▪ XML: var data = <info><social>11-22-3333</social><name>Joe</name>

Javascript\XML Hijacking Gmail▪ http://jeremiahgrossman.blogspot.com/

2006/01/advanced-web-attack-techniques-using.html

Exposed script contained contacts info Script path was fully predictable Script can be included x-domain Script content can be accessed

Variables Functions (e.g. function_name.toString() )

Cookies by default permit read/write access to cookie values if: The domain is the same (Limited subdomain check)

▪ Foo.bar.com bar.com▪ bar.com foo.bar.com

Does not respect port numbers! Does not respect scheme

▪ Unless you opt in to secure attribute

Foo.bar.com can steal/poison cookie on bar.com.

Foo.bar.com:1111 can steal/poison cookie on Foo.bar.com:2222.

With regards to cookie and subdomains and ports are of limited security boundary.

IE does not use ports during origin calculation. You can read/write/script between:▪ Bar.com:80 and Bar.com:1234

Hosting multiple web apps on different ports Should be avoided when possible

Ports are not a security boundary for IE Host web apps on separate domains

You can not issue request cross-domain.

You can only read response on the same domain.

Most restrictive Same Origin PolicyBut it allows you to insert arbitrary

header value when issuing request. (e.g. SOAPAction header)

Using declarative security Permits you to expand origin▪ This is an opt-in policy/feature▪ Access-Control-Allow-Origin/Method Header

Allows you to send request cross-domain Allows you to read response cross-domain More Info:

Cross Origin Resource Sharing (Firefox 3.5, Safari 4.0)▪ http://www.w3.org/TR/access-control/

XDomainRequest Object (IE8)▪ http://msdn.microsoft.com/en-us/library/

cc288060(VS.85).aspx

Overly permissible policy Kind of like ACL on Windows. Tempting for frustrated developer to

give everyone full control.

Site where the binary lives is origin. Site where the binary is embedded is also considered

origin in some cases. App.xap lives in foo.com and a page on bar.com is using

it. App now has access to bar.com and foo.com.▪ Read/Write DOM on bar.com▪ Make network requests back to foo.com

Lock these RIA runtimes down: Cross-domain policy files▪ For Flash and Silverlight▪ Easy to mess up: Tom found a major site that allowed all sites on the

internet to read/write to their site for over a year.. Embed these applets with security flags.▪ Silverlight:▪ EnableHtmlAccess

▪ Flash▪ AllowScriptAccess

Hosting potentially evil RIA files Can make network connection back to

your hostEmbedding potentially evil RIA files

Can script on your siteHosting overly permissive policy files

Can read and write against your domain

Flash flash.net.SharedObject▪ Capacity: 100KB by default (adjustable)▪ Same Origin Policy▪ By Domain▪ By User

3rd Party Content (enabled by default) Silverlight

System.IO.IsolatedStorage.IsolatedStorageFile ▪ Capacity: 1024KB▪ Same Origin Policy▪ By User + Assembly▪ By User + Domain + Assembly

HTML 5 FeatureEnables cross-domain

Communication target.postMessage(msg, origin)

Can implemenet listener by calling target.attachEvent(“onmessage” , handler) target.addEventListener(“message”, handler,

useCapture)Origin check in handler optional

Lack of optional origin checkTrusting potentially malicious origin If no origin check is done by design

Sanitize incoming message before use

In addition to Get/Post there is Put/Delete support for forms in HTML 5

Html 5 Spec supports this via form Hopefully this will not be allowed x-

domain!

Html 5 FeatureEnables bi-directional binary/text

comm.Still unclear how it will be securedEnable cross-domain

communication.

Up to dev/test/pm to define the policy. Red flag!

Sitelock technique Contain usage to one domain. (Different

from SOP) Generally should follow the same-origin

policy… But which one???▪ The strictest definition to be safest.▪ Port, Domain, Subdomain, Protocol should match for

read/write access.

My attempt at a summary table…

Cross-domain Get/Post can introduce CSRF. Incorrectly configured RIA policy files and

apps can introduce cross-site access. Lenient subdomain rule for cookie access

makes hosting multiple sites a challenge. Cross-domain resource sharing of script,

json, xml, etc can introduce hijacking problems.

IE doesn’t utilize port for origin calculation. Web apps should be hosted on distinct domains.

One-off x-domain apis such as postmessage can catch developers off guard.

Etc..

We’re in a bad state with varying definition for same-origin policy.

Hard for developers to understand the risk with their design.

Audit all the areas that can go wrong: Webservices that return includable data. New ActiveX controls. Features that leverage RIA platforms. Crossdomain policy files Declarative security flags Usage of apis that permit x-domain access by design Web service that permits state changing operations Topology of the web app setup. Etc.

There are other other technology that needs to be looked at: Gears, Air, Java, HTML 5 features, etc.

Same-origin policy is inconsistent today. It will probably continue to stay this

way. For compat reasons…

The same-origin policy will probably evolve. Hence the definition in this deck may be

obsolete soon.

If you have questions, concerns, corrections please mail me at: hidejo@gmail.com