hidetake jo. a security policy for the web access from meant to prevent cross-site issues ...
TRANSCRIPT
Hidetake Jo
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?
SOP is implemented everywhere Browser features, RIA plugins, etc.
SOP is implemented differently Neat but dangerous
Makes web developers life very interesting
High level overview of.. Same Origin Policies by technology▪ Browsers, Javascript, Cookies, RIA, etc
Summary of deltasHow this affects usConclusion
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.
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.
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…
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>
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() )
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
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.
IE does not use ports during origin calculation. You can read/write/script between:▪ Bar.com:80 and Bar.com:1234
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
You can not issue request cross-domain.
You can only read response on the same domain.
Most restrictive Same Origin PolicyBut it allows you to insert arbitrary
header value when issuing request. (e.g. SOAPAction header)
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
Overly permissible policy Kind of like ACL on Windows. Tempting for frustrated developer to
give everyone full control.
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
Hosting potentially evil RIA files Can make network connection back to
your hostEmbedding potentially evil RIA files
Can script on your siteHosting overly permissive policy files
Can read and write against your domain
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
HTML 5 FeatureEnables 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
Lack of optional origin checkTrusting potentially malicious origin If no origin check is done by design
Sanitize incoming message before use
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!
Html 5 FeatureEnables bi-directional binary/text
comm.Still unclear how it will be securedEnable cross-domain
communication.
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.
My attempt at a summary table…
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..
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.
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.
If you have questions, concerns, corrections please mail me at: [email protected]