1. #141
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,605
    Vote Rating
    326
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    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:

    http://www.sencha.com/forum/showthre...741#post660741

  2. #142
    Sencha - Community Support Team edspencer's Avatar
    Join Date
    Jan 2009
    Location
    Palo Alto, California
    Posts
    1,939
    Vote Rating
    9
    edspencer is a jewel in the rough edspencer is a jewel in the rough edspencer is a jewel in the rough

      0  

    Default


    Quote Originally Posted by bfelaco View Post
    On the contrary, I think what Ext is doing by default today is actually performing worse than if the strings were inserted as text.
    How so?
    Ext JS Senior Software Architect
    Personal Blog: http://edspencer.net
    Twitter: http://twitter.com/edspencer
    Github: http://github.com/edspencer

  3. #143
    Ext GWT Premium Member
    Join Date
    Jul 2011
    Posts
    2
    Vote Rating
    0
    bfelaco is on a distinguished road

      0  

    Default


    That was pure speculation on my part. But my expectation in general is that on most browsers, most of the time this:
    div.appendChild(document.createTextNode(myText));
    will be faster than:
    div.innerHtml = myText;
    The original comments regarding performance seem to be assuming that you MUST use "div.innerHtml" and thus you would have to escape the text (in JavaScript) which would naturally be less efficient.

  4. #144
    Ext JS Premium Member
    Join Date
    Mar 2010
    Location
    Austin, TX
    Posts
    11
    Vote Rating
    1
    normanrichards is on a distinguished road

      0  

    Default


    Quote Originally Posted by bfelaco View Post
    I see no hint that in the API docs that this has been addressed in Ext 4 in any way, or am I just missing something? If not, then when do you plan to address this?
    I don't believe it has. I didn't follow up on my earlier comments here because after doing the basic work to secure the Ext app I was working on, I moved on to work on another project that happened to not be using Ext. A few months back, I came back to ExtJS, working a project that was migrating to Ext 4 (from a pure jquery/javascript UI) and the initial code developed for that had all the classic Ext HTML injection security bugs. Since the developers who did the work were very experienced in Ext and generally tried to do things the "recommended", I suspect that not much has been done to address the problem. Unfortunately I was only able to work on that project for long enough to demonstrate the fundamental problem and demonstrate how to work around the ExtJS encoding issues. It's possible that new solutions are in Ext4, but I didn't see anything.

  5. #145
    Sencha User
    Join Date
    Jun 2012
    Posts
    8
    Vote Rating
    0
    similian is an unknown quantity at this point

      0  

    Default


    This has not been adressed in 4.1.1.

    I can still recreate this bug:
    http://www.sencha.com/forum/showthre...l=1#post651043

    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.

    Best example:
    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 !!!!

  6. #146
    Ext JS Premium Member
    Join Date
    Jul 2010
    Location
    UK
    Posts
    524
    Vote Rating
    29
    MrSparks has a spectacular aura about MrSparks has a spectacular aura about

      0  

    Default


    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.

    For client side protection in EXTJS I believe Sencha should leave this for the end user/dev to work out. I'd rather not have more layers on top of the JavaScript framework slowing things down. I'd prefer to add bespoke implementations to my app.

  7. #147
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,330
    Vote Rating
    846
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    Quote Originally Posted by MrSparks View Post
    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.
    This should really be known by all web devs. Never trust the client, don't care if your mom is the only one that should be using it.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    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 services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  8. #148
    Sencha User
    Join Date
    Jun 2012
    Posts
    8
    Vote Rating
    0
    similian is an unknown quantity at this point

      -1  

    Default


    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.
    http://www.sencha.com/forum/showthre...l=1#post651043


    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:
    http://www.sencha.com/forum/showthre...l=1#post651043

    Which really is a funny issue.

  9. #149
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    559
    Vote Rating
    29
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      2  

    Default


    Quote Originally Posted by MrSparks View Post
    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.

    For client side protection in EXTJS I believe Sencha should leave this for the end user/dev to work out. I'd rather not have more layers on top of the JavaScript framework slowing things down. I'd prefer to add bespoke implementations to my app.
    No. That's just wrong. You should *never* protect server-side (if you're using a pure ExtJS + web services architecture).

    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

  10. #150
    Sencha User
    Join Date
    Jun 2012
    Posts
    8
    Vote Rating
    0
    similian is an unknown quantity at this point

      0  

    Default


    Quote Originally Posted by mitchellsimoens View Post
    This should really be known by all web devs. Never trust the client, don't care if your mom is the only one that should be using it.
    Thank you for your help.

    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.