Closed Bug 195201 Opened 22 years ago Closed 21 years ago

An image that sends a "Location: javascript:document.location.href='....';" http header will redirect the whole browser window


(Core :: Networking: HTTP, defect, P3)

Windows 2000





(Reporter: plaz, Assigned: dougt)





(1 file, 2 obsolete files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; PN)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030226

The page linked to from has <img 
src="image.jpg"> .. image.jpg is a php script that sends the http 
header "Location: javascript:document.location.href=''".

This causes the browser window to be redirected to the mozilla site.

Reproducible: Always

Steps to Reproduce:
Described above
Actual Results:  
Browser window was redirected to

Expected Results:  
Not execute javascript delivered in http headers.

Theme was default.
Computer is a duron 850 with 640mb ram, running Windows 2000.
I'll download the nightly Linux build when I get to work tomorrow, and try it 
with that.

I'm guessing this could cause problems with people posting images to forums 
that redirect browsers to porn sites or similar.
while this could be annoying, i don't think there are any security ramifications.
Actually, I can see not supporting JS in Location: headers.  But yes, this is
not a security bug.
Group: security
->Networking: HTTP
Assignee: asa → darin
Component: Browser-General → Networking: HTTP
QA Contact: asa → httpqa
I'm hesitant to agree on that.  

I haven't tested it fully, but given that the document.location code is
executing, is there the possibility that other javascript code could be
executed, modifying the document in the web browser without the user's
knowledge?  For example, changing the action property on a form in the document
and redirecting the submission?
OK, I see this (1.3b/Win2K). Confirming. I agree with comment 4; I'm sure that
there are plenty of nasty things someone could do with this. Furthermore, I
can't think of any times where you would legitimately put some Javascript in a
Location header that couldn't be done in a better way.

I've just tried in IE5.5, and it isn't susceptible to this; the test URL just
shows a broken image.
Ever confirmed: true
Likewise with IE6 and Konqueror (In fact Konq spews warnings apout javascript 
redirects to stdout when it tries to open the image)
Yeah, but JS code executing this way is no different from JS code executing any
other way, imo (think linking to an image that's SVG and just has script
embedded in it).
given the timing of this bug report, i wonder if this bug could be a duplicate
of or possibly related to bug 193887.
In response to comment 7:

There's no real issue if you're hosting images yourself, but if you have a site
that links to images on a host that you're not in control of, then somebody with
access to the images you're linking could manipulate the content of your site at
the browser.
Many forums allow posts to include <img>s with off-site srces.  I disagree with
bz's conclusion that this isn't a security problem.
we have discussed possibly limiting HTTP redirects to a whitelist. i don't know
if now is the right time to do that or not...
Priority: -- → P3
Target Milestone: --- → mozilla1.4final
I thought that we'd blocked js redirects a long time back.

Even ignoring this, why is the document getting redirected, not the image? Is
this because ofhte nsImageDocument hacks? Even so, 'document' shouldn't be the
parent document.
The script is executed in the context of the parent document, in this case.

Jesse, your concern about off-site images does not address the fact that SVG has
precisely that problem, and that as people move from the deprecated (in XHTML)
<img> to <object> this will only get worse, since HTML could be used instead of
SVG as the script vehicle.
svg doesn't yet work in <img>, and theres a bug somewhere detailing the security
concerns this would have.
If an HTML page includes a <SCRIPT SRC="script file from some other host"> tag,
then the script runs with the permissions of the page and can modify or read the
DOM of the page. It's always been that way: including a script from another host
gives anyone with write access on that other host control over your page. The
problem here is that there may be an assumption among page authors that the same
is not true for images. Lots of people include images from other hosts without
realizing this security implication. For that reason, I think this is a real
security issue that should be fixed ASAP.

Marking this bug Security-Sensitive.
Group: security
should try to fix for 1.4 final if possible.
Flags: blocking1.4+
Whiteboard: [ETA: June 12, 2003]
mitch, doug: can one of you pick this up for 1.4 final?  thanks!
in 1.4b, i get an uncaught exception: permission deniced to get property

I am updating my tree now.  
Assignee: darin → dougt
yup.  i can repro with a build from this morning.  I hope to look at this over
the 3 day weekend.  If someone has time, it would be a good exercise to reduce
the range of dates where this bug started to occur.
I checked version 1.3, 1.4a, and 1.4b.  I could only reproduce this problem in
1.3.  Mitch we attempt to fix any similar issues between 1.3 and now?  I am not
sure if this is a regression or if this is a hole that we never encountered.

This test case is slightly misleading.  The contents of the image doesn't really
matter in the general case.  You could set up a server that on every image
request, the server returns a redirect as part of the response.  

There is no way to prevent an image request from returning a Location field in
the http response.  So, the root of the problem, i believe, is that we are
honoring URI's that have no business being in a Location field.  This follows
darin comment #11.

Also Mitch, we currently call CheckLoadURI() when processing the redirect.  It
would be nice to continue using this check instead of special casing the code in
http.  How do you suggest that we instruct this method to exclude javascript and
possibly other URL schemes during a redirect check?  

Any suggestions on alternative fixes?  

Whiteboard: [ETA: June 12, 2003]
Your approach sounds good. We can add another "flag" to CheckLoadURI that
excludes javascript: and data: URLs.
Attached patch CAPS patch (obsolete) — Splinter Review
This patch adds a new option to CheckLoadURI that prevents loading javascript:
and data: URLs. To use it, pass nsIScriptSecurityManager::DISALLOW_JAVASCRIPT
as the third argument to CheckLoadURI.
Attachment #124319 - Attachment is obsolete: true
Attached patch patch v.2Splinter Review
Although, I am not convinced that this is the best solution to the problem, it
does fix the potential security hole and it is quite simple.
Attachment #124380 - Attachment is obsolete: true
Comment on attachment 124384 [details] [diff] [review]
patch v.2

I think this will do for now. r=mstoltz.
Attachment #124384 - Flags: review+
Comment on attachment 124384 [details] [diff] [review]
patch v.2

brendan, can you review this change?
Attachment #124384 - Flags: superreview?(brendan)
Attachment #124384 - Flags: approval1.4?
Comment on attachment 124384 [details] [diff] [review]
patch v.2

Call it DISALLOW_SCRIPT to generalize to other languages than javascript, and
to take in the notion of data: URLs.  Maybe DISALLOW_SCRIPT_OR_DATA?  Your

Attachment #124384 - Flags: superreview?(brendan) → superreview+
mitch, you pick the name.
Comment on attachment 124384 [details] [diff] [review]
patch v.2

Feel free to change the define name before checkin, but let's get this in. 
Attachment #124384 - Flags: approval1.4? → approval1.4+
Checking in caps/idl/nsIScriptSecurityManager.idl;
/cvsroot/mozilla/caps/idl/nsIScriptSecurityManager.idl,v  <-- 
new revision:; previous revision: 1.54
Checking in caps/src/nsScriptSecurityManager.cpp;
/cvsroot/mozilla/caps/src/nsScriptSecurityManager.cpp,v  <-- 
new revision:; previous revision: 1.201
Checking in netwerk/protocol/http/src/nsHttpChannel.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v  <-- 
new revision:; previous revision: 1.165

Waiting on the trunk to open to check in there.
Adding branch fixed1.4 keyword 
Keywords: fixed1.4
fixed on trunk:
Checking in caps/idl/nsIScriptSecurityManager.idl;
/cvsroot/mozilla/caps/idl/nsIScriptSecurityManager.idl,v  <-- 
new revision: 1.55; previous revision: 1.54
Checking in caps/src/nsScriptSecurityManager.cpp;
/cvsroot/mozilla/caps/src/nsScriptSecurityManager.cpp,v  <-- 
new revision: 1.203; previous revision: 1.202
Checking in netwerk/protocol/http/src/nsHttpChannel.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v  <-- 
new revision: 1.166; previous revision: 1.165
Closed: 21 years ago
Resolution: --- → FIXED
Blocks: 211999
Is there an updated test case for this bug? The mentioned site is now gone.
QA Contact: httpqa → benc
I've put it back up at

Sorry about that - the box I had hosted on fell over somewhat messily.


So if the fix worked the page simply displays w/ a broken image right?
Yeah - that's right.

On Mozilla 1.3 and below, it redirected the entire browser window to another 
V, verified 1.4, using Netscape 7.1
Keywords: fixed1.4verified1.4
Bugs published on the Known-vulnerabilities page long ago, removing confidential
Group: security
You need to log in before you can comment on or make changes to this bug.