18 Nov 2011 12:01 PM #141
Currently ExtJS 4 is much the same as previous versions from this perspective. You can alter the default renderer on grids easily enough if that's what you want (it's something I would recommend).
It is something the dev team are aware of:
18 Nov 2011 1:21 PM #142
- Join Date
- Jan 2009
- Palo Alto, California
- Vote Rating
18 Nov 2011 1:36 PM #143
That was pure speculation on my part. But my expectation in general is that on most browsers, most of the time this:
will be faster than:
div.innerHtml = myText;
1 Dec 2011 12:46 PM #144
7 Aug 2012 7:37 AM #145
This has not been adressed in 4.1.1.
I can still recreate this bug:
Which results in temporary ui hacks (very ugly bugs) because html is not escaped properly (within the framework) out of the box.
Now we need to double encode content for ext js 4 frontend.
This way we break our common rest api.
This is not funny!
EXT JS needs to encode html within the framework itself properly.
Try to store html data in a model property.
The data can break the page and or modify the objects in runtime.
Especially if its coming from the backend (you can see it in the page source as the raw data attribute).
This is really bad!!!
No data what so ever should break my ui.
It can be displayed wrong, but it should not break my ui !!!!
7 Aug 2012 8:29 AM #146
My 2 cents. The lack of Client side XSS protection shouldn't be an issue because you should "always" protect server side. Anything that Sencha build into the framework can be very easily hacked out client side.
7 Aug 2012 10:47 AM #147
- Join Date
- Mar 2007
- St. Louis, MO
- Vote Rating
Mitchell Simoens @SenchaMitch
Sencha Inc, Senior Forum Manager
http://www.JSONPLint.com - Source to lint your JSONP!
Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/
Need more help with your app? Hire Sencha Services email@example.com
Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is almost in print!
When posting code, please use BBCode's CODE tags.
8 Aug 2012 1:16 AM #148
Yes I agree !
XSS Protection is a serverside matter, I agree.
I really hope all web devs not that too.
We are not trusting the client to protect us from the complete
(As you could read we are re-endcoding every thing for ext js )
This is why I mentioned them as "ugly bugs", as they are only supposed XSS hacks.
Only work when you do not encode your stuff serverside.
Then again with local stores I can hack the hell out of my ui, which is not really that much of an issue,
unless it affects usability.
Which it does.
I guess I have to admit maybe the issue does not enable a full XSS hack.
Yet the mentioned root cause is affecting usability.
We end up doing the whole encoding reencoding thing ourselves.
Thanks for the adivce.
All web framework devs should know tho, that html encoding should work properly within the framework data itself.
Again I would like to refer to the bug:
Which really is a funny issue.
8 Aug 2012 1:30 AM #149
There is no single way to encode data to protect against XSS. You have to encode for the appropriate context: HTML, URL, CSS, attribute, or script. See the OWASP cheatsheet for explanation of the different contexts: https://www.owasp.org/index.php/XSS_...on_Cheat_Sheet
So, there is no single way to encode data. You have to encode for the context in which data will be used, even if all of it is in a web page. This means a web service must either encode for the specific context the data is used, or send the data 5 times, in 5 different encodings. The first one intimately ties the web service's implementation to the front-end implementation, the second one is hugely wasteful. Neither is a good design. Long story short: in my opinion, if you're encoding for output in your web service, you're doing it wrong.
So, let's all agree that encoding for output must be done in the web service client, the rendering layer. In an ExtJS app, this means it happens inside ExtJS code. If it must be done in ExtJS code, and it must; and if the ExtJS framework knows the exact context where data will be used, and it does; why in the world wouldn't you want to have the framework encode for output by default?
But even if encoding by default doesn't happen, can we at least get a master switch? I want to start my code with Ext.encodeForOutput = true and have the framework handle everything for me. Why can't I even get that?
Last edited by joeri; 13 Aug 2012 at 12:19 AM. Reason: Removed shouty bold tags, clarified wording
8 Aug 2012 1:50 AM #150
The default rendering of ui makes XSS happen.
But it seems as an enterprise software developer I do not understand your concept of webdevelopment.
I mentioned before that we now ended up encoding data on our api for specific context in ext js.
Which is the wrong way.
As joeri described.
So we of course are going to patch up encoding / re-encoding in our ui.
All web framework devs should know tho, that html encoding should work properly within the framework (client) data itself.
I can break the Ext Js ui out of the box with simple html input easily.
Which should not be possible!
This is where the problem starts.
See related discussion on html encoding:http://www.sencha.com/forum/showthre...l=1#post651043
We agree that "we" the devs can fix this. Also we agree that this is our concern to have proper encoding and dodge XSS.
Yet as a dev I would like to kindly ask you to support this very basic yet very important feature.
As it breaks ui and YES opens XSS threats if you do not actively encode properly for that ui context.