XSS from chrome: and about:blank

[al_9x]

turn off abe, allow javascript: on urlbar, allow localhost

Code: Select all

http://localhost/tests/?q=%F0%E0%20%E7

The above url entered from about:home or about:blank produces:

Code: Select all

[NoScript XSS] Sanitized suspicious request. Original URL [http://localhost/tests/?q=%F0%E0%20%E7] requested from [chrome://browser/content/browser.xul]. Sanitized URL: [http://localhost/tests/?q=%20#3430993393202175486].

The equivalent navigation from javascript: on about:blank

Code: Select all

javascript:open('http://localhost/tests/?q='+'%'+'F0' + '%' + 'E0' + '%' + '20' + '%' + 'E7','_self')

produces:

Code: Select all

[NoScript XSS] Sanitized suspicious request. Original URL [http://localhost/tests/?q=%F0%E0%20%E7] requested from [about:blank]. Sanitized URL: [http://localhost/tests/?q=%20#35888526449113833969].

two issues:

1. Should chrome: or about:blank origins ever result in XSS?
2. Should this particular char sequence trigger XSS? It represents printable Cyrillic chars that a windows-1251 page would submit. But even interpreted as latin it doesn't seem like XSS
3. a more general question: in theory % encoding is supposed to be universal, utf-8 based, but in practice it's based on the charset of the page, so what does that mean for decoding and interpreting urls out of context?

[Giorgio Maone]

Should chrome: or about:blank origins ever result in XSS?

Yes.

Should this particular char sequence trigger XSS? It represents printable Cyrillic chars that a windows-1251 page would submit. But even interpreted as latin it doesn't seem like XSS

Interpreted as UTF-8 they are an invalid sequence which can be uset to exploit the laxity of the utf8_decode PHP function (and of similar decoding methods in Java-based servers) to work-around XSS filters.
NoScript knows about it and preemptively triggers on expoitable quasi-UTF8 sequences like this.

a more general question: in theory % encoding is supposed to be universal, utf-8 based, but in practice it's based on the charset of the page, so what does that mean for decoding and interpreting urls out of context?

NoScript is aware of this problem and accommodates for potential encoding mismatches.

[al_9x]

Should chrome: or about:blank origins ever result in XSS?

Yes.

Please explain. Isn't the idea to prevent site1->site2? If the origin is about:blank or chrome: then is it not a user request? Is it possible to exempt these origins? If not can you add such capability?

Should this particular char sequence trigger XSS? It represents printable Cyrillic chars that a windows-1251 page would submit. But even interpreted as latin it doesn't seem like XSS

Interpreted as UTF-8 they are an invalid sequence which can be uset to exploit the laxity of the utf8_decode PHP function (and of similar decoding methods in Java-based servers) to work-around XSS filters.
NoScript knows about it and preemptively triggers on expoitable quasi-UTF8 sequences like this.

a more general question: in theory % encoding is supposed to be universal, utf-8 based, but in practice it's based on the charset of the page, so what does that mean for decoding and interpreting urls out of context?

NoScript is aware of this problem and accommodates for potential encoding mismatches.

I don't understand what this means. If you always decode as utf-8, then won't the result always be meaningless for pages that actually are using other encodings? That's probably fairly common for non us-en sites?

[Giorgio Maone]

Should chrome: or about:blank origins ever result in XSS?

Yes.

Please explain. Isn't the idea to prevent site1->site2? If the origin is about:blank or chrome: then is it not a user request? Is it possible to exempt these origins? If not can you add such capability?

Think of a user who's prompted by a phishing email to follow a link or copy & paste it on the address bar (for the chrome: case).

Regarding about:blank, there are edge cases where a hostile load can spoof it as its origin.

I don't understand what this means.

Don't worry, the important thing is that I do

If you always decode as utf-8, then won't the result always be meaningless for pages that actually are using other encodings? That's probably fairly common for non us-en sites?

I don't "always decode as UTF-8". I both decode as UTF-8 and as latin, as a fallback. Don't forget, also, that ASCII is a subset of most encodings (except UTF-7, UTF-16 and UTF-32, two of which are deprecated in the web platform and removed in Firefox 5, and which NoScript works around anyway), and the most interesting stuff in XSS happens in the ASCII bits.
Finally, as I already told you, special cases where transcoding may open the door to other exploitation scenarios (like the utf8_decode exploit) are explicitly handled by NoScript.

[al_9x]

Please explain. Isn't the idea to prevent site1->site2? If the origin is about:blank or chrome: then is it not a user request? Is it possible to exempt these origins? If not can you add such capability?

Think of an user who's prompted by a phishing email to follow a link or copy & paste it on the address bar (for the chrome: case).

That type of protection should be optional, just like javascript: on the urlbar. Not everyone needs it. You didn't answer, is there a way to exempt this origin, if not can you add such capability?

Regarding about:blank, there are edge cases where a hostile load can spoof it as its origin.

Would that be considered a gecko bug or is it normal? When specifically does that happen, please give an example?

If you always decode as utf-8, then won't the result always be meaningless for pages that actually are using other encodings? That's probably fairly common for non us-en sites?

I don't "always decode as UTF-8". I both decode as UTF-8 and as latin, as a fallback. Don't forget, also, that ASCII is a subset of most encodings (except UTF-7, UTF-16 and UTF-32, two of which are deprecated in the web platform and removed in Firefox 5, and which NoScript works around anyway), and the most interesting stuff in XSS happens in the ASCII bits.
Finally, as I already told you, special cases where transcoding may open the door to other exploitation scenarios (like the utf8_decode exploit) are explicitly handled by NoScript.

Non us-en sites that use their own local encodings are not doing this to send primarily ascii. So the bottom line is, for requests to sites that don't use utf-8 or latin url encoding, NS XSS filter is likely to produce false positives and there isn't anything that can be done about it.

[Giorgio Maone]

That type of protection should be optional, just like javascript: on the urlbar. Not everyone needs it. You didn't answer, is there a way to exempt this origin, if not can you add such capability?

Like any other XSS origin exception,

Code: Select all

^@(?:about|chrome):

Regarding about:blank, there are edge cases where a hostile load can spoof it as its origin.

Would that be considered a gecko bug or is it normal? When specifically does that happen, please give an example?

It happened in the past for regular web pages as Gecko bugs (one lasted many months in Firefox 4 betas, for instance), and it still can happen if an extension creates a preview or an otherwise filtered view of a web page by injecting its content in an empty iframe (Firebug, for instance, does it in more than one place, and so do feed readers).

Non us-en sites that use their own local encodings are not doing this to send primarily ascii. So the bottom line is, for requests to sites that don't use utf-8 or latin url encoding, NS XSS filter is likely to produce false positives and there isn't anything that can be done about it.

Since they all can represent ASCII, and ASCII is the "zone" where most checks are done (the above check for utf8_decode() exploits is very specific, and doesn't trigger for any invalid UTF8 sequence as you seem to suppose) the increased likeliness of false positives is modest, IMHO.

[dhouwn]

So the bottom line is, for requests to sites that don't use utf-8 or latin url encoding, NS XSS filter is likely to produce false positives and there isn't anything that can be done about it.

Well, maybe one could guess and/or remember what encoding the sites prefer. I remember to have read about such proposals on Mozilla's Bugzilla (must have been related to this or this bug report) to solve the problem of sites not getting their stuff in the encoding they want.

[al_9x]

Like any other XSS origin exception,

Code: Select all

^@(?:about|chrome):

That's good to know, so filterXExceptions are matched against the destination url and then also the origin url prefixed with '@'? Did you want it to be possible for the same filter to match either origin or destination?

[Giorgio Maone]

Like any other XSS origin exception,

Code: Select all

^@(?:about|chrome):

Did you want it to be possible for the same filter to match either origin or destination?

You can certainly do it by starting your filter with ^@?, but I'm not sure it's actually useful in many circumstances.