Presentation is loading. Please wait.

Presentation is loading. Please wait.

Same Origin Policies Hidetake Jo.

Similar presentations

Presentation on theme: "Same Origin Policies Hidetake Jo."— Presentation transcript:

1 Same Origin Policies Hidetake Jo

2 What is it? A security policy for the web
Access from Meant to prevent cross-site issues can’t access content from 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. Request * Response Response Response Response Response

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. vs setting document.domain to is owned then attacker can set domain to and access! Threats: All eggs in one basket (* or * 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> Response Response Response Response Response

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)   Does not respect port numbers! Does not respect scheme Unless you opt in to secure attribute Response Response Response Response Response

11 Risk can steal/poison cookie on can steal/poison cookie on 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: and Response Response Response Response Response

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) 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 and a page on is using it. App now has access to and Read/Write DOM on Make network requests back to 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 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:

Download ppt "Same Origin Policies Hidetake Jo."

Similar presentations

Ads by Google