1. Same Origin Policies
Hidetake Jo

2. What is it? A security policy for the web
Access from
Meant to prevent cross-site issues
Evil.com can’t access content from bank.com
Simple enough, right?

3. Not quite… SOP is implemented everywhere
Browser features, RIA plugins, etc.
SOP is implemented differently
Neat but dangerous
Makes web developers life very interesting

4. Agenda High level overview of.. Summary of deltas How this affects us
Same Origin Policies by technology
Browsers, Javascript, Cookies, RIA, etc
Summary of deltas
How this affects us
Conclusion

5. Same Origin For Get/Post for Most Browsers
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.
Example.com
Request *
Example.com
Response
Example.com:80
Response
Example.com:80
Response
Example.com:100
Example.com
Response
Foo.Example.com
Example.com
Response
Different.com

6. Same Origin For Get/Post Request for Browsers
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.

7. Risk Domain Lowering Cross-Site Request Forgery
Putting all the eggs in one basket
Cross-Site Request Forgery
Netflix
Get/Post request for adding movie to queue
Get/Post works cross-domain…

8. Script and XML Resources
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": " ", "name": "Joe"};
XML: var data = <info><social> </social><name>Joe</name>
Example.com
Response
Example.com:80
Response
Example.com:80
Response
Example.com:100
Example.com
Response
Foo.Example.com
Example.com
Response
Different.com

9. Risk Javascript\XML Hijacking Exposed script contained contacts info
Gmail
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() )

10. Same Origin for Cookies
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:80
Response
Example.com:80
Response
Example.com:100
Example.com
Response
Foo.Example.com
Example.com
Response
Different.com

11. Risk 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.

12. Same Origin for IE 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:80
Response
Example.com:80
Response
Example.com:100
Example.com
Response
Foo.Example.com
Example.com
Response
Different.com

13. Risk 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

14. Same Origin for XmlHTTPRequest
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

15. Same Origin for XDomainRequest + COR
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)
XDomainRequest Object (IE8)

16. Example\Risk Overly permissible policy Kind of like ACL on Windows.
Tempting for frustrated developer to give everyone full control.

17. Same Origin for Flash/Silverlight
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

18. Risk 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

19. Same Origin for Flash/Silverlight Data Storage
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
By User + Assembly
By User + Domain + Assembly

20. Same Origin for PostMessage API
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

21. Risk Lack of optional origin check
Trusting potentially malicious origin
If no origin check is done by design
Sanitize incoming message before use

22. Same Origin for Put/Delete
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!

23. Same Origin for WebSockets
Html 5 Feature
Enables bi-directional binary/text comm.
Still unclear how it will be secured
Enable cross-domain communication.

24. Same Origin for ActiveX
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.

25. Summary
My attempt at a summary table…

26. Different policies = Trouble
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..

27. How does this impact us?
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.

28. Conclusion
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.

29. Questions
If you have questions, concerns, corrections please mail me at: