Closed Bug 530308 Opened 15 years ago Closed 3 years ago

Disallow <object data="javascript:..."> for XSS prevention

Categories

(Core :: Layout, defect)

x86
Windows Vista
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: brandnewx, Unassigned)

References

Details

(Keywords: sec-want, Whiteboard: [sg:want P4])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

A special crafted HTML code will allow attackers to remotely execute malicious javascript code in the latest Firefox browsers.

Reproducible: Always

Steps to Reproduce:
1. Create an HTML file with the following text:

<object data="javascript:alert('hello')"></object>

2. Open it in the browser. The javascript will execute. This opens a security hole to initiate a XSS attack.

3. Another variant of the XSS code is:

<object data="http://website/page-that-contains-javascript-code.html"></object>
Actual Results:  
The javascript will execute. This opens a security hole to initiate a XSS attack.

Expected Results:  
The javascript code embedded should never be executed.
How did the <object> tag get there? If an attacker can inject an object tag they can inject <script> or <iframe> tags. This is a well-known XSS vector and is considered a site-authoring bug.   http://ha.ckers.org/xss.html#XSS_OBJECT

Your Firefox 3.0.10 is vulnerable to 6 months worth of security fixes, including one very bad SSL exploit announced at this past summer's BlackHat conference. Please upgrade to 3.0.15 or 3.5.5 ASAP!
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Hello Daniel,

<object> tag is allowed on many social networking websites for video and app embedding, whereas <script> and <iframe> are not typically allowed.

The thing is the <object> tag should never behave that way. It is not a by-design feature; therefore, it should be investigated further and fixed. I suspect this very vulnerability might be limited to only <object> tag but many others as well.

By the way, <iframe> should be safe, as the javascript in the iframe is sandboxed in another domain.

I have successfully tested this vulnerability on some social networking sites and have informed them separately.

Regards,
I really don't like the way you put this issue as "Resolved Invalid."

This is a valid security issue here. IE7, IE8, Chrome and Safari do not exhibit this vulnerable behavior like Firefox does.
Status: RESOLVED → VERIFIED
Resolution: INVALID → FIXED
The bug is NOT fixed in the latest version of Firefox.
Resolution: FIXED → WORKSFORME
Blocks: xss
This XSS pattern is well-known, so I'm making this bug report public.
http://www.google.com/search?q=xss+%22object+data+javascript%22

But I'm also reopening it, because I think we should fix it.  It's not an XSS flaw in Firefox, but it could make a site vulnerable in Firefox that is not vulnerable in most other browsers (with the exception of Opera).

Web site authors could miss this case because of the unusual attribute name "data" (rather than "src" or "href"), or because they think the "type" attribute will protect them, or just because they made a mistake.

I'm not sure what all the popular plugins do, though, which is relevant to whether it's sane for a web site to allow users to stick in <object>s at all.

FWIW, WebKit seems to be quite aware of their decision to disallow javascript: URLs here:
http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/xssAuditor/object-tag-javascript-url.html
http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/xssAuditor/object-tag-javascript-url-expected.txt
Group: core-security
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: 'object' tag is vulnerable to XSS attack → Disallow <object data="javascript:..."> for XSS prevention
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Whiteboard: [sg:want P4]
Status: UNCONFIRMED → NEW
Ever confirmed: true
> By the way, <iframe> should be safe, as the javascript in the iframe is
> sandboxed in another domain.

It's sandboxed just as much as <object>; no more and no less.  The only difference is that the iframe js is executed in a separate script context (but one same-origin with the parent page!) if using <iframe src="javascript:"> but an <object data="javascript:"> is executed in the parent page's script context.

The <object> behavior here was last changed in bug 300263.  It sounds like comment 5 is requesting that that fix be backed out, effectively?

In any case, any site allowing completely user-authored <object>s has lost the XSS battle immediately.  <object> can load all sorts of nasties other than javascript: URIs.  Most obviously, Flash plug-ins and data: URIs.  It looks like webkit doesn't propagate the parent principal for the latter, which has come up as a point of contention before: their approach breaks most legitimate data: URI uses...

Jesse, if you want to come up with a coherent plan and decide that we're actually doing it and will push for standardizing it, then we should consider implementing it.  I think the whack-a-mole approach, with constantly changing policy on <object>, breaking and unbreaking sites, etc is totally worth it.

First question: Should it be safe to include an <object> whose attributes you do not vet in your page?  If not, this bug seems invalid to me.  If yes, what things other than this bug are obstacles to such safe inclusion?
Oh, and to be clear the last part of comment 0 is bogus, and the "not a by-design feature" of comment 2 is bogus.  The current <object> behavior wrt javascript: URIs is very much by-design.  Again, see bug 300263.
Boris,

Why would anyone want to legitimately execute some javascript in the 'data' attribute of an object? Basically, it does not make sense that javascript code injected in the <object>' data attribute could get executed. I do not see any legitimate use of this whatsoever. Since you believe otherwise, please at least direct me to an example of it being legitimately used.

What I am seeing here is that you fixed a bug back in 2005 and then managed to create this bug. Then you stamped it as a by-design feature. 

To say that <object> could be used to load malicious flash/java/silverlight/etc object is unfounded. As far as I know, the plug-ins have their security model respectively. What you are trying to say is that those flash objects on Facebook and Myspace profiles pose serious security risks to users, which is also unfounded. Note that, I do understand that plug-ins may contain security vulnerabilities, but isn't that a different story? It is beyond the scope of this issue here.

Regards,

P.S. Boris, I appreciate if you could stop using the word "bogus" in place of "invalid" in response to my comments/posts. Don't you think it's a little bit intimidating?
In the interest of saving time, I believe the fix discussions should be limited to two thing:

1. Is the current behavior of <object data="javascript:"> beneficial to the users or not?

2. Does it conform to the standards? 

I do not see any reason why people should dicuss unrelated issues here. Does it matter how the <object> gets into the web page? No. That does not concern the design of Firefox. It is beyond the control of Firefox team. 

Again, IE6, IE7, IE8 and WebKit do not exhibit this behavior. Should Firefox and Opera be an exception and leave users vulnerable is up to your decision.
Note that the flawed feature could also be exploited this way:

<object data="http://website.com/page-that-contains-javascript-code.html"></object>

And again, only Mozilla has this great feature. /s
> Why would anyone want to legitimately execute some javascript in the 'data'
> attribute of an object?

I have no idea; similar for <iframe src>.  But people do it.  See examples in the bug I cite, and numerous examples all over the web for <iframe src>.  Why aren't you calling for that to be removed, exactly?

> What I am seeing here is that you fixed a bug back in 2005 and then managed to
> create this bug. Then you stamped it as a by-design feature. 

Then you're not reading very carefully.  Please go reread the bug I cited.  If nothing else, the bug was fixed in late 2007, and very very explicitly added this behavior.

> As far as I know, the plug-ins have their security model respectively.

They do, but they don't protect you against XSS injection, particularly.

> Don't you think it's a little bit intimidating?

I'll stick to calling such statements "factually incorrect" if that will make you feel better.  Will that make you check your claims before making them?

> I believe the fix discussions should be limited to two thing:

I believe those two things are insufficient; the cost of changing the behavior should also be considered, as should benefits to authors, weighed against those to users.  For your two things you mention, you seem to be arguing that the answer to #1 is "no" (whereas given that it works and that people are authoring content useing it the answer is "depends on whether anything the user uses breaks if we change it").  You don't really bring up #2 (at the moment the answer is "yes" insofar as any existing standards cover this; if HTML5 drafts cover this I'd like to see a link).

> Again, IE6, IE7, IE8 and WebKit do not exhibit this behavior. Should Firefox
> and Opera be an exception

So two browsers (IE, webkit) behave one way and two others behave another way.  Why are you picking a particular pair as "an exception".  Why not say that IE and webkit are the exception?

Comment 10 is factually incorrect.  Webkit executes script in that situation just fine, as you would know if you'd actually bothered to test.  It does apply the normal same-origin restrictions to it, as does Mozilla.

It would really help your case to stick to statements that are actually true.  For one thing, it wouldn't give me the sense that I'm wasting my time responding to false statements...
One other note: it might make sense to have a sandboxed version of <object> (similar to the sandboxed iframe idea in html5 drafts) which would disallow or sandbox a javascript: @data, as well as disallowing all types except that listed in @type from loading, not inheriting principals for data: values of @data, and probably some other restrictions.  Would be good to have a list of what it would actually take to make <object> safe to use, as I said above.
First off, I would like to know if there are other developers who fix security bugs. I'm now getting an impression that Firefox security is managed by a single developer. Jesse Ruderman suggested a fix, and Boris Zbarsky suggested a no-fix. So what is the verdict? Who can authorize a go to fixing this? Who's not?


> Why aren't you calling for that to be removed, exactly?

Instead of coming up with pointers to actual usage of <object data="javascript:">, you pointed to <iframe src="javascript:"> as an example. You don't realize that these two tags serve different purposes, do you?

I would compare this issue with <img src="javascript:..." />. Why wouldn't Firefox execute javascript in that img src attribute? 


>  Why not say that IE and webkit are the exception?

Remember that the current Firefox behavior put users at risk, while IE/Webkit do not. Who cares which is exceptional? You shouldn't pair Firefox with Opera anyway, because Opera will likely schedule a fix for this I believe (unless you work at Opera too, or there's a developer of the same kind).

>  bug was fixed in late 2007...

2005 or 2007 doesn't matter. What matters is that you introduced this security vulnerability with your fix. It was like fixing a problem with another problem. Should that old fix even be called a fix at all?

> I believe those two things are insufficient; the cost of changing the behavior
should also be considered.

As far as I believe that website developers should take extra care of giving the users to input <object> tags, I do not advocate personal guidelines set by browser developers.

Your fix was like "Hey the world, revolve around my proprietary design, or else you suffer the consequence." This philosophy is horrible. Browser developer should design in accordance to the accepted standards, and website developers in turn should revolve around the web standards, not your personal security guidelines. 

What's next in your security guidelines? The elimination of <object> so that the web is safe?


> I'm wasting my time responding to false statements...

I see your statements are all true especially the comparison of <object> to <iframe>.
> it might make sense to have a sandboxed version of <object>

That is a good idea, I must say (No sarcasm). I'm all for a good fix that keep users safe from this XSS. 

Your proposal is nice.
> Would be good to have a list of what it would actually take to make <object> safe to use, as I said above.

1. For that, I would suggest that Firefox disallow the following @type of <object>:

text/javascript
text/x-scriptlet

HTML standard has <script> to serve script types.

2. I thinking the the javascript: @data should be disallowed all together, as it has minimal usage. As IE/webkit don't execute it, due to compatibility issues like this, I don't see any reason why a web developer would use the javascript: @data.
> I would like to know if there are other developers who fix security bugs.

Sure.

> Who can authorize a go to fixing this?

Anyone who wants to can write a patch.  It then needs review from either the module owner (jst or peterv, in this case), or one of the peers (me, sicking, smaug).  See http://www.mozilla.org/about/owners.html the DOM module.  A peer's decision can be appealed to the owner; an owner's decision can be appealed to Brendan.  Given that this deals with javascript:, I'm not sure you actually want to appeal to Brendan; he thinks it should work in all sorts of cases where _I_ think it shouldn't (e.g. <img src>).

> Instead of coming up with pointers to actual usage of <object
> data="javascript:">

Bug 300263 is all about someone trying to use it (and then reporting as a bug that it stopped working).

> You don't realize that these two tags serve different purposes, do you?

<iframe> serves the purpose of embedding documents.  <object> serves the purpose of embedding arbitrary content, including documents.  The functionality of <object> is a superset of that of <iframe>, generally.  See section 13.5 of HTML 4.01 for an explicit statement to that effect.

> Why wouldn't Firefox execute javascript in that img src attribute? 

It does.  It just does so in a sandbox.  If your question is why it should be in a sandbox, that's excellent question.  Brendan argues it shouldn't.  I argue that it should because no browser has run such script outside a sandbox in the recent past (ever since Netscape 4.x went away), and hence no one ever expects this to happen, and more importantly since <img> is generally considered a "safe" tag.  <object> is generally NOT considered a "safe" tag by competent web developers, as things stand, for reasons far beyond the javascript: issue.  That said, <img src> the argument is in abeyance for now because imagelib doesn't know how to tell images the right security context to run the script with so they have no choice but to run it in a sandbox.

> It was like fixing a problem with another problem.

The problem I was fixing was "<object data='javascript:...'> has stopped working".  That's what the bug was reported on.  Did you actually _read_ the bug?

> Your fix was like

My fix was like "Hey, this used to work, but then we broke it when we rewrote <object>; let's restore the old behavior."

> Browser developer should design in accordance to the accepted standards

Sure.  Can you point to a standard that says that javascript: should not run here?

Comment 15 point 1 makes no sense; an <object> that uses the text/javascript type will just show the script as text; text/x-scriptlet is not supported at all (and will just fall back to the <object>'s fallback contnet).

Comment 15 point 2 is clearly necessary to make <object> safe in the sense that <img> is, but patently not sufficient.  My question is what _would_ be sufficient.  It's no use changing one "unsafe" behavior if there are several; it just gives web sites that want to use <object> as if it were safe a false sense of security.
> Can you point to a standard that says that javascript: should not run here

This leads back to the discussion about <img src="javascript:..." /> and why it should not run the javascript:. I believe the final decision against running "javascript:" in <img> is unrelated to any image library (selection of a proper security context). The decision made against running <img src="javascript:"> is solely to avoid XSS attacks.

If you're against <img src="javascript:">, I don't see any reason not to go against <object data="javascript">. The purpose is to thwart the same XSS attack.

Well you say, <img> is generally considered a safe tag and image library do not render . I agree. But do not forget that more and more web developers are considering an <object> as a safe tag too. Otherwise, Myspace, facebook and ning wouldn't allow users to input <object> into their profiles and messages.

So what I mean by "accepted standard" is basically widely accepted standard practice, whether it is adopted into a formal standard (i.e. W3C HTML4) or not. Just like element.innerHTML which is nowhere in W3C specification, yet I believe it's an "accepted standard."


> The functionality of <object> is a superset of that of <iframe>

<object> is a superset of <img> too.


> an <object> that uses the text/javascript type will just show the script as text

You're right. Firefox actually renders it as text. I thought it was related to the following alternative XSS vulnerability:

<object type="text/javascript" data="http://ha.ckers.org/scriptlet.html"></object>

What is the context that this <object> executes the javascript in? Is it that of <iframe>? Just want to clarify, because <iframe> would execute it in a different domain (which is safe), but this <object> executes the javascript in cross-domain.


> My question is what _would_ be sufficient

I think it is not sufficient. However, the user input of <object> is sometimes inevitable.

Extra precautions should always be taken. Various websites acknowledge that, and they wrap the <object> inside an <iframe> in which the @src points to a different domain. Some websites enforce the Flash permission security through "AllowScriptAccess" parameter. I think they are pretty conscious on enforcing many attacks except this <object data="javascript:"> XSS.
Correction

From:

Well you say, <img> is generally considered a safe tag and image library do not
render 

To:

Well you say, <img> is generally considered a safe tag
> But do not forget that more and more web developers are considering an <object> 
> as a safe tag too.

Then they're screwed no matter what we do with this bug.

> Just like element.innerHTML which is nowhere in W3C specification

It's in the draft HTML5 specification, fwiw.  That's also where the javascript: behavior would need to be defined.

> <object> is a superset of <img> too.

Right, which means it carries all the dangers of <img> (e.g. ability to exploit bugs in image libraries).

> What is the context that this <object> executes the javascript in? Is it that
> of <iframe>?

In this example, yes.

> but this <object> executes the javascript in cross-domain.

What makes you say that, exactly?  The <object> includes an HTML file that alerts the string "XSS".  It never tries to perform any cross-domain access, much less succeed at it.

> However, the user input of <object> is sometimes inevitable.

Then, pending a safe version of <object> the user input needs to be carefully validated.

> except this <object data="javascript:"> XSS.

I seriously doubt there are sites that deal with data="data:" but not data="javascript:".  Can you point me to one?

In any case, I think the next step for this bug is Jesse answering my questions from comment 6.
> Then they're screwed no matter what we do with this bug.

Not exactly. Not all web developers share your view that <object> is unsafe. Not even majority of web developers. If <object> were always deemed unsafe by all developer crowd, you wouldn't see it being allowed on most if not all multi-billion dollar social networking sites.

> It never tries to perform any cross-domain access, much less succeed at it.

Ah... you're absolutely right. I thought the JS executing in another domain didn't have the permission to calling alert(). It does.

> I seriously doubt there are sites that deal with data="data:" but not data="javascript:".  Can you point me to one?

I could not disclose the name of any vulnerable websites. I informed them separately for this matter. 

The websites in question do not validate the @data attribute (they do check for escape characters though). You could be asking why. For that, you should refer to Jesse's comment 5.

You shouldn't really doubt it. A working PoC is in comment 0. Somebody using it to attack is absolutely plausible. A web developer overlooking this XSS pattern is absolutely plausible.

Well, by the way, I consider my reporting job is done here. I'm looking forward to seeing the javascript URI disallowed for <object>.
> Not all web developers share your view that <object> is unsafe.

It's not a "view"; it's just a statement of fact: if they're allowing user-authored <object> with insufficient validation of the input, then I can write things that are equivalent to the issue that concerns you with javascript: without using javascript:.

> The websites in question do not validate the @data attribute

Then they lose even if we stop allowing javascript: in @data.
> I can write things that are equivalent to the issue that concerns you with
javascript: without using javascript:.

I'm not aware of any other @data attack besides this. I would appreciate if you could give some pointers. The @data is generally considered safe. How many developers would question that Firefox allows javascript: URI execution in there?
> I'm not aware of any other @data attack besides this.

Then you need to read comment 6 (or comment 12) again.
As Firefox is generally considered having stricter security scrutiny. Web developers generally test their XSS filters first with the least safe broswer: IE. If it's safe under IE, they generally consider it safe under Firefox.

That is probably a logical fallacy of a web developer, as Firefox in this case is not necessarily safer than IE.
> Then you need to read comment 6 (or comment 12) again.

Do you have any other working PoC that exploits the @data of <object>? In comment 12, you were not aware of other exploits yourself.

I think the allowing javascript: URI to pass is the only security mistake here. Correct me if I'm wrong, the rest of other data formats are safe.
> In comment 12, you were not aware of other exploits yourself.

Sounds like you need to read comment 12 again, carefully.

  <object data="data:text/html,<script>doStuff();</script>"></object>

> That is probably a logical fallacy of a web developer

Yes; any time browser A has a feature that browser B doesn't have testing in browser B tells you nothing about security risks of said feature.
This vulnerability is beyond javascript: URI. I am just aware of that.

Here's another PoC:

<object data="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH 
A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv 
MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs 
aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw 
IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh 
TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml"></object>
The point is, that's been the behavior of data: URIs as long as they've been implemented.  There's some debate as to whether it _should_ be the behavior, as I said.  But sites that aren't screening their @data just lose at the moment, as I also said.
Indeed, they lose it by not validating @data. A whole lot of nasties could be put in there. Thanks for pointing that out.

I've tried to reproduce this in Windows 10 with no luck. Since issue is no longer reproducible and hasn't had any updates in the past years I'll close it as resolved WFM. Please feel free to reopen it or open a new bug if you consider it that still occurs.

Status: NEW → RESOLVED
Closed: 15 years ago3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.