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 deltas
How this affects us
Conclusion

Get/Post request can be made from one domain to another.
Example.com

Request
*
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.
Example.com
Response
Example.com
Example.com:80
Response
Example.com:80
Example.com:80
Response
Example.com:100
Example.com
Response
Foo.Example.com
Example.com
Response
Different.com

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). Crosssubdomain communication.

Domain Lowering
 Putting all the eggs in one basket

Cross-Site Request Forgery
 Netflix
▪ http://www.webappsec.org/lists/websecurity/archive/20
06-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>
Example.com
Response
Example.com
Example.com:80
Response
Example.com:80
Example.com:80
Response
Example.com:100
Example.com
Response
Foo.Example.com
Example.com
Response
Different.com

Javascript\XML Hijacking
 Gmail
▪ http://jeremiahgrossman.blogspot.com/2006/01/advanc
ed-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
Example.com
Response
Example.com
Example.com:80
Response
Example.com:80
Example.com:80
Response
Example.com:100
Example.com
Response
Foo.Example.com
Example.com
Response
Different.com



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
Example.com
Response
Example.com
Example.com:80
Response
Example.com:80
Example.com:80
Response
Example.com:100
Example.com
Response
Foo.Example.com
Example.com
Response
Different.com

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 Policy
But it allows you to insert arbitrary header
value when issuing request. (e.g. SOAPAction
header)
Example.com
Request
Example.com

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 host

Embedding potentially evil RIA files
 Can script on your site

Hosting 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 Feature
Enables 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 check
Trusting 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 Feature
Enables bi-directional binary/text comm.
Still unclear how it will be secured
Enable 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