Closed Bug 885733 Opened 11 years ago Closed 11 years ago

JavaScript getting executed in address bar

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Version:
21 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: shinto143, Unassigned)

References

Details

Attachments

(1 file)

Proof of concept
242.78 KB, application/octet-stream
Details
Attached file Proof of concept — 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

Step 1: Enter javascript:alert("XSS") in the address bar of the browser and press enter. It was observed that the self reflected popup is not coming in Firefox. 

Step 2: Enter the following script in the address bar of the browser and press enter: data:html;base64,PGh0bWw+PHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw+ 

(It was observed that the script is getting executed in the browser directly from address bar and XSS popup is coming in the browser)


Actual results:

While entering a base 64 encoded JavaScript in address bar of the browser it is getting rendered. (Selef reflected XSS will happen in this case) 


Expected results:

It shouldn't get executed even if the script is encoded in any ways. This will prevent Firefox from executing any self reflected script.
Severity: normal → major
Component: Untriaged → Security
Please let me know if you need any additional clarification.
What privileges does the data: URI have? If it has the privileges of the prior page that was loaded in the browser, then I agree we should prevent this the same way we prevent javascript: URIs. But if this merely loads a new page with no privileges, then I don't think that's a problem.

Jesse, what's a good rating for this/does it need to remain hidden?
Blocks: 656433
It will not load in a new page. This has the privileges of the prior page that was loaded in the browser. 

I have hyper-linked my blog with the same encoded javascript: 
http://friends105.blogspot.in/2009/01/friends-for-ever.html (Please click on the blog content to see the effect of it). 

I think you should give e the same priority given for Javascript: URLs.
Flags: needinfo?(jruderman)
(In reply to Shinto K Anto from comment #3)
> It will not load in a new page. This has the privileges of the prior page
> that was loaded in the browser. 

How are you determining this? I can't reproduce that. We explicitly load URLs entered in the URL bar in a new context that does not inherit the privileges of the existing page, and indeed when I load e.g. data:text/html,<html><script>alert(document.domain)</script></html> or data:text/html,<html><script>alert(document.cookie)</script></html> in the location bar while on this page, the no data from the existing domain (bugzilla.mozilla.org) is revealed.

(The reason javascript:alert() doesn't work but the data: URI version does is that javascript: links run against a context with no DOM, so "alert" is undefined and the load fails. javascript:1+1 still works fine, and similarly creates a new context that does not inherit the previous page's privileges.)

This is different than the case of links on a web page linking to a data: URI (comment 3), which is covered by bug 255107.
What I tried to convince here was, If you are blocking Javascript:alert() in the address bar of the browser, you should also be blocking the base 64 encoded JavaScript too. 

Whatever function that Mozilla can perform using a javascript: alert in address bar can also be performed using a base 64 version. 

Here the only problem I feel was you are blocking javascript:alert() but not blocking its base 64 version which also performs the same function.
We don't have an issue with users running javascript: urls in the addressbar per se -- it's been a basic capability of web browsers since the javascript: url was invented. However scammers were taking advantage of this functionality to manipulate/fool users into executing malicious scripts in the context of a domain with something of value to the scammer (especially effective on social sites like Facebook and Twitter).

To prevent this abuse we want to stop the execution of ADDRESSBAR javascript IN THE CONTEXT OF the current page.

As Gavin noted in comment 4 a strictly computational javascript: url WILL run. The result is converted to a string (if necessary) and then displayed as an HTML document. The context this code runs in is pretty basic and if you reference an object that does not exist (alert, document, etc) then it throws an exception -- but the script _did_ run! You can detect this exception on the Web Console or Error Console, or use a try/catch block in your script.

data: urls in the addressbar no longer inherit the page's context either, they get their own unique origin. But a document _is_ created for it and therefore any scripts in the page are less likely to hit the exceptions that make your test javascript: url not work. Since it's a new context any scripts can't harm the page the user was just on. There's no more security problem letting scripts run than on any other page you load on the internet so we can let them run.

Base64 has nothing to do with this. Many data: urls happen to be base64 encoded but they don't have to be, and script execution happens the same either way. The behavioral difference is due to the fact that data: urls create a document and javascript: urls do not.

Testcase:
1. open some page you know has cookies. This page, for example
2. in the addressbar execute the following:
  data:text/html,<script>alert(document.cookie)</script>

Result: a blank alert will be shown, not containing the site's cookies.

The results for javascript: and data: urls differ because their contexts differ, but in both cases we prevent scripts from running in the context of the displayed page which was our goal. Stopping scripts for their own sake was not.
Group: core-security
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(jruderman)
Resolution: --- → INVALID
Hi Daniel,

As per You comment - " However scammers were taking advantage of this functionality to manipulate/fool users into executing malicious scripts in the context of a domain with something of value to the scammer (especially effective on social sites like Facebook and Twitter).To prevent this abuse we want to stop the execution of ADDRESSBAR JavaScript IN THE CONTEXT OF the current page." 

You have told that there is a threat in executing JavaScript in address bar of the browser, even-though I am not able to fetch the cookie. That is the reason you have blocked this functionality. And in this case I am able to perform what you have blocked. 

I am executing the same javascript: alert which you have blocked, using the base 64 encoded script on the same place. So I felt this  should also be prevented. This is like bypassing some filtering mechanism used in Mozilla if i am not wrong. 

Also Please confirm that there will not be any problem if I publish an article in my blog about this topic "How to execute JavaScripts on address bar of Firefox".
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I concur with Dan.  This isn't a "filtering mechanism"; it's just a decision to not execute address bar scripts *in the context of the current page*.  For javascript: URLs, that meant giving them a separate origin and scope (?).  For data: URLs, the least restrictive way to do that was to give them a separate origin.

I don't mind if you blog about this behavior.
(In reply to Shinto K Anto from comment #7)
> You have told that there is a threat in executing JavaScript in address bar
> of the browser, even-though I am not able to fetch the cookie.

Why do you ignore "in the context of a domain"?

> That is the
> reason you have blocked this functionality.

We do not block script execution functionality itself, as Daniel already said.

> And in this case I am able to perform what you have blocked. 
>
> I am executing the same javascript: alert which you have blocked, using the
> base 64 encoded script on the same place.

No, you aren't. You are not executing the script in the same context of the page.
Script execution itself doesn't matter.

> So I felt this  should also be
> prevented. This is like bypassing some filtering mechanism used in Mozilla
> if i am not wrong. 

We are not using any "filtering mechanism" in the first place.
This is unrelated to base64 at all. (Try "data:html,%3Cscript%3Ealert%28document.cookie%29%3C/script%3E").

Please do not reopen again based on the complete misunderstanding.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: