Presentation is loading. Please wait.

Presentation is loading. Please wait.

Hidetake Jo.  A security policy for the web  Access from  Meant to prevent cross-site issues  Evil.com can’t.

Similar presentations


Presentation on theme: "Hidetake Jo.  A security policy for the web  Access from  Meant to prevent cross-site issues  Evil.com can’t."— Presentation transcript:

1 Hidetake Jo

2  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  SOP is implemented everywhere  Browser features, RIA plugins, etc.  SOP is implemented differently  Neat but dangerous  Makes web developers life very interesting

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

5  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.comExample.com:80 Response Example.com:80 Response Example.com:100Example.com Response Foo.Example.comExample.com Response Different.com

6  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  Domain Lowering  Putting all the eggs in one basket  Cross-Site Request Forgery  Netflix ▪ /msg00063.html  Get/Post request for adding movie to queue  Get/Post works cross-domain…

8  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 = Joe Example.com Response Example.comExample.com:80 Response Example.com:80 Response Example.com:100Example.com Response Foo.Example.comExample.com Response Different.com

9  Javascript\XML Hijacking  Gmail ▪ 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() )

10  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.comExample.com:80 Response Example.com:80 Response Example.com:100Example.com Response Foo.Example.comExample.com Response Different.com

11  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  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.comExample.com:80 Response Example.com:80 Response Example.com:100Example.com Response Foo.Example.comExample.com Response Different.com

13  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  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

15  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  Overly permissible policy  Kind of like ACL on Windows.  Tempting for frustrated developer to give everyone full control.

17  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  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  Flash  flash.net.SharedObject ▪ Capacity: 100KB by default (adjustable) ▪ Same Origin Policy ▪ By Domain ▪ By User  3 rd Party Content (enabled by default)  Silverlight  System.IO.IsolatedStorage.IsolatedStorageFile ▪ Capacity: 1024KB ▪ Same Origin Policy ▪ By User + Assembly ▪ By User + Domain + Assembly

20  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  Lack of optional origin check  Trusting potentially malicious origin  If no origin check is done by design  Sanitize incoming message before use

22  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  Html 5 Feature  Enables bi-directional binary/text comm.  Still unclear how it will be secured  Enable cross-domain communication.

24  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  My attempt at a summary table…

26  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  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  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 If you have questions, concerns, corrections please mail me at:


Download ppt "Hidetake Jo.  A security policy for the web  Access from  Meant to prevent cross-site issues  Evil.com can’t."

Similar presentations


Ads by Google