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.
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...
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.
should try to fix for 1.4 final if possible.
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 Function.href. I am updating my tree now.
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.
Created attachment 124384 [details] [diff] [review] patch v.2 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.
Comment on attachment 124384 [details] [diff] [review] patch v.2 I think this will do for now. r=mstoltz.
Comment on attachment 124384 [details] [diff] [review] patch v.2 brendan, can you review this change?
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. a=rjesup
Checking in caps/idl/nsIScriptSecurityManager.idl; /cvsroot/mozilla/caps/idl/nsIScriptSecurityManager.idl,v <-- nsIScriptSecurityManager.idl new revision: 220.127.116.11; previous revision: 1.54 done Checking in caps/src/nsScriptSecurityManager.cpp; /cvsroot/mozilla/caps/src/nsScriptSecurityManager.cpp,v <-- nsScriptSecurityManager.cpp new revision: 18.104.22.168; previous revision: 1.201 done Checking in netwerk/protocol/http/src/nsHttpChannel.cpp; /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v <-- nsHttpChannel.cpp new revision: 22.214.171.124; previous revision: 1.165 done Waiting on the trunk to open to check in there.
Adding branch fixed1.4 keyword
fixed on trunk: Checking in caps/idl/nsIScriptSecurityManager.idl; /cvsroot/mozilla/caps/idl/nsIScriptSecurityManager.idl,v <-- nsIScriptSecurityManager.idl new revision: 1.55; previous revision: 1.54 done Checking in caps/src/nsScriptSecurityManager.cpp; /cvsroot/mozilla/caps/src/nsScriptSecurityManager.cpp,v <-- nsScriptSecurityManager.cpp new revision: 1.203; previous revision: 1.202 done Checking in netwerk/protocol/http/src/nsHttpChannel.cpp; /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v <-- nsHttpChannel.cpp new revision: 1.166; previous revision: 1.165 done bash-2.05b$
Is there an updated test case for this bug? The mentioned site is now gone.
I've put it back up at http://plaz.net.nz/mozilla/ Sorry about that - the box I had plaz.net.nz hosted on fell over somewhat messily. Cheers, Sam
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 site.
V, verified 1.4, using Netscape 7.1
Bugs published on the Known-vulnerabilities page long ago, removing confidential flag.