Same Origin Policy Weaknesses

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.

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

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

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

<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

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

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

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/

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/

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

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

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

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

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

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

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

Same Origin Policy Weaknesses

by kuza55 on Jul 16, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Same Origin Policy Weaknesses — Document Transcript