[Security] XSS attacks for Extjs Applications - critical warning

[Hani]

grid.on('validateedit', function(e){
   e.value = Ext.util.Format.stripTags(e.value);
});

Yay, even better than the previous workaround!

I agree re someone injecting js for their own pages, but the example above shows someone doing it such that they get data from other users. Granted, server side scrubbing is the fix there, but the UI would not reflect that scrubbing without additional code. Having said that, the 3 liner is easy enough to add in (and would be sooo nice as a toggle).

[haibijon]

Granted, server side scrubbing is the fix there, but the UI would not reflect that scrubbing without additional code.

Not that the posts before this haven't already said this, but... Client side scrubbing doesn't really do much, there isn't anything keeping someone from removing your scrubbing using js through firebug, or any other js console. When developing any client/server application you can never assume that data that is being sent from the client is secure... Client's can be spoofed, and data can be manipulated, that is true in any client/server environment using a socket protocol. So even if you scrub the data on grid input, the only thing you're doing is making it harder to break the grid's html when the data is rendered. Server side scrubbing is the best-practice thing to do.

Having said that, the 3 liner is easy enough to add in (and would be sooo nice as a toggle).

Though the fix is easy, I wouldn't vote for this to be integrated into the framework. If anything it makes it easier to untoggle the validation through a js console.

[watrboy00]

XSS is when 1 user can input JS that can be executed on another users page. The proper way to prevent that (IMO) is to clean it up before it is stored in the DB, not every time it is displayed.

I would have to also say that if you are not cleaning the code before it gets inserted into your database then you are leaving yourself a little more open that just xss attacks. No escaping input on the server side could cause large possibilities for sql injects rather than just xss attacks.

You should always fix the root solution and not try to implement exception rules in your client side js to prevent problems.

[Alan Knowles]

I don't think many really see the issue here. I noticed the lack of escaping purely by accident. Having assumed that it would be the default behavior.....

Our data is email connection records using exim's mysql feature. - we store things like subject / from: line and use this to enable and administrator determine if the end user should receive the email (like spam or recruitment emails from competitors.)

I've installed this on my own server to test, and noticed that
xxx <email@address> was just rendering as xxx - with the email hidden...

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...

If this is anything to go by, - there are alot of open door's out there...
http://75.126.167.146/forum/showthread.php?p=37106

While not in this particular application, I often do some data processing of data in the grid, client side. and It is essential that the data is not munged in any way so the processing can provide the correct results.

I have seen many applications that are complete messes, as they tried to munge the data at various points and resulted in gibberish at the end of the day. - There is nothing wrong in storing raw data from post's in database - mysql_escape/stored procedures solve that issue.
There is nothing wrong in sending raw data via json (most json libraries correctly escape that data). But then displaying that data 'as is' on something like grid is just dangerous.

The fix may have a small performance hit (read extremely small in most cases, compared to the HTTP call required to fetch the data). and can easily be turned off.. hence I would be surprised not to see it used..

[jack.slocum]

Combined with a couple of functions Alan, it is easy to set it up as you want.

The one from above:

grid.on('validateedit', function(e){
   e.value = Ext.util.Format.stripTags(e.value);
});

And a renderer on the column:

renderer: Ext.util.Format.htmlEncode

[Alan Knowles]

I'm not sure if htmlEncode is a vaild way of doing html encoding - have a look at PHP's htmlentites functions to get an idea of the real complexity.. - using DOM textNode's is probably going to catch far more edge cases : - UTF8 international characters etc....

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

[haibijon]

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.

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)

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.

[Specks]

I'm going to agree with all those who said that this doesn't constitute an XSS attack. As long as doesn't affect another user's browser the point being made that it is, is moot. Now if you were to submit the data as is and uncleaned of any markup then yes you have a problem. It's not on the Javascript side though. It's up to the server side script to clean any user input.

Might I suggest HTML Purifier if you're submitting anything marked up? Other than that type checking should be sufficient.

Specks

[Alan Knowles]

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.

This I would have to say is absolute rubbish.

I have a database library that escape data to prevent SQL injection, and has to be 'forced' not to escape data. making locating potential SQL injection issues thousands of time simpler.

I have a JSON library that escapes data to prevent XSS attacks on data being sent from the server to the browser. Making XSS practically impossible at this layer.

I have a template library that escapes data by default to prevent XSS attacks. again making any potential holes simple to locate, and difficult to accidentally do.

What I'm missing is a presentation layer 'extjs' that uses data, and presents it by default, as raw and ready for attacks. This I regard as a serious flaw - read bug!, And the only justification for not fixing it, is that it may be a slight performance issue...

Libraries should be designed to make it difficult to accidentally cause security holes, rather than the opposite.....

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)

mmh... PDO prepared statements (most PEAR libraries), JSON libraries... Most 'good' PHP template libraries... - All of these libraries do escaping "on an as-needed basis" eg. when it goes in a database, when it get's sent via JSON, or "When it is rendered in HTML"

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.

Yes it add a huge amount of security by default. My bets are that most current public application using ExtJS are viable XSS targets due to this bug...

[ElliotS]

What I'm missing is a presentation layer 'extjs' that uses data, and presents it by default, as raw and ready for attacks.

Eh? But where is this data coming from? The server! Where it should have been cleaned!

As long as doesn't affect another user's browser the point being made that it is, is moot.

Well said, or in wikipedias words....

Cross site scripting (XSS) is a type of computer security exploit where information from one context, where it is not trusted, can be inserted into another context, where it is. From the trusted context, an attack can be launched.

-1 for "fixing" this.