Same Origin Policies

1. Same Origin Policies Hidetake Jo

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

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

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 • 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…

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

9. Risk • 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() )

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

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

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)

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

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

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: hidejo@gmail.com