Hybrid View

[Security] XSS attacks for Extjs Applications - critical warning

[Security] XSS attacks for Extjs Applications - critical warning

While I've not examined Lists yet, Grid is highly susceptible to XSS attacks. Due to it's lack of escaping of data rendered into the page. String.format(), which 'on the face of it looks like it might solve it' does nothing to reduce this problem.

Here a proof of concept.
-> there is a user comment form on a website. which comments can be posted:
-> data is assumed to be just raw text, and is stored in the database 'As is'.
-> Back end application uses ExtJs to render list of new comments using JSON to just send the data (escaped correctly for JSON) to the Grid.

It's not the view layer's job to do data security cleanup. In fact, doing so there could have a huge negative impact on performance of your application. That should be on an entirely different layer. I would recommend that when you do validation of data entered, you also do clean up to remove any insecure content.

The reason its a valid XSS attack is that this isnt a matter of the user submitting something and the server then dealing with it and not cleaning it up; the code never gets to the server because users are able to execute arbitrary js in the context of the page.

Ext guys, why dont we flip the argument around, can anyone think of a single valid usecase for NOT escaping this content? Why would a user ever want to specify markup in an input field? (sure, I can think of contrived cases, but nothing that actually happens in real life!)

The reason its a valid XSS attack is that this isnt a matter of the user submitting something and the server then dealing with it and not cleaning it up; the code never gets to the server because users are able to execute arbitrary js in the context of the page.

Executing arbitrary JS in the context of your page view, does not constitute an XSS attach that should be of concern. Further, your backend system should be built such that incoming data is scrubbed, cleansed, validated, etc. The presentation layer, or more specifically a presentation layer that's open for adjustments by the end user (via something like Firebug), cannot and should not be relied upon to offer protection against XSS as that protection can be easily compromised.

Originally Posted by Hani

Ext guys, why dont we flip the argument around, can anyone think of a single valid usecase for NOT escaping this content? Why would a user ever want to specify markup in an input field? (sure, I can think of contrived cases, but nothing that actually happens in real life!)

In my experience, markup has lots of valid usecases in fields. In fact, in a CMS, it's almost a requirement to support markup in nearly every input field that accepts non-datetime/non-numeric data.

Any and all code samples that are authored by me and posted on the Ext forums or website are hereby released into the public domain and I release anyone or entity of liability by using said code samples unless explicitly stated otherwise.

Opinions are mine and not necessarily endorsed by Ext, LLC. Please do not contact me directly for assistance unless requested by me.

Err, the only sane usecase for this would be in textareas, a textfield that allows markup would be pretty stupid and bad design imho, since all you'd be able to do is have one liners.

The only sane usecase is textareas? Whether you agree with me or not, my point that markup in fields (regardless of type), is still valid.

Originally Posted by Hani

Likewise for a grid edit, I still maintain that it makes no sense whatsoever to allow inline markup by the user in such a form (and this is for a CMS too).

Again, we're going to agree to disagree. I don't feel anywhere near as passionate about disallowing markup in a grid and can think of plenty of cases where it would be helpful for a client, should they choose to use it.

You skirted my strongest point though and that's the [in]security of having the client-side framework even bother with protecting against markup in fields. Did you choose to not respond to that because you think it's invalid or because you don't have a rebuttal to it?

Any and all code samples that are authored by me and posted on the Ext forums or website are hereby released into the public domain and I release anyone or entity of liability by using said code samples unless explicitly stated otherwise.

Opinions are mine and not necessarily endorsed by Ext, LLC. Please do not contact me directly for assistance unless requested by me.

You skirted my strongest point though and that's the [in]security of having the client-side framework even bother with protecting against markup in fields. Did you choose to not respond to that because you think it's invalid or because you don't have a rebuttal to it?

I'm not ignoring it, because this argument to me seems to imply that XSS attacks dont exist, which is not something I'm willing to debate (because this isnt the forum for it). While on one level I do agree with you, the world at large doesnt, and has decided that XSS constitutes a security hole, and merits security advisories (and I've received a few, so I know!)

The issue isnt whether scrubbing is done server side or not, its that there's no trivial way of making sure that this cleanup is done both server and client side.

As you said though, we can agree to disagree, and I can but hope that enough users run into this that it merits reconsideration.

The reason its a valid XSS attack is that this isnt a matter of the user submitting something and the server then dealing with it and not cleaning it up; the code never gets to the server because users are able to execute arbitrary js in the context of the page.

This does not constitute an XSS attack, since it does not affect another users page, it only affects your page view. If it were a cross site scripting attack, it would require the unescaped data to be passed back to the server, and subsequently served to someone else. Cross site scripting attacks have much more to do with the server side unescaped data, than the client side unescaped data. Why should the presentation layer have to worry about the data, that's not its job.

Originally Posted by Alan Knowles

We work with raw data in all places, the only place where it's not 'raw' is where it is displayed, in which case it should be escaped. - I would surprised if http://www.yui-ext.com/forum2/topics-remote.php escapes data.. - opening up all cookies in this forum for usage by a malicious attacker..

Again, you shouldn't be passing raw data to the presentation layer if can't simply display it, you should be passing the data as it should be displayed, the presentation layer really shouldn't have to massage the data or muck around with it. (Ideally)

Originally Posted by Alan Knowles

But again, not having this as default behaviour is not only a little unexpected, but very risky.

What other presentation tier framework has a default behaviour of escaping data? Escaping should be done on an as-needed basis. Assuming that data will be escaped is much more detrimental than not (which I would argue is extremely risky), and leads to far more XSS attacks than when an engineer assumes that the input is never reliable or trustworthy. I for one would rather assume the data isn't escaped, and use escaping methods when needed, you know, the same way you do in most languages (Java, PHP, etc)

This isn't a cross site scripting issue, and I don't know why you guys are hung up on doing all this client-side escaping when it would take 2 minutes to disable via firebug. Sure the implementation is easy, but it doesn't add any more security.