Page 1 of 1
XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 2:33 pm
by 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:
- Should chrome: or about:blank origins ever result in XSS?
- 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
- 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?
Re: XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 3:01 pm
by Giorgio Maone
al_9x wrote:
Should chrome: or about:blank origins ever result in XSS?
Yes.
al_9x wrote: 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.
al_9x wrote: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.
Re: XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 3:26 pm
by al_9x
Giorgio Maone wrote:al_9x wrote:
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?
Giorgio Maone wrote:al_9x wrote: 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.
al_9x wrote: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?
Re: XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 3:40 pm
by Giorgio Maone
al_9x wrote:Giorgio Maone wrote:al_9x wrote:
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.
al_9x wrote:
I don't understand what this means.
Don't worry, the important thing is that
I do
al_9x wrote: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.
Re: XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 5:10 pm
by al_9x
Giorgio Maone wrote:al_9x wrote: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?
Giorgio Maone wrote: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?
Giorgio Maone wrote:al_9x wrote: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.
Re: XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 6:00 pm
by Giorgio Maone
al_9x wrote:
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,
al_9x wrote:
Giorgio Maone wrote: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).
Giorgio Maone wrote: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.
Re: XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 6:22 pm
by dhouwn
al_9x wrote: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.
Re: XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 8:36 pm
by al_9x
Giorgio Maone wrote:
Like any other XSS origin exception,
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?
Re: XSS from chrome: and about:blank
Posted: Wed Jun 22, 2011 8:43 pm
by Giorgio Maone
al_9x wrote:Giorgio Maone wrote:
Like any other XSS origin exception,
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.