1391909 - Same-origin security on different contexts

Status: RESOLVED INVALID

(Core :: DOM: Security, defect)

Description

[sworddragon2]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170616154447

Steps to reproduce:

I'm testing for a specific issue and marking this ticket as INVALID until I'm finished.

Comment 1

[sworddragon2]

Attachment: test_internet.jsonp

Comment 2

[sworddragon2]

Attachment: testcase.html

Comment 3

[sworddragon2]

Attachment: test_file.jsonp

Comment 4

[sworddragon2]

Attachment: test_localhost.jsonp

Comment 5

[sworddragon2]

Using the script tag is normally not affected by the same-origin policy in the same way as other methods are restricted by it (like XMLHttpRequest) and mainly I wanted to test if higher contexts (sites from the internet (referenced in this report as internet context)) can access lower contexts (localhost (referenced in this report as localhost context) and file protocol (referenced in this report as file context)) and if there are differences if the same is done from a sandboxed iframe with only allow-scripts which results that it is basically always a foreign origin.

For the preparation (based on a Linux system - it should be possible to adjust it to work on Windows too) testcase.html, test_file.jsonp and test_localhost.jsonp from the attachments need to be downloaded and saved into /var/tmp under the same names. A local webserver needs to be started with /var/tmp as the root directory for example by executing in this directory "python3 -m http.server 80".


On step 1 I'm opening https://bug1391909.bmoattachments.org/attachment.cgi?id=8899066 (testcase.html) in Firefox, disabling temporary mixed content blocking (with the padlock symbol) and making a look at the web console. I get:

"Stole data for https://bug1391909.bmoattachments.org/attachment.cgi?id=8899064 from unsandboxed context:" Object { data: "_secret_password_" }
"Stole data for http://localhost/test_localhost.jsonp from unsandboxed context:" Object { data: "_secret_password_" }
Error loading file:///var/tmp/test_file.jsonp from unsandboxed context
"Stole data for https://bug1391909.bmoattachments.org/attachment.cgi?id=8899064 from sandboxed context:" Object { data: "_secret_password_" }
"Stole data for http://localhost/test_localhost.jsonp from sandboxed context:" Object { data: "_secret_password_" }
Error loading file:///var/tmp/test_file.jsonp from sandboxed context

The conclusion is that script tags residing at the internet context were:
1. Able to fetch data from the internet context, no matter if sandboxed or not.
2. Able to fetch data from the localhost context, no matter if sandboxed or not.
3. Unable to fetch data from the file context, no matter if sandboxed or not.

So there seems to be an origin restriction that prevents internet sites to access the users filesystem at all (is this based on a specification?). That internet sites can be accessed without problem seems here to be fine too but [*1]-> isn't it a bit dangerous that if the user opens a website from the internet that it is able to access files on the local webserver (for example to guess common jsonp filenames to try to steal their content)?


On step 2 I'm opening http://localhost/testcase.html in Firefox and making a look at the web console. I get:

"Stole data for https://bug1391909.bmoattachments.org/attachment.cgi?id=8899064 from unsandboxed context:" Object { data: "_secret_password_" }
"Stole data for http://localhost/test_localhost.jsonp from unsandboxed context:" Object { data: "_secret_password_" }
Error loading file:///var/tmp/test_file.jsonp from unsandboxed context
"Stole data for https://bug1391909.bmoattachments.org/attachment.cgi?id=8899064 from sandboxed context:" Object { data: "_secret_password_" }
"Stole data for http://localhost/test_localhost.jsonp from sandboxed context:" Object { data: "_secret_password_" }
Error loading file:///var/tmp/test_file.jsonp from sandboxed context

The conclusion is that script tags residing at the localhost context were:
1. Able to fetch data from the internet context, no matter if sandboxed or not.
2. Able to fetch data from the localhost context, no matter if sandboxed or not.
3. Unable to fetch data from the file context, no matter if sandboxed or not.

Basically the same from the last test happened. localhost sites are prevented too to access the filesystem and that they are able to access the internet seems to be fine here too. That localhost sites can access itself (even from a sandbox) seems fine but based on the previous test [*2]-> if the access from [*1] would have been prevented I think we should see here that localhost sites would still be able to access itself from an unsandboxed script tag but not anymore from a sandboxed script tag.


On step 3 I'm opening file:///var/tmp/testcase.html in Firefox and making a look at the web console. I get:

"Stole data for https://bug1391909.bmoattachments.org/attachment.cgi?id=8899064 from unsandboxed context:" Object { data: "_secret_password_" }
"Stole data for http://localhost/test_localhost.jsonp from unsandboxed context:" Object { data: "_secret_password_" }
Stole data for file:///var/tmp/test_file.jsonp from unsandboxed context: Object { data: "_secret_password_" }
"Stole data for https://bug1391909.bmoattachments.org/attachment.cgi?id=8899064 from sandboxed context:" Object { data: "_secret_password_" }
"Stole data for http://localhost/test_localhost.jsonp from sandboxed context:" Object { data: "_secret_password_" }
Error loading file:///var/tmp/test_file.jsonp from sandboxed context

The conclusion is that script tags residing at the file context were:
1. Able to fetch data from the internet context, no matter if sandboxed or not.
2. Able to fetch data from the localhost context, no matter if sandboxed or not.
3. Able to fetch data from the file context but only if not sandboxed.

That sites on the file protocol are able to access sites on localhost and the internet seems to be fine here. As far as I know how restrictive unsandboxed file access is depends on the browser and if I'm not wrong Firefox allows access to files on the same directory level or any below while Google Chrome is here even more restrictive and would possibly fail so this looks fine too. And that access to the filesystem from a sandboxed script tag does fail seems to be correct too as it should be treated as any site from the internet like a foreign origin and step 1 figured already out that access is then denied.



All this leaves now 2 questions:

1. Should access from internet sites to local addresses (like localhost) be denied to increase the security or would doing this have any downsides? If there would be any would an option make sense?
2. While figuring all this information out I could not find them on the internet but I remember to have seen them somewhere more or less in the past. On looking at https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy it seems to be also not documented there (or I'm overlooking it). Are these specific restrictions documented somewhere at developer.mozilla.org or need/should they eventually to be added there?

Comment 6

[Daniel Veditz [:dveditz]]

(In reply to sworddragon2 from comment #5)
> The conclusion is that script tags residing at the internet context were:
> 1. Able to fetch data from the internet context, no matter if sandboxed or not.
> 2. Able to fetch data from the localhost context, no matter if sandboxed or not.

<script> comes from the primordial web, doesn't follow the same-origin policy

> 3. Unable to fetch data from the file context, no matter if sandboxed or not.

file:/// is never accessible from the web

> [*1]-> isn't it a bit dangerous that if the user opens a website from the
> internet that it is able to access files on the local webserver (for example
> to guess common jsonp filenames to try to steal their content)?

Yes, it is. The user with a browser blows a hole in your firewall. Hard to define your "intranet", but as long as people are using IPv4 we have thought about using known reserved addresses like RFC 1918 and localhost. See bug 354493, and the W3 Web Application Security Working Group has talked about standardizing it (without much progress).

> The conclusion is that script tags residing at the localhost context were:
> 1. Able to fetch data from the internet context, no matter if sandboxed or not.
> 2. Able to fetch data from the localhost context, no matter if sandboxed or not.

<script> still doesn't care about same-origin

> 3. Unable to fetch data from the file context, no matter if sandboxed or not.

"web" content (even on localhost) can't access file:/// urls

> The conclusion is that script tags residing at the file context were:
> 1. Able to fetch data from the internet context, no matter if sandboxed or not.
> 2. Able to fetch data from the localhost context, no matter if sandboxed or not.

<script> still doesn't care about same-origin policy

> 3. Able to fetch data from the file context but only if not sandboxed.

file:/// behavior is completely unspecified and each browser is different. IE blocks scripts on local files, but if you allow them then it can load everything. Chrome treats all file: urls as having a unique origin, and Firefox allows a file to read files in the same directory or a subdirectory (for historical reasons, but we're considering changing to match chrome).

However, when you put it in a sandbox then it gets a "unique origin". It's no longer considered a file:/// url so it can't read other file:/// urls. At least on Firefox.

> 1. Should access from internet sites to local addresses (like localhost) be
> denied to increase the security or would doing this have any downsides? If
> there would be any would an option make sense?

It would increase security which is why we tried to implement bug 354493, and it also breaks some content. Since the death of plugins many services have switched to running a local webserver on localhost and rely on their web pages being able to reference URLs to it. Dropbox is one, for example.

It's also hard to define "local" addresses. localhost is pretty obvious, but for security you really want to block your entire intranet so printers and routers and other "Internet of Things" devices with poor security can't be targets. In an IPv4 world the rfc1918 addresses are an obvious solution, but incomplete in an enterprise environment and useless for IPv6.

> https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy it
> seems to be also not documented there (or I'm overlooking it). Are these
> specific restrictions documented somewhere at developer.mozilla.org or
> need/should they eventually to be added there?

<script>'s behavior is documented with <script>, and the file:/// restrictions are something different from the same-origin policy (since you can't link <img> or other resources that the same-origin policy doesn't apply to).

This report seems to be documenting known behavior, not a bug. Probably would have been better as a post on the security or platform newsgroups/mailing lists.