Yay, even better than the previous workaround!Quote:
Originally Posted by jack.slocum
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).
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.Quote:
Originally Posted by Hani
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.Quote:
Originally Posted by Hani
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.Quote:
Originally Posted by jack.slocum
You should always fix the root solution and not try to implement exception rules in your client side js to prevent problems.
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..
Combined with a couple of functions Alan, it is easy to set it up as you want.
The one from above:
And a renderer on the column:Code:grid.on('validateedit', function(e){
e.value = Ext.util.Format.stripTags(e.value);
});
renderer: Ext.util.Format.htmlEncode
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.
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.Quote:
Originally Posted by Hani
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)Quote:
Originally Posted by Alan Knowles
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)Quote:
Originally Posted by Alan Knowles
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.
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
This I would have to say is absolute rubbish.Quote:
Originally Posted by haibijon
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.....
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"Quote:
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)
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...Quote:
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.
Eh? But where is this data coming from? The server! Where it should have been cleaned!Quote:
Originally Posted by Alan Knowles
Well said, or in wikipedias words....Quote:
Originally Posted by Specks
-1 for "fixing" this.Quote:
Originally Posted by Wikipedia