Same Origin Policy Weaknesseskuza55 <kuza55@gmail.com>

http://kuza55.blogspot.com/

AbstractThe Same Origin Policy is the most talked about security policy which relates to web applications, it is the constraint within browsers that ideally stops active content from different origins arbitrarily communicating with each other. This policy has given rise to the class of bugs known as Cross-Site Scripting (XSS) vulnerabilities, though a more accurate term is usually HTML or JavaScript injection, where the ability to force an application to echo crafted data gives an attacker the ability to execute JavaScript within the context of the vulnerable origin.

This paper takes the view that the biggest weakness with the Same Origin Policy is that it must be implemented by every component of the browser independently, and if any component implements it differently to other components then the security posture of the browser is altered. As such this paper will examine how the 'Same Origin Policy' is implemented in different circumstances, especially in active content, and where the Same Origin Policy is not really enforced at all.

Same Origin Policy Weaknesses.........................................................................................1Abstract............................................................................................................................1

The Beginning.....................................................................................................................3An Obvious Attack..............................................................................................................3Understanding Context........................................................................................................3Active and Passive Context Components............................................................................4JavaScript Hijacking Advances...........................................................................................4Other Components...............................................................................................................5

The HTTP Parser.............................................................................................................5The CSS Parser................................................................................................................6Flash VM.........................................................................................................................7Java Applet VM...............................................................................................................8Google Gears Web Workers............................................................................................9Conclusion I...................................................................................................................10

Part II.................................................................................................................................10Browser Cookies............................................................................................................10JavaScript document.domain.........................................................................................12Other DNS Trust Relationships.....................................................................................12

Hetrogenous DNS Records........................................................................................12Ambiguous IP Addresses...........................................................................................13

Flash and Silverlight crossdomain.xml..........................................................................14IE By Design SOP Bypasses.........................................................................................15

MSXML2.XMLHTTP.6.0 and related components..................................................15ActiveX SiteLock......................................................................................................16No Port Restrictions on JavaScript, etc.....................................................................16

Conclusion II.................................................................................................................16The End..............................................................................................................................16

The BeginningThe history behind the name Cross-Site Scripting is an interesting one that will set the stage for understanding how the many parsers present in browsers can be abused to perform XSS attacks. In the beginning before JavaScript was implemented, there was no active content and there was no Same Origin Policy, and applications could point the src attributes of html tags wherever they wanted and nothing dared to stop them. But this did not mean there were no vulnerabilities, the ability to force a user to make a request to the server lead to what we now call Cross-Site Request Forgery attacks, but which were initially labeled as 'Confused Deputy' attacks. The ability to force user actions was already taking a toll on the security of the web.

With the introduction of JavaScript, fundamental changes needed to be made to add some kind of security to the web, otherwise JavaScript could actively interact with content from other origins and steal data or perform actions on the user's behalf. The solution to this problem came in the form of the Same Origin Policy (SOP). The SOP is typically best understood in the context of JavaScript, where JavaScript is not allowed to get or set properties from windows belonging to other origins where an origin is defined as a 3-tuple made up of a protocol, a hostname and a port.

An Obvious AttackThe most obvious attack against a policy which says active content can only interact with content from it's own origin

is to either look for places where the origin is not enforced, as many of the original Same Origin Policy Bypasses did, or to figure out a method of placing your own active content in the same origin as the application you wanted to attack as XSS bugs do. (From here we will revert to modern terminology which labels the original Cross-Site Scripting bugs as Same Origin Policy Bypasses, and refers to JavaScript Injection bugs as Cross-Site scripting or XSS bugs.)

Understanding ContextWhen the SOP was being implemented in the browser the decision was made that the HTML context would be used, rather than the JavaScript context. This may seem irrelevant when JavaScript is being embedded directly onto the page like so:

<hmtl><body><script>alert("Hi!");</script></body></html>

As the context is one and the same, but it makes a marked difference in what can and cannot be exploited when examining HTML which looks like this:

<hmtl><body><script language="JavaScript" src="http://www.othersite.com/some.js" ></script></body></html>

The decision meant that to get into the appropriate context inside the JavaScript interpreter you needed to first get into the right context in the HTML interpreter. So while typical XSS bugs are just JavaScript Injection bugs, they

are a really just a subset of HTML Injection bugs. While the following piece of PHP code which generates the vulnerable JavaScript inside a HTML container is trivially exploitable as single quotes are not escaped:

<html><body><script><?phpprint "var data = '".htmlentities($_GET['xss'])."';";?></script></body></html>

The same cannot be said of the PHP/JavaScript code alone like so:

<?phpprint "var data = '".htmlentities($_GET['xss'])."';";?>

This is because we cannot invoke the proper context in the HTML interpreter since we cannot use the needed control characters to create HTML tags, and we cannot simply point the JavaScript interpreter to the code and have it use to context from which it loaded the code.

Active and Passive Context ComponentsAll of the components inside browsers can be grouped inside one of two categories; active or passive context components. The HTML interpreter is an active context component since all HTML that is loaded is loaded in the context of the domain it was loaded from, as opposed to the JavaScript interpreter which is a passive component since it inherits the context of the context that loaded it.

There are two specific classes of attacks; code injection and information leakage,

that are specific to each respective type of component.1

As such the passive equivalent of XSS bugs to JavaScript is JavaScript and JSON Hijacking, whereby an attacker is able to setup a context such that when code containing sensitive information is executed in it, sensitive information can sometimes be extracted.

JavaScript Hijacking AdvancesWhile XSS has been thoroughly, but not exhaustively, examined, JavaScript hijacking has received relatively little attention, however some interesting work has been done recently to show how changes to the JavaScript parser in Gecko, namely the support of E4X has introduced a new method of extracting data cross-domain.2 Namely it has been noted that the new JavaScript parser will happily parse any valid fully XML documents. This means that it van be pointed at arbitrary XML documents on the web, which will be interpreted as JavaScript and executed in an attacker’s chosen context.XML being ‘executed’ will typically have no effect as it is simply considered an object, though unlike most objects it does not have methods attached to it, however it does have constructors. Constructors are single statement pieces of JavaScript code wrapped in braces like so:

<name>{get_name();}</name><mail>none</mail>

1 A third type of attack in the form of Confused Deputy or CSRF attacks exists, but is outside the scope of this paper.2 http://code.google.com/p/doctype/wiki/ArticleE4XSecurity

As such, if a place where user input is printed to a page that is valid XML, then it may be possible to construct braces and some accompanying JavaScript code around some sensitive data like so:

<html><body>  Non-JavaScript text  Something completely non-parseable - 1 2 3 **** }}  ...  { x =     ...    User mailbox data    in HTML format    ...  } </body></html>

Then embedding the appropriate URL in a script tag would see the window.x variable populated with the contents of a potentially sensitive email.

However, the chance of exploitation remains low as the prerequisites are rather high:

The vulnerable page must have sensitive content

The attacker must be able to inject braces around the sensitive content in such a way that the sensitive content it a valid XML block encapsulated in some JavaScript statement

The document must be valid XML, which means that

o The document contains no unclosed tags such as <br>

o All the attributes in the document are quoted using single (‘) or double quotes (")

o The document does not contain tags such as <?xml or <!DOCTYPE

o However <?xml support is being added

However, if these conditions are met then the attack described can be executed, though sometimes existing braces may make exploitation trickier in which case it is possible to close one set of braces then place a semi-colon and open a new set. Note braces cannot contain any semi-colons inside.

Other Components

The HTML and JavaScript parsers are not the only components in web browsers, rather they contain many and varied components which bring the web together. In fact they typically contain more parsers and components than this paper can cover and this author knows about, however an examination of the following additional components can lead to some insights into what kind of new vulnerabilities new parsers and implementations of the Same Origin Policy may bring:

HTTP Parser CSS Parser Flash VM Java Applet VM Silverlight VM Google Gears Web Workers

The HTTP ParserThe lowest level parser we deal with is the HTTP parser, and understanding of this fundamental part of the browser has lead to Header Injection and HTTP Response Splitting attacks as well as typical XSS attacks, where the attack

jumps from HTTP headers to the HTML parser.

The HTTP Parser is invoked from many different contexts, including HTML, JavaScript, CSS, etc. When it loads content it loads it in the only sensible way possible; it loads it in the context from which it receives it rather than the context of the invoking script. As such it is considered to be an active context component as it does not inherit it’s context. And therefore the attacks against it work by trying to inject active content into the vulnerable context.

One common theme for the rest of this paper can be found in papers such as ‘The Extended HTML Form attack’3, ‘Inter-Protocol Communication’4, etc, where the authors have noted that the HTTP parser in browsers can be pointed at any text-based protocol, and other than attempting to not interpret data from some well known non-http ports, many still do not confirm that what they are receiving is HTTP before processing it.

The recent advances in browser protections involve Firefox practically solving the problem in Firefox 2.0 whereby they have started searching for the string “http” (case-insensitively) in the first 8 bytes.

However no other browsers do this. The only protection in most browsers is the ports list that the http protocol handler will not talk to in [3].

3 http://resources.enablesecurity.com/resources/the%20extended%20html%20form%20attack%20revisited.pdf4 http://www.bindshell.net/papers/ipc

The CSS ParserThe CSS parser is not usually considered active content, as it resides in a similar realm to HTML where it can influence the page, sometimes conditionally, but cannot really act upon it, but can invoke active content (in the form of JavaScript, usually). This means that it is a possible intermediary between a filtered HTML Injection and an arbitrary script execution exploit, yet like JavaScript it is a passive context component that must be embedded within a HTML container.

And like JavaScript, it too can leak information, however due to how it parses data no significant uses for this have been determined other than remotely determining what the style of a 3rd party website looks like; phear.

However, this ability to determine what styles exist have allowed researchers and attackers alike to detect a user’s ability to access a stylesheet at a given URL. This has allowed us to do things like remotely determining which Firefox extensions a user has installed using only CSS5 and determining whether a victim is authenticated as an administrative user to a website before launching a noisy attack6.

Recently however, Eduardo “sirdarckcat” Vela and Stefano “WiSec” Di Paola have both independently discovered that CSS can be used for some limited active scripting, and that CSS can be used to read parts of the page.7 Again, as this has been covered

5 http://kuza55.blogspot.com/2007/10/detecting-firefox-extension-without.html6 http://sirdarckcat.blogspot.com/2007/11/inside-history-of-hacking-rsnake-for.html7 http://www.thespanner.co.uk/wp-content/uploads/2008/10/the_sexy_assassin2ppt.zip

elsewhere the content will not be needlessly reproduced; suffice to say that injecting CSS can be used to extract data from the page even when JavaScript is disabled.

Flash VMThe Flash VM is an interesting component in that it is in itself an active content and active context component, and yet shares the trait of being able to somewhat communicate with the hosting page, yet this communication is one-sided, and so information leaks from Flash are rare.

However information leaks are possible when code is written that assumes it can only comminucate with a single origin:

getURL ('javascript:func("'+sensitive_data+'")');

An attacker would be able to embed such code on their page and then create a function by the name of func which captured the sensitive data that was retrieved from the vulnerable application’s domain.

And while there has been significant work related to the examination of XSS-style attacks against the ActionScript portion of Flash applications8, much like DOM-Based XSS9, there has been no analysis of the Flash bytecode parser and VM in the context of SOP violations.

While an exhaustive examination of the Flash SWF file parser will not be

8 http://www.wisec.it/sectou.php?id=464dd35c8c5ad9 http://www.webappsec.org/projects/articles/071105.shtml

examined, the following things should be noted:

When invoked, the parser does not check the Content-Type header of the HTTP response, nor does it check the file extension of the file

The only check performed to ascertain the file is a proper swf file is to check the first 3 bytes for the letters CWS or FWS

Flash bytecode can contain ‘jumps’

The Flash VM which is responsible for parsing ActionScript 2 bytecode works on a similar model to CPUs, in that it does not validation of the code, but merely executes it from start to finish

The Flash VM contains bytecode for a ‘stop’ instruction

Due to these facts, it is in some cases possible to smuggle a swf object into the context of a 3rd party site if the attacker can control the first 3 bytes of the response, and also controls the point at which the Flash VM starts parsing instructions, even if it is only to insert a jump to a later section of flash code.

There are two somewhat standard scenarios where this knowledge of the Flash VM leads to exploits in the following situation:

When hosting user supplied files, such as text files, where specific filtering to stop Flash files being uploaded as other file types does not exist

JavaScript callback functions where an attacker is able to control the beginning of the string, but cannot use standard

XSS techniques due to HTTP Content-Type headers or filtering

Once a request has been constructed so that it can be processed as a proper swf file, it merely needs to be embedded in a html object like so:

<html><body><EMBED src="http://site.com/file.txt" TYPE="application/x-shockwave-flash" allownetworking="always" allowscriptaccess="always"></EMBED></body></html>

And it will be executed in the context of the site it is being hosted on.

A simple ActionScript payload may look something like this:

class Attack { static function main(mc) { var req:LoadVars = new LoadVars(); req.x = "y"; req.load("http:// site.com/sensitive.php"); req.onData = function(src:String) { req.x = src; req.send("http://www.evil.com/capture.php", "_self", "POST"); }; }}

Java Applet VMThe Java Applet VM is, in terms of what kinds of attacks it can be utilized for, almost identical to the Flash VM, though the Java VM gains both the context within which it was embedded and from which it is hosted. This means that information leaks such as those through JavaScript are possible if a valid response, containing sensitive

information and the appropriate Java code can be constructed; however due to the SOP, being able to execute code in a context will lead to that information leak anyway, and is considerably easier, and so information leaks of this nature will not be examined here.

This issue has been discussed in several10 places11 where researchers have conducted examinations of the JAR format and found that JAR files are essentially read from the end of a file, rather than the beginning, and as such a JAR file can be both a valid image file (or any other file where the file is read from the start and to which extraneous content can be appended) and a valid JAR file.

As noted by the researchers who have disclosed this, this makes it much easier to attack file upload functionality as images are often accepted as file uploads, and no checking for JAR files is usually done.

JAR Files can then access the site using a user’s cookies, as others have already released PoC code, this presentation does not address this topic in depth.

Google Gears Web WorkersGoogle Gears does not have it’s own JavaScript interpreter, but rather utilizes the browsers’ native JavaScript interpreter. It is invoked by Google Gears only in one module; the Worker Pool module, which developers can use to create separate workers which execute JavaScript code outside the context of

10 http://www.gnucitizen.org/blog/java-jar-attacks-and-features/

11 http://pseudo-flaw.net/content/web-browsers/corrupted-jars/

the document and are given a simple mechanism to message back and forth between the worker pool and the workers themselves. Workers can be loaded both from a string of JavaScript, which is irrelevant to us, since it merely resembles a different kind of JavaScript eval() call.

However the workerPool.createWorkerFromUrl() function allows us to, as the function name say, create a Worker from a URL, and in this case it is an active context component (with the caveat that the script must call AllowCrossOrigin() to be given the security context).

This is particularly interesting since this means that a browsers’ native JavaScript interpreter can be invoked as an active context component.

For most browsers this simply means that injections into dynamically generated JavaScript files (anywhere in the file) are trivially exploitable, even when they are served with Content-Type headers which make them non-renderable.

Also, given JavaScript’s flexibility it allows GIFAR-like attacks where a file is created that is both a valid image and a valid JavaScript file. The GIF file format was found to be particularly easy to work with for this attack.

However, on Firefox, it presents a whole new problem when combined with the recent addition of E4X. As mentioned before the following piece of code is valid JavaScript:

<name>{get_name();}</name><mail>none</mail>

And it executes the get_name function.

Given that braces ({}) are not often considered meta characters it is rare for them to be escaped, further many applications which use actual XML to achieve AJAX results return data in a very similar format, it is often possible to conduct an XSS attack via unescaped braces like so:

<name>{{eval('var wp = google.gears.workerPool; wp.allowCrossOrigin();

var request = google.gears.factory.create("beta.httprequest"); request.open("GET" , "/sensitive_data"); request.send("");

request.onreadystatechange = function() {if (request.readyState == 4) { wp.sendMessage(request.responseText, 0);}};')}}</name><mail>none</mail>

which would send the worker pool with the id 0 the response. Additional damage can be done with Google Gears as well, since these workers can remain active until the browser closes and can also send messages to and from an attacker controlled domain after the original page which loaded it has been closed. This has been abused to build a Worker-based proxy that does not die until the browser is closed.

Also, this same functionality is intended to be included in Firefox 3.1 Beta 2 and release versions, so this could become a valid way of attacking standard Firefox users in the near future.12

12 http://developer.mozilla.org/web-tech/2008/09/04/web-workers-part-1/

Conclusion IAs we can see; if we classify how components determine the security context to be used in their implementation of the SOP, we can, by simply examining the parser, understand the additional risks such a component will pose without needing to inspect any of the functions themselves.

This is not to say that all security issues can be seen this way, but simply the SOP design issues the component introduces which web developers need to work around can be envisioned without needing to repeat the discovery of an attack on a new type of component, as has been done by many researches regarding many browser-based components.

As such these discoveries may be treated as routine and expected rather than something that catches anyone unexpectedly.

Part IIAs mentioned in the abstract, this paper’s view is that the biggest issue with the SOP is that it, unlike restrictions such as CPU rings, need to be specifically implemented in each piece of browser code which deals with URLs.

The first part of this paper investigated how the design decision related to how security context is established can show us how they impact security, this portion of the paper will attempt to catalogue as many currently known and unknown methods of bypassing the SOP by utilizing different components as possible to illustrate this further with examples of components that have simply ignored the most widely accepted

security policy on the web for various reasons.

The components that have been identified are:

Browser Cookies JavaScript document.domain Other DNS Trust Relationships Flash and Silverlight

crossdomain.xml IE By Design SOP Bypasses

o MSXML2.XMLHTTP.6.0 and related components

o ActiveX SiteLocko No port restrictions on

JavaScript

While this is a relatively short list, this is a list of issues that are known to the creators of the objects which have simply gone unfixed and as such potentially allow us to conduct attacks from different ports and different hosts and sometimes different protocols.

Browser CookiesBrowser cookies have a unique place in browser security in that they are one of the most closely guarded objects of a website, as they often contain enough details to authenticate as a given user, however they were never designed with security in mind, and as such they leave a few large holes that are often unaccounted for.

The first, most obvious, issue with cookies is that there are no port restrictions on them and as such cookies for a given host are shared across all ports on that host.

Furthermore, hosts are allowed to set cookies for domains other than their own; they are allowed to set cookies for

any host they ‘domain match’, a complete description is available in the corresponding RFC, but suffice to say that www.site.domain.com can set cookies for .www.site.domain.com, .site.domain.com, and .domain.com, but not .com.This is because when a browser needs to send cookies they do not do a direct match either, rather they also ‘domain match’ cookies, however in the opposite direction. Any cookies marked as .domain.com will be sent to domain.com, but also to site.domain.com, and news.domain.com and www.news.domain.com, etc, i.e. cookies are sent to all the subdomains of a host. As such if sites were able to set cookies for .com they would be able to set a cookie which is sent to all sites in the .com tree, which could lead to potentially exploitable vulnerabilities. However this problems is not adequately solved for all public registries such as .co.uk in all browsers, and more information can be found in several13 places14.

These ground rules mean that if you are able to XSS a parent domain, you would not be able to access the parent domain’s subdomains’ cookies, but you would be able to set cookies for them (this is useful for the exploitation of certain web vulnerabilities, which is also out of scope). But more interestingly if you were to XSS a subdomain of your target domain, then you would effectively be able to read all the cookies set for the parent domain.

13 http://kuza55.blogspot.com/2008/02/understanding-cookie-security.html14 http://kuza55.blogspot.com/2008/07/some-random-safari-notes.html

This lends an interesting caveat to the recent DNS bug discovered by Dan Kaminsky; the core reason this was considered a serious bug was that “being able to poison random subdomains is not useful”, however given that we know that it XSS-ing a subdomain is often as useful as XSS-ing the actual domain, it is arguable that for the web, the existence of this specific attack above existing knowledge (that it was possible to poison random subdomains) has limited relevance, though the randomized source port patches manage to solve both attacks.

And last of all, protocol restrictions are only applied for access to secure cookies from non-secure protocols, i.e. cookies that are marked secure cannot be accessed from sites contacted via http, only from those contacted through https.

However this option is opt-in on a per-cookie basis and does not apply to the setting of cookies sent over secure channels, i.e. a http site can easily set a cookie that is sent to a https site.

JavaScript document.domainThe document.domain property exposed to JavaScript is designed to allow sites in the same domain tree to be able to communicate, after a mutual agreement has been reached.

The implementation is intended to work like this:If two pages share the same document.domain property, and both are ‘unlocked’.

The document.domain property becomes unlocked by being set to any legal value.

Pages are allowed to set their document.domain property to any portion of their DNS name above their current name, so it is very similar to the domains sites are allowed to set cookies for, e.g. site.domain.com can becomes domain.com but not www.site.domain.com.

In theory this should not add any extra attack surface unless a site allows it, however the implementation of this has been extremely shaky in both IE and Firefox, and as such many innocuous pieces of JavaScript unlock the document.domain property, including portions of the Google Analytics JavaScript code. This means that on many sites, JavaScript can violate the SOP to jump to parent domains simply by setting its own document.domain property to a parent domain, and then jumping across on a page which inadvertently unlocks the document.domain property.

Since this is an annoying process to do by hand, a tool is included with this paper which can be loaded with a set of URLs, and where necessary POST parameters, which automatically load the URLs and attempt to jump across from a subdomain to detect whether a given domain is vulnerable to this; most domains that contain any JavaScript content are expected to be vulnerable.

However, some of these bugs have been fixed in IE8 Beta 2, so finding sites which accidentally unlock document.domain due to bugs may become harder in the future.

Other DNS Trust RelationshipsWhile we understand that DNS maps domains to a specific IP, many people make the mistake of oversimplifying their mental model of DNS as having it resolve to a particular machine, however the fact that DNS resolves domains to an IP (or not) can result in some leeway for exploitation.

Heterogeneous DNS RecordsMany people assume that DNS results are the same across the internet, however there are two specific, and not uncommon, instances this author can think of where this is not the case.

First of all, in the US and possibly other places around the world, it seems fairly common for ISPs and DNS providers to attempt to automatically hijack all DNS records which return with the result of NXDOMAIN.

These attempts have15 often16 been constructed with little or no attempts to the secure the pages before launching them; as such they have had several easy to identify xss bugs that could have potentially allowed adversaries to compromise the security of many web sites due to the way cookies are handled and the document.domain issues described above.

Secondly, when DNS entries for internal and external sites are separated, it is common to find that inside an internal network, intranet.company.com resolves to an IP address, but outside it does not,

15 http://kuza55.blogspot.com/2008/04/do-you-trust-your-dns-operator.html16 http://blog.wired.com/27bstroke6/2008/04/isps-error-page.html

or more frequently, outside the internal network intranet.company.com is covered by the *.company.com address, and it is resolved to the same domain as www.company.com.

This means that outside the internal network, being able to xss www.company.com will let you xss intranet.company.com, however the advantage here is not completely clear as any external user would not have any authentication information for intranet.company.com.

However, many people these days work from laptops, and move from one network to another and will often browse website from other networks, such as form home, using the same computer.

While an analysis of the attacks that are possible when such a user is at home and you can utilise a bug in www.company.com that is rendered on intranet.company.com is outside the scope of this paper, there are several methods to create backdoor payloads by abusing persistent client-side data stores such as the browser cache, or the cookie store, or extract information from the browser cache and password managed, among others.

Ambiguous IP AddressesAnother possibility for domains names is for them to resolve to internal IP addresses for everyone. There are two specific cases of interest, the case there domains resolve to 127.0.0.1 and the case where they resolve to any non-Public IP address.

While the two cases are separate in terms of exploitation, they both result in a similar issue: a domain resolves to an

IP address that is outside of the domain owner’s control. This fact means that the domain owner is relying on that IP address to be non-malicious and secure across all computers and networks.

Early this year Travis Ormandy found that for many domains, localhost.domain.com resolved to 127.0.0.117 due to many DNS administrators forgetting to place the trailing dot that is needed to specify fully qualified domain names (FQDNs) in their nameserver configurations. This was found to affect many domains such as microsoft.com, yahoo.com, ebay.com, etc.

He also highlighted some valid attack vectors. Using the lack of port restrictions described in cookies and later in this paper, he showed that these configurations made it impossible to browser these domains securely from a multi-user environment such as a UNIX machine as any user on that machine could bind a high port on 127.0.0.1.

Furthermore Will Drewry found that the CUPS HTTP daemon that runs locallyon port 631 on many Linux and Mac computers had an XSS flaw in it that could be abused and forced to run in the context of the localhost domains, e.g. localhost.microsoft.com.

It was also noted that xss-able services running on the localhost of a proxy server would provide an adequate exploitation vector for any users of that vulnerable proxy.

17 http://www.securiteam.com/securitynews/5RP0M00N5K.html

The second scenario, where non-public, but non-loopback, addresses are exposed to the internet is considerably harder to exploit as the victim must be on the same network block as a vulnerable service running on the particular IP, however this is not always an insurmountable issue.

A much larger issue that an attacker must resolve is the fact that they do not know what particular service is running on the IP, however as classic Anti-DNS Pinning attacks18 using browsers’ XHR objects have not been fixed, and closely resemble the kind of requests you would be forcing the user to make (namely they would have incorrect domains for that IP and you would only be able to abuse the default host), it is possible for an attacker to use Anti-DNS Pinning attacks to find an XSS vulnerability in the target on-the-fly, however building such a set of tools is clearly outside the scope of this paper.

Flash and Silverlight crossdomain.xmlThe crossdomain.xml policy file pioneered by the Flash plugin allows sites to create trust links whereby Flash (and now Silverlight) files can read data cross-domain if it is allowed by the policy of the target site.

The Silverlight implementation allows only complete trust between domains by only loading the crossdomain.xml file from the document root and does not allow cross-protocol communication, however, like Flash, it does allow trust of wildcard domains such as *.microsoft.com.

18 http://shampoo.antville.org/stories/1548035/

The Flash implementation is more feature-rich and therefore more interesting as it allows not only the ability to specify trust to wildcard domains, but also allows sites served over encrypted connections to trust sites served over plaintext connections by using a policy file that looks like this:

<cross-domain-policy><allow-access-from

domain="*.good.com" secure="false" /></cross-domain-policy>

The part that allows cross-domain communication is the secure="false" attribute. While it is not evident, Flash implicitly assumes this is *.good.com:80, and does not allow

Furthermore, via the LoadPolicyFile function, Flash will load policy files from arbitrary places within the domain, however in Flash Player 10 this must be explicitly allowed by a site in it’s meta-policy file19 in the root of the web server; in recent versions of Flash Player 9, it can merely be disabled via a meta-policy file.When these files are loaded they grant access to only a specific part of the domain, namely the directory they are hosted within, and any directories which are contained within their directory recursively.This functionality is intended to allow sites to expose a certain amount of functionality to other sites without completely compromising their own security, however as they are often used to allow access to public data they are often setup to allow access from all domains.

19 http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_03.html

This is particularly interesting as URL parsing differences between the Flash Player and the web server may result in the ability for the site to be compromised. One such method I discovered in May this year, which Adobe plans to patch in early November, is a directory traversal bug due to unnecessary URL decoding on the part of the Flash player, namely if a policy file is hosted at

http://www.site.com/path/to/policy/file/crossdomain.xml

Then an attacker will be able to request a URL like the following:

http://www.site.com/path/to/policy/file/%3f/..\..\..\..\..\path\from\root.aspx

On an IIS web server to read any page in the domain. Again, an analysis of this vulnerability is outside the scope of this paper.

An astute reader may recognise that these trust boundaries exist irrespective of whether a user is logged into one site or another, this presents some interesting additional opportunities to exploit users when a vulnerability, such as the ability to upload a Flash file, is masked in such a way that it is difficult to exploit any users other than yourself, and example of this was shown by Jeremiah Grossman in his attack against YouTube where he used YouTube’s trust of Google domains to abuse the file upload vulnerability in GMail.20

20 http://jeremiahgrossman.blogspot.com/2008/09/i-used-to-know-what-you-watched-on.html

IE By-Design SOP BypassesInternet Explorer has never fully embraced the Same Origin Policy, and is rather more interested in it’s own ‘Security Zone’ Policy, and while an analysis of that policy is outside the scope of this paper, it should not be discounted when attempting to understand the ultimate impact and usefulness of a vulnerability/PoC exploit.

MSXML2.XMLHTTP.6.0 and related componentsMicrosoft have released many versions of their XMLHTTP component which allowed websites to make HTTP requests back to the originating website, however they have not always, and still do not always enforce the SOP.

Microsoft’s decision to allow access to all the old objects as ActiveX controls means that old objects, such as ‘MSXML2.XMLHTTP.6.0’ (and others) can be accessed.

This object works as a typical XMLHttpRequest object, however it (among others) does not enforce port restrictions, and so it is trivial to jump across from one site to another on the same host, but on different ports.

Further the ‘MSXML2.XMLHTTP.3.0’ is documented21 as allowing access from http to https ports/protocols, however this is not corroborated by the implementations tested, and rather only seems to allows cross-port communications, so your mileage will probably be very limited to old and outdated versions.

21 http://msdn.microsoft.com/en-us/library/ms537505(VS.85).aspx

ActiveX SiteLockMicrosoft have release a SiteLock template for ActiveX components so that developers can more easily lock down a component to their own website, however the mechanisms they provide to do this are not designed to implement the SOP.

While users of the Sitelock template can choose to lock their control to a single domain, there are well documented options available to developers to allow wildcard domains, e.g. *.microsoft.com would allow all microsoft.com subdomains. While this does not allow us to bypass the SOP in the browser, it is a clear illustration of how XSSing a site may get us more than just the site’s cookies, which is particularly useful when reviewing the usefulness of XSS bugs in sites which do not have any applications.

No Port Restrictions on JavaScript, etcOne little known fact is that Microsoft do not consider port restrictions an essential part of the SOP, and as such allow technologies such as JavaScript to bypass it without any trickery. The following trivial HTML illustrates how it is not enforced at all:

<iframe src="http://www.good.com:8080/server.php" onload="alert(window.frames[0].document.body.innerHTML);"> </iframe>

As traditional JavaScript, unlike many of the other components discussed here, has transitive trust, in that once a JavaScript SOP boundary is breached, it is able to assume the origin of the origin it jumped into, and then attempt to make further

jumps from that domain, and so this issue, like the document.domain issue, allows us to abuse this ability in concert with any other possible payloads.

Conclusion IIWhile the examples provided do not allow for a reliable way to arbitrarily bypass the SOP, they are issues that are known to, at the very least, the developers and are often there by design and are even documented and illustrate that the SOP is not the only security consideration we need to apply to XSS bugs since the old mantra of XSS being irrelevant in ‘brochure-ware’ sites being irrelevant is not always true, depending on whether it can be used to leverage access to another important domain.

The EndAs a final conclusion, it is this paper’s author’s hope that you can now see that the web is no longer bound up in a single simple JavaScript-Only implementation of the Same Origin Policy is not the only security consideration we must deal with and any browser add-on that exposes a URL interface must be checked to ensure we fully understand the environment we are dealing with.

Some areas that still need to be explored are add-ons that have not been covered in this paper, such as Silverlight, policies that have not been covered such as IE’s Zone Policy, and any bugs in general. Hack the planet! ;)