Same Origin Policies Hidetake Jo

What is it? 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?

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

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

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

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.

Risk Domain Lowering Cross-Site Request Forgery 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…

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": "11-22-3333", "name": "Joe"}; XML: var data = <info><social>11-22-3333</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

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

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

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.

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

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

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

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) http://www.w3.org/TR/access-control/ XDomainRequest Object (IE8) http://msdn.microsoft.com/en-us/library/cc288060(VS.85).aspx

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

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

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

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

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

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

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!

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

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.

Summary My attempt at a summary table…

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

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.

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.

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