http://www.powerofcommunity.net/pastcon_2008.html & http://xcon.xfocus.org/XCon2008/index.html The 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 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 talk 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 talk 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.

1. Same Origin Policy Weaknesses
kuza55 <kuza55@gmail.com>
http://kuza55.blogspot.com/
Abstract
The 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.

2. Same Origin Policy Weaknesses.........................................................................................1
Abstract............................................................................................................................1
The Beginning......................................................................................................................3
An Obvious Attack..............................................................................................................3
Understanding Context........................................................................................................3
Active and Passive Context Components............................................................................4
JavaScript Hijacking Advances...........................................................................................4
Other Components...............................................................................................................5
The HTTP Parser.............................................................................................................5
The CSS Parser................................................................................................................6
Flash VM.........................................................................................................................7
Java Applet VM...............................................................................................................8
Google Gears Web Workers............................................................................................8
Conclusion I.....................................................................................................................9
Part II.................................................................................................................................10
Browser Cookies............................................................................................................10
JavaScript document.domain.........................................................................................11
Other DNS Trust Relationships.....................................................................................12
Heterogeneous DNS Records....................................................................................12
Ambiguous IP Addresses...........................................................................................13
Flash and Silverlight crossdomain.xml..........................................................................14
IE By-Design SOP Bypasses.........................................................................................15
MSXML2.XMLHTTP.6.0 and related components..................................................15
ActiveX SiteLock.......................................................................................................15
No Port Restrictions on JavaScript, etc......................................................................16
Conclusion II..................................................................................................................16
The End..............................................................................................................................16

3. The Beginning is to either look for places where the
origin is not enforced, as many of the
The history behind the name Cross-Site
original Same Origin Policy Bypasses
Scripting is an interesting one that will
did, or to figure out a method of placing
set the stage for understanding how the
your own active content in the same
many parsers present in browsers can be
origin as the application you wanted to
abused to perform XSS attacks. In the
attack as XSS bugs do. (From here we
beginning before JavaScript was
will revert to modern terminology which
implemented, there was no active
labels the original Cross-Site Scripting
content and there was no Same Origin
bugs as Same Origin Policy Bypasses,
Policy, and applications could point the
and refers to JavaScript Injection bugs as
src attributes of html tags wherever they
Cross-Site scripting or XSS bugs.)
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 Understanding Context
what we now call Cross-Site Request When the SOP was being implemented
Forgery attacks, but which were initially in the browser the decision was made
labeled as 'Confused Deputy' attacks. that the HTML context would be used,
The ability to force user actions was rather than the JavaScript context. This
already taking a toll on the security of may seem irrelevant when JavaScript is
the web. being embedded directly onto the page
like so:
With the introduction of JavaScript,
<hmtl>
fundamental changes needed to be made <body>
to add some kind of security to the web, <script>
alert("Hi!");
otherwise JavaScript could actively </script>
interact with content from other origins </body>
</html>
and steal data or perform actions on the
user's behalf. The solution to this
As the context is one and the same, but it
problem came in the form of the Same
makes a marked difference in what can
Origin Policy (SOP). The SOP is
and cannot be exploited when examining
typically best understood in the context
HTML which looks like this:
of JavaScript, where JavaScript is not
allowed to get or set properties from <hmtl>
windows belonging to other origins <body>
<script language="JavaScript"
where an origin is defined as a 3-tuple src="http://www.othersite.com/some.js"
made up of a protocol, a hostname and a ></script>
</body>
port. </html>
The decision meant that to get into the
An Obvious Attack appropriate context inside the JavaScript
The most obvious attack against a policy interpreter you needed to first get into
which says active content can only the right context in the HTML
interact with content from it's own origin interpreter. So while typical XSS bugs

4. are just JavaScript Injection bugs, they There are two specific classes of attacks;
are a really just a subset of HTML code injection and information leakage,
Injection bugs. While the following that are specific to each respective type
piece of PHP code which generates the of component.1
vulnerable JavaScript inside a HTML
container is trivially exploitable as single As such the passive equivalent of XSS
quotes are not escaped: bugs to JavaScript is JavaScript and
JSON Hijacking, whereby an attacker is
<html>
<body>
able to setup a context such that when
<script> code containing sensitive information is
<?php
print "var data =
executed in it, sensitive information can
'".htmlentities($_GET['xss'])."';"; sometimes be extracted.
?>
</script>
</body>
</html>
JavaScript Hijacking
The same cannot be said of the Advances
PHP/JavaScript code alone like so: While XSS has been thoroughly, but not
exhaustively, examined, JavaScript
<?php
print "var data = hijacking has received relatively little
'".htmlentities($_GET['xss'])."';"; attention, however some interesting
?>
work has been done recently to show
This is because we cannot invoke the how changes to the JavaScript parser in
proper context in the HTML interpreter Gecko, namely the support of E4X has
since we cannot use the needed control introduced a new method of extracting
characters to create HTML tags, and we data cross-domain.2 Namely it has been
cannot simply point the JavaScript noted that the new JavaScript parser will
interpreter to the code and have it use to happily parse any valid fully XML
context from which it loaded the code. 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
Active and Passive chosen context.
Context Components XML being ‘executed’ will typically
All of the components inside browsers have no effect as it is simply considered
can be grouped inside one of two an object, though unlike most objects it
categories; active or passive context does not have methods attached to it,
components. The HTML interpreter is an however it does have constructors.
active context component since all Constructors are single statement pieces
HTML that is loaded is loaded in the of JavaScript code wrapped in braces
context of the domain it was loaded like so:
from, as opposed to the JavaScript
interpreter which is a passive component 1
since it inherits the context of the A third type of attack in the form of Confused
Deputy or CSRF attacks exists, but is outside the
context that loaded it. scope of this paper.
2
http://code.google.com/p/doctype/wiki/ArticleE
4XSecurity

5. <name>{get_name();}</name><mail> o The document does not
none</mail>
contain tags such as <?
xml or <!DOCTYPE
As such, if a place where user input is o However <?xml
printed to a page that is valid XML, then support is being
it may be possible to construct braces added
and some accompanying JavaScript code
around some sensitive data like so: However, if these conditions are met
then the attack described can be
<html> executed, though sometimes existing
<body> braces may make exploitation trickier in
Non-JavaScript text
Something completely non- which case it is possible to close one set
parseable - 1 2 3 **** }} of braces then place a semi-colon and
... open a new set. Note braces cannot
{ x = contain any semi-colons inside.
...
User mailbox data
in HTML format
... Other Components
}
</body>
</html> The HTML and JavaScript parsers are
not the only components in web
Then embedding the appropriate URL in browsers, rather they contain many and
a script tag would see the window.x varied components which bring the web
variable populated with the contents of a together. In fact they typically contain
potentially sensitive email. more parsers and components than this
paper can cover and this author knows
However, the chance of exploitation about, however an examination of the
remains low as the prerequisites are following additional components can
rather high: lead to some insights into what kind of
 The vulnerable page must have new vulnerabilities new parsers and
sensitive content implementations of the Same Origin
 The attacker must be able to Policy may bring:
inject braces around the sensitive  HTTP Parser
content in such a way that the  CSS Parser
sensitive content it a valid XML  Flash VM
block encapsulated in some  Java Applet VM
JavaScript statement  Silverlight VM
 The document must be valid  Google Gears Web Workers
XML, which means that
o The document contains The HTTP Parser
no unclosed tags such as The lowest level parser we deal with is
<br> the HTTP parser, and understanding of
o All the attributes in the this fundamental part of the browser has
document are quoted lead to Header Injection and HTTP
using single (‘) or double Response Splitting attacks as well as
quotes (") typical XSS attacks, where the attack

6. jumps from HTTP headers to the HTML The CSS Parser
parser. The CSS parser is not usually considered
active content, as it resides in a similar
The HTTP Parser is invoked from many realm to HTML where it can influence
different contexts, including HTML, the page, sometimes conditionally, but
JavaScript, CSS, etc. When it loads cannot really act upon it, but can invoke
content it loads it in the only sensible active content (in the form of JavaScript,
way possible; it loads it in the context usually). This means that it is a possible
from which it receives it rather than the intermediary between a filtered HTML
context of the invoking script. As such it Injection and an arbitrary script
is considered to be an active context execution exploit, yet like JavaScript it
component as it does not inherit it’s is a passive context component that must
context. And therefore the attacks be embedded within a HTML container.
against it work by trying to inject active
content into the vulnerable context. And like JavaScript, it too can leak
information, however due to how it
One common theme for the rest of this parses data no significant uses for this
paper can be found in papers such as have been determined other than
‘The Extended HTML Form attack’3, remotely determining what the style of a
‘Inter-Protocol Communication’4, etc, 3rd party website looks like; phear.
where the authors have noted that the
HTTP parser in browsers can be pointed However, this ability to determine what
at any text-based protocol, and other styles exist have allowed researchers and
than attempting to not interpret data attackers alike to detect a user’s ability
from some well known non-http ports, to access a stylesheet at a given URL.
many still do not confirm that what they This has allowed us to do things like
are receiving is HTTP before processing remotely determining which Firefox
it. extensions a user has installed using only
CSS5 and determining whether a victim
The recent advances in browser is authenticated as an administrative user
protections involve Firefox practically to a website before launching a noisy
solving the problem in Firefox 2.0 attack6.
whereby they have started searching for
the string “http” (case-insensitively) in Recently however, Eduardo
the first 8 bytes. “sirdarckcat” Vela and Stefano “WiSec”
Di Paola have both independently
However no other browsers do this. The discovered that CSS can be used for
only protection in most browsers is the some limited active scripting, and that
ports list that the http protocol handler CSS can be used to read parts of the
will not talk to in [3]. page.7 Again, as this has been covered
5
http://kuza55.blogspot.com/2007/10/detecting-
firefox-extension-without.html
6
http://sirdarckcat.blogspot.com/2007/11/inside-
3
http://resources.enablesecurity.com/resources/t history-of-hacking-rsnake-for.html
7
he%20extended%20html%20form%20attack http://www.thespanner.co.uk/wp-
%20revisited.pdf content/uploads/2008/10/the_sexy_assassin2ppt.
4
http://www.bindshell.net/papers/ipc zip

7. elsewhere the content will not be  When invoked, the parser does
needlessly reproduced; suffice to say not check the Content-Type
that injecting CSS can be used to extract header of the HTTP response,
data from the page even when JavaScript nor does it check the file
is disabled. extension of the file
 The only check performed to
ascertain the file is a proper swf
Flash VM file is to check the first 3 bytes
The Flash VM is an interesting for the letters CWS or FWS
component in that it is in itself an active  Flash bytecode can contain
content and active context component, ‘jumps’
and yet shares the trait of being able to  The Flash VM which is
somewhat communicate with the hosting responsible for parsing
page, yet this communication is one- ActionScript 2 bytecode works
sided, and so information leaks from on a similar model to CPUs, in
Flash are rare. that it does not validation of the
code, but merely executes it from
However information leaks are possible start to finish
when code is written that assumes it can  The Flash VM contains bytecode
only comminucate with a single origin: for a ‘stop’ instruction
getURL ('javascript:func("'+sensitive_data+'")'); Due to these facts, it is in some cases
possible to smuggle a swf object into the
An attacker would be able to embed context of a 3rd party site if the attacker
such code on their page and then create a can control the first 3 bytes of the
function by the name of func which response, and also controls the point at
captured the sensitive data that was which the Flash VM starts parsing
retrieved from the vulnerable instructions, even if it is only to insert a
application’s domain. jump to a later section of flash code.
And while there has been significant There are two somewhat standard
work related to the examination of XSS- scenarios where this knowledge of the
style attacks against the ActionScript Flash VM leads to exploits in the
portion of Flash applications8, much like following situation:
DOM-Based XSS9, there has been no  When hosting user supplied files,
analysis of the Flash bytecode parser and such as text files, where specific
VM in the context of SOP violations. filtering to stop Flash files being
uploaded as other file types does
While an exhaustive examination of the not exist
Flash SWF file parser will not be  JavaScript callback functions
examined, the following things should where an attacker is able to
be noted: control the beginning of the
string, but cannot use standard
8 XSS techniques due to HTTP
http://www.wisec.it/sectou.php?
id=464dd35c8c5ad Content-Type headers or filtering
9
http://www.webappsec.org/projects/articles/071
105.shtml

8. Once a request has been constructed so so information leaks of this nature will
that it can be processed as a proper swf not be examined here.
file, it merely needs to be embedded in a
html object like so: This issue has been discussed in
several10 places11 where researchers have
<html> conducted examinations of the JAR
<body> format and found that JAR files are
<EMBED src="http://site.com/file.txt" essentially read from the end of a file,
TYPE="application/x-shockwave-flash"
allownetworking="always"
rather than the beginning, and as such a
allowscriptaccess="always"></EMBED> JAR file can be both a valid image file
</body> (or any other file where the file is read
</html> from the start and to which extraneous
content can be appended) and a valid
And it will be executed in the context of JAR file.
the site it is being hosted on.
As noted by the researchers who have
A simple ActionScript payload may look disclosed this, this makes it much easier
something like this: to attack file upload functionality as
images are often accepted as file
class Attack { uploads, and no checking for JAR files is
static function main(mc) { usually done.
var req:LoadVars = new LoadVars();
req.x = "y";
JAR Files can then access the site using
req.load("http:// site.com/sensitive.php");
a user’s cookies, as others have already
req.onData = function(src:String) { released PoC code, this presentation
req.x = src; does not address this topic in depth.
req.send("http://www.evil.com/capture.
php", "_self", "POST"); Google Gears Web Workers
};
} Google Gears does not have it’s own
} JavaScript interpreter, but rather utilizes
the browsers’ native JavaScript
Java Applet VM interpreter. It is invoked by Google
The Java Applet VM is, in terms of what Gears only in one module; the Worker
kinds of attacks it can be utilized for, Pool module, which developers can use
almost identical to the Flash VM, though to create separate workers which execute
the Java VM gains both the context JavaScript code outside the context of
within which it was embedded and from the document and are given a simple
which it is hosted. This means that mechanism to message back and forth
information leaks such as those through between the worker pool and the
JavaScript are possible if a valid workers themselves. Workers can be
response, containing sensitive loaded both from a string of JavaScript,
information and the appropriate Java which is irrelevant to us, since it merely
code can be constructed; however due to 10
http://www.gnucitizen.org/blog/java-jar-
the SOP, being able to execute code in a attacks-and-features/
context will lead to that information leak 11
http://pseudo-flaw.net/content/web-
anyway, and is considerably easier, and browsers/corrupted-jars/

9. resembles a different kind of JavaScript achieve AJAX results return data in a
eval() call. very similar format, it is often possible
to conduct an XSS attack via unescaped
However the braces like so:
workerPool.createWorkerFromUrl()
function allows us to, as the function <name>{{eval('
var wp =
name say, create a Worker from a URL,
google.gears.workerPool;
and in this case it is an active context wp.allowCrossOrigin();
component (with the caveat that the
script must call AllowCrossOrigin() to var request =
be given the security context). google.gears.factory
.create("beta.httprequest");
request.open("GET" ,
This is particularly interesting since this "/sensitive_data");
means that a browsers’ native JavaScript request.send("");
interpreter can be invoked as an active
context component. request.onreadystatechange =
function() {if
For most browsers this simply means (request.readyState == 4)
{ wp.sendMessage(
that injections into dynamically request.responseText, 0);
generated JavaScript files (anywhere in }};')}}</name><mail>none</mail>
the file) are trivially exploitable, even
when they are served with Content-Type which would send the worker pool with
headers which make them non- the id 0 the response. Additional damage
renderable. can be done with Google Gears as well,
since these workers can remain active
Also, given JavaScript’s flexibility it until the browser closes and can also
allows GIFAR-like attacks where a file send messages to and from an attacker
is created that is both a valid image and controlled domain after the original page
a valid JavaScript file. The GIF file which loaded it has been closed. This
format was found to be particularly easy has been abused to build a Worker-based
to work with for this attack. proxy that does not die until the browser
is closed.
However, on Firefox, it presents a whole
new problem when combined with the Also, this same functionality is intended
recent addition of E4X. As mentioned to be included in Firefox 3.1 Beta 2 and
before the following piece of code is release versions, so this could become a
valid JavaScript: valid way of attacking standard Firefox
users in the near future.12
<name>{get_name();}</name><mail>
none</mail>
And it executes the get_name function.
Conclusion I
As we can see; if we classify how
Given that braces ({}) are not often components determine the security
considered meta characters it is rare for context to be used in their
them to be escaped, further many 12
http://developer.mozilla.org/web-
applications which use actual XML to tech/2008/09/04/web-workers-part-1/

10. implementation of the SOP, we can, by The components that have been
simply examining the parser, understand identified are:
the additional risks such a component • Browser Cookies
will pose without needing to inspect any • JavaScript document.domain
of the functions themselves. • Other DNS Trust Relationships
• Flash and Silverlight
This is not to say that all security issues crossdomain.xml
can be seen this way, but simply the • IE By Design SOP Bypasses
SOP design issues the component o MSXML2.XMLHTTP.6.
introduces which web developers need 0 and related components
to work around can be envisioned o ActiveX SiteLock
without needing to repeat the discovery
o No port restrictions on
of an attack on a new type of
JavaScript
component, as has been done by many
researches regarding many browser-
While this is a relatively short list, this is
based components.
a list of issues that are known to the
creators of the objects which have
As such these discoveries may be treated
simply gone unfixed and as such
as routine and expected rather than
potentially allow us to conduct attacks
something that catches anyone
from different ports and different hosts
unexpectedly.
and sometimes different protocols.
Part II Browser Cookies
As mentioned in the abstract, this Browser cookies have a unique place in
paper’s view is that the biggest issue browser security in that they are one of
with the SOP is that it, unlike restrictions the most closely guarded objects of a
such as CPU rings, need to be website, as they often contain enough
specifically implemented in each piece details to authenticate as a given user,
of browser code which deals with URLs. however they were never designed with
security in mind, and as such they leave
The first part of this paper investigated a few large holes that are often
how the design decision related to how unaccounted for.
security context is established can show
us how they impact security, this portion The first, most obvious, issue with
of the paper will attempt to catalogue as cookies is that there are no port
many currently known and unknown restrictions on them and as such cookies
methods of bypassing the SOP by for a given host are shared across all
utilizing different components as ports on that host.
possible to illustrate this further with
examples of components that have Furthermore, hosts are allowed to set
simply ignored the most widely accepted cookies for domains other than their
security policy on the web for various own; they are allowed to set cookies for
reasons. any host they ‘domain match’, a
complete description is available in the
corresponding RFC, but suffice to say

11. that www.site.domain.com can set useful”, however given that we know
cookies for .www.site.domain.com, that it XSS-ing a subdomain is often as
.site.domain.com, and .domain.com, but useful as XSS-ing the actual domain, it
not .com. is arguable that for the web, the
This is because when a browser needs to existence of this specific attack above
send cookies they do not do a direct existing knowledge (that it was possible
match either, rather they also ‘domain to poison random subdomains) has
match’ cookies, however in the opposite limited relevance, though the
direction. Any cookies marked as randomized source port patches manage
.domain.com will be sent to to solve both attacks.
domain.com, but also to
site.domain.com, and news.domain.com And last of all, protocol restrictions are
and www.news.domain.com, etc, i.e. only applied for access to secure cookies
cookies are sent to all the subdomains of from non-secure protocols, i.e. cookies
a host. As such if sites were able to set that are marked secure cannot be
cookies for .com they would be able to accessed from sites contacted via http,
set a cookie which is sent to all sites in only from those contacted through https.
the .com tree, which could lead to
potentially exploitable vulnerabilities. However this option is opt-in on a per-
However this problems is not adequately cookie basis and does not apply to the
solved for all public registries such as setting of cookies sent over secure
.co.uk in all browsers, and more channels, i.e. a http site can easily set a
information can be found in several13 cookie that is sent to a https site.
places14.
These ground rules mean that if you are JavaScript document.domain
able to XSS a parent domain, you would The document.domain property exposed
not be able to access the parent domain’s to JavaScript is designed to allow sites in
subdomains’ cookies, but you would be the same domain tree to be able to
able to set cookies for them (this is communicate, after a mutual agreement
useful for the exploitation of certain web has been reached.
vulnerabilities, which is also out of
scope). But more interestingly if you The implementation is intended to work
were to XSS a subdomain of your target like this:
domain, then you would effectively be If two pages share the same
able to read all the cookies set for the document.domain property, and both are
parent domain. ‘unlocked’.
This lends an interesting caveat to the The document.domain property becomes
recent DNS bug discovered by Dan unlocked by being set to any legal value.
Kaminsky; the core reason this was
considered a serious bug was that “being Pages are allowed to set their
able to poison random subdomains is not document.domain property to any
13
http://kuza55.blogspot.com/2008/02/understan portion of their DNS name above their
ding-cookie-security.html current name, so it is very similar to the
14
http://kuza55.blogspot.com/2008/07/some- domains sites are allowed to set cookies
random-safari-notes.html

12. for, e.g. site.domain.com can becomes IP (or not) can result in some leeway for
domain.com but not exploitation.
www.site.domain.com.
Heterogeneous DNS Records
In theory this should not add any extra Many people assume that DNS results
attack surface unless a site allows it, are the same across the internet, however
however the implementation of this has there are two specific, and not
been extremely shaky in both IE and uncommon, instances this author can
Firefox, and as such many innocuous think of where this is not the case.
pieces of JavaScript unlock the
document.domain property, including First of all, in the US and possibly other
portions of the Google Analytics places around the world, it seems fairly
JavaScript code. This means that on common for ISPs and DNS providers to
many sites, JavaScript can violate the attempt to automatically hijack all DNS
SOP to jump to parent domains simply records which return with the result of
by setting its own document.domain NXDOMAIN.
property to a parent domain, and then
jumping across on a page which These attempts have15 often16 been
inadvertently unlocks the constructed with little or no attempts to
document.domain property. the secure the pages before launching
them; as such they have had several easy
Since this is an annoying process to do to identify xss bugs that could have
by hand, a tool is included with this potentially allowed adversaries to
paper which can be loaded with a set of compromise the security of many web
URLs, and where necessary POST sites due to the way cookies are handled
parameters, which automatically load the and the document.domain issues
URLs and attempt to jump across from a described above.
subdomain to detect whether a given
domain is vulnerable to this; most Secondly, when DNS entries for internal
domains that contain any JavaScript and external sites are separated, it is
content are expected to be vulnerable. common to find that inside an internal
network, intranet.company.com resolves
However, some of these bugs have been to an IP address, but outside it does not,
fixed in IE8 Beta 2, so finding sites or more frequently, outside the internal
which accidentally unlock network intranet.company.com is
document.domain due to bugs may covered by the *.company.com address,
become harder in the future. and it is resolved to the same domain as
www.company.com.
Other DNS Trust
Relationships This means that outside the internal
While we understand that DNS maps network, being able to xss
domains to a specific IP, many people www.company.com will let you xss
make the mistake of oversimplifying
their mental model of DNS as having it 15
http://kuza55.blogspot.com/2008/04/do-you-
resolve to a particular machine, however trust-your-dns-operator.html
16
the fact that DNS resolves domains to an http://blog.wired.com/27bstroke6/2008/04/isps
-error-page.html

13. intranet.company.com, however the 127.0.0.117 due to many DNS
advantage here is not completely clear as administrators forgetting to place the
any external user would not have any trailing dot that is needed to specify fully
authentication information for qualified domain names (FQDNs) in
intranet.company.com. their nameserver configurations. This
was found to affect many domains such
However, many people these days work as microsoft.com, yahoo.com, ebay.com,
from laptops, and move from one etc.
network to another and will often browse
website from other networks, such as He also highlighted some valid attack
form home, using the same computer. vectors. Using the lack of port
restrictions described in cookies and
While an analysis of the attacks that are later in this paper, he showed that these
possible when such a user is at home and configurations made it impossible to
you can utilise a bug in browser these domains securely from a
www.company.com that is rendered on multi-user environment such as a UNIX
intranet.company.com is outside the machine as any user on that machine
scope of this paper, there are several could bind a high port on 127.0.0.1.
methods to create backdoor payloads by
abusing persistent client-side data stores Furthermore Will Drewry found that the
such as the browser cache, or the cookie CUPS HTTP daemon that runs locallyon
store, or extract information from the port 631 on many Linux and Mac
browser cache and password managed, computers had an XSS flaw in it that
among others. could be abused and forced to run in the
context of the localhost domains, e.g.
Ambiguous IP Addresses localhost.microsoft.com.
Another possibility for domains names is
for them to resolve to internal IP It was also noted that xss-able services
addresses for everyone. There are two running on the localhost of a proxy
specific cases of interest, the case there server would provide an adequate
domains resolve to 127.0.0.1 and the exploitation vector for any users of that
case where they resolve to any non- vulnerable proxy.
Public IP address.
The second scenario, where non-public,
While the two cases are separate in but non-loopback, addresses are exposed
terms of exploitation, they both result in to the internet is considerably harder to
a similar issue: a domain resolves to an exploit as the victim must be on the
IP address that is outside of the domain same network block as a vulnerable
owner’s control. This fact means that the service running on the particular IP,
domain owner is relying on that IP however this is not always an
address to be non-malicious and secure insurmountable issue.
across all computers and networks.
A much larger issue that an attacker
Early this year Travis Ormandy found must resolve is the fact that they do not
that for many domains,
localhost.domain.com resolved to 17
http://www.securiteam.com/securitynews/5RP
0M00N5K.html

14. know what particular service is running <allow-access-from
domain="*.good.com"
on the IP, however as classic Anti-DNS
secure="false" />
Pinning attacks18 using browsers’ XHR </cross-domain-policy>
objects have not been fixed, and closely
resemble the kind of requests you would The part that allows cross-domain
be forcing the user to make (namely they communication is the secure="false"
would have incorrect domains for that IP attribute. While it is not evident, Flash
and you would only be able to abuse the implicitly assumes this is
default host), it is possible for an *.good.com:80, and does not allow
attacker to use Anti-DNS Pinning
attacks to find an XSS vulnerability in Furthermore, via the LoadPolicyFile
the target on-the-fly, however building function, Flash will load policy files
such a set of tools is clearly outside the from arbitrary places within the domain,
scope of this paper. 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;
Flash and Silverlight in recent versions of Flash Player 9, it
crossdomain.xml can merely be disabled via a meta-policy
The crossdomain.xml policy file file.
pioneered by the Flash plugin allows When these files are loaded they grant
sites to create trust links whereby Flash access to only a specific part of the
(and now Silverlight) files can read data domain, namely the directory they are
cross-domain if it is allowed by the hosted within, and any directories which
policy of the target site. are contained within their directory
recursively.
The Silverlight implementation allows This functionality is intended to allow
only complete trust between domains by sites to expose a certain amount of
only loading the crossdomain.xml file functionality to other sites without
from the document root and does not completely compromising their own
allow cross-protocol communication, security, however as they are often used
however, like Flash, it does allow trust to allow access to public data they are
of wildcard domains such as often setup to allow access from all
*.microsoft.com. domains.
The Flash implementation is more This is particularly interesting as URL
feature-rich and therefore more parsing differences between the Flash
interesting as it allows not only the Player and the web server may result in
ability to specify trust to wildcard the ability for the site to be
domains, but also allows sites served compromised. One such method I
over encrypted connections to trust sites discovered in May this year, which
served over plaintext connections by Adobe plans to patch in early November,
using a policy file that looks like this: is a directory traversal bug due to
unnecessary URL decoding on the part
<cross-domain-policy>
19
http://www.adobe.com/devnet/flashplayer/artic
18
http://shampoo.antville.org/stories/1548035/ les/fplayer9_security_03.html

15. of the Flash player, namely if a policy MSXML2.XMLHTTP.6.0 and
file is hosted at related components
http://www.site.com/path/to/poli
Microsoft have released many versions
cy/file/crossdomain.xml of their XMLHTTP component which
allowed websites to make HTTP
Then an attacker will be able to request a requests back to the originating website,
URL like the following: however they have not always, and still
do not always enforce the SOP.
http://www.site.com/path/to/poli
cy/file/%3f/..........path Microsoft’s decision to allow access to
fromroot.aspx all the old objects as ActiveX controls
means that old objects, such as
On an IIS web server to read any page in ‘MSXML2.XMLHTTP.6.0’ (and others)
the domain. Again, an analysis of this can be accessed.
vulnerability is outside the scope of this
paper. This object works as a typical
XMLHttpRequest object, however it
An astute reader may recognise that (among others) does not enforce port
these trust boundaries exist irrespective restrictions, and so it is trivial to jump
of whether a user is logged into one site across from one site to another on the
or another, this presents some interesting same host, but on different ports.
additional opportunities to exploit users
when a vulnerability, such as the ability Further the ‘MSXML2.XMLHTTP.3.0’
to upload a Flash file, is masked in such is documented21 as allowing access from
a way that it is difficult to exploit any http to https ports/protocols, however
users other than yourself, and example this is not corroborated by the
of this was shown by Jeremiah implementations tested, and rather only
Grossman in his attack against YouTube seems to allows cross-port
where he used YouTube’s trust of communications, so your mileage will
Google domains to abuse the file upload probably be very limited to old and
vulnerability in GMail.20 outdated versions.
IE By-Design SOP Bypasses ActiveX SiteLock
Internet Explorer has never fully Microsoft have release a SiteLock
embraced the Same Origin Policy, and is template for ActiveX components so that
rather more interested in it’s own developers can more easily lock down a
‘Security Zone’ Policy, and while an component to their own website,
analysis of that policy is outside the however the mechanisms they provide to
scope of this paper, it should not be do this are not designed to implement
discounted when attempting to the SOP.
understand the ultimate impact and
usefulness of a vulnerability/PoC While users of the Sitelock template can
exploit. choose to lock their control to a single
domain, there are well documented
20 21
http://jeremiahgrossman.blogspot.com/2008/09 http://msdn.microsoft.com/en-
/i-used-to-know-what-you-watched-on.html us/library/ms537505(VS.85).aspx

16. options available to developers to allow that the SOP is not the only security
wildcard domains, e.g. *.microsoft.com consideration we need to apply to XSS
would allow all microsoft.com bugs since the old mantra of XSS being
subdomains. While this does not allow irrelevant in ‘brochure-ware’ sites being
us to bypass the SOP in the browser, it is irrelevant is not always true, depending
a clear illustration of how XSSing a site on whether it can be used to leverage
may get us more than just the site’s access to another important domain.
cookies, which is particularly useful
when reviewing the usefulness of XSS
bugs in sites which do not have any The End
applications. As a final conclusion, it is this paper’s
author’s hope that you can now see that
No Port Restrictions on
the web is no longer bound up in a single
JavaScript, etc simple JavaScript-Only implementation
One little known fact is that Microsoft of the Same Origin Policy is not the only
do not consider port restrictions an security consideration we must deal with
essential part of the SOP, and as such and any browser add-on that exposes a
allow technologies such as JavaScript to URL interface must be checked to
bypass it without any trickery. The ensure we fully understand the
following trivial HTML illustrates how environment we are dealing with.
it is not enforced at all:
Some areas that still need to be explored
<iframe
are add-ons that have not been covered
src="http://www.good.com:8080/se
rver.php" in this paper, such as Silverlight, policies
onload="alert(window.frames[0].d that have not been covered such as IE’s
ocument.body.innerHTML);"> Zone Policy, and any bugs in general.
</iframe> Hack the planet! ;)
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 II
While 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