1. #21
    Sencha User trbs's Avatar
    Join Date
    Mar 2007
    Posts
    310
    Vote Rating
    0
    trbs is on a distinguished road

      0  

    Default


    I'm -0 on 'fixing' this. Everybody should note that the server should always (and i really mean always) clean, validate and shrub input. (Always and Everytime) If escaping would be the default then there will be some people screaming about that Besides a framework should escape everything or nothing (and let the developer escape it himself) one decision and stick with that which good documentation

    But i'm +1 on creating a special section in the Documentation and Learn/Wiki section of the website explaining these kind of web development security issues/pointers.
    I'm part of the Ext Community
    Maintaining: Translations and some Examples
    Developing on: ExtJS Python Builder / Gozerbot
    Places: Ido.nl.eu.org / My ExtSamples / Trbs on Wiki / IRC

  2. #22
    Ext User haibijon's Avatar
    Join Date
    Mar 2007
    Posts
    105
    Vote Rating
    0
    haibijon is on a distinguished road

      0  

    Default


    I know my previous posts may seem a bit brash, I just don't think this thread is about a security issue. Don't get me wrong, XSS are a very real problem, I just don't think client-side default escaping is the answer, and that's really what this thread is about (since an XSS using the grid previously described would require served data to be unescaped).

    Quote Originally Posted by trbs View Post
    But i'm +1 on creating a special section in the Documentation and Learn/Wiki section of the website explaining these kind of web development security issues/pointers.
    I also +1 this. I think that it would also be great to highlight the built-in escaping methods that ExtJS provides, and possibly any security extensions that may developed in the future.

    Maybe it should be a wiki page?

  3. #23
    Sencha Premium Member
    Join Date
    Apr 2007
    Posts
    65
    Vote Rating
    1
    Hani is on a distinguished road

      0  

    Default


    The fix posted by Jack in this thread doesnt actually work, the right fix (or at least one that works for me) is to use a subclass of ColumnModel to handle it. This works in both 1.x and 2.0:

    Code:
    Ext.grid.SecureColumnModel = Ext.extend(Ext.grid.ColumnModel, {
         getRenderer : function(col){
             var c = this.config[col];
             if(!c.secureRenderer){
                 var fn = c.renderer;
                 if(!fn){
                    fn = Ext.grid.ColumnModel.defaultRenderer;
                 }
                 c.secureRenderer = function(val, p){
                   var rendered = fn.apply(window, arguments);
                   return val && val != '' && typeof val != 'boolean' ? Ext.util.Format.htmlEncode(rendered) : rendered;
                 }
            }
            return c.secureRenderer;
         }
    })

  4. #24
    Ext User
    Join Date
    Oct 2007
    Posts
    9
    Vote Rating
    0
    jaanus is on a distinguished road

      0  

    Default


    Validating and escaping input on the server side is a good practice. Combine it with the design where you have only one gateway for all the data sent by the client and you will have a very secure and fast application.

  5. #25
    Ext User
    Join Date
    Mar 2007
    Posts
    2
    Vote Rating
    0
    bidochko is on a distinguished road

      0  

    Default


    Personally I do not think an ExtJS grid component should be responsible for any type of escaping unless application functionality requires it. For example, server might send a valid IMG tag which should be rendered like an image without any escaping, right?
    Of course in some cases escaping is necessary and you have plenty of methods how to do it: Ext.util.Format.stripTags on a client side or doing some server side escaping.

    ~ Andrew Bidochko
    http://mashuptechnologies.com/

  6. #26
    Ext User ofir's Avatar
    Join Date
    Jan 2008
    Posts
    8
    Vote Rating
    1
    ofir is on a distinguished road

      1  

    Default


    Thanks for the solution Hani, I think many people in this thread haven't understood the problem quite well.

    This issue doesn't even have to do with server-side escaping at all, just try entering this in the editable grid from the example: User <user@email.com>.
    The email address magically dissappears because anything inside the <> characters is treated as html, which it shouldn't.

    I hope this gets fixed in the next ExtJS version!

  7. #27
    Sencha Premium Member
    Join Date
    Apr 2007
    Posts
    65
    Vote Rating
    1
    Hani is on a distinguished road

      0  

    Default


    Actually, despite the protestations of some, I'm glad to say that 2.0.1 fixes this issue and adds an autoEncode option to editorgrid, which does all the encoding needed. I'm glad someone saw reason, though I am curious as to what caused this enhancements to happen, despite being told in this thread that it doesnt make sense to add such a config option

  8. #28
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    Tampa, FL
    Posts
    6,955
    Vote Rating
    17
    jack.slocum will become famous soon enough jack.slocum will become famous soon enough

      0  

    Default


    Since it's done on input (not with a renderer), it is a little different. I think it makes for a good compromise, especially since the developer has the option of turning it on/off.
    Jack Slocum
    Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum
    jack@extjs.com

  9. #29
    Ext User ofir's Avatar
    Join Date
    Jan 2008
    Posts
    8
    Vote Rating
    1
    ofir is on a distinguished road

      0  

    Default


    The autoEncode option works as long as you don't send your data to the server on the afteredit event, which I'm guessing it is triggered before the encoding.

  10. #30
    Ext User
    Join Date
    Oct 2007
    Posts
    15
    Vote Rating
    0
    kmbarr is on a distinguished road

      0  

    Default Why Not a Renderer

    Why Not a Renderer


    I don't always want to deal with html-escaped text in my database for sorting reasons, reporting, etc. What am I missing, isn't this as simple as adding a renderer to any vulnerable column, like:
    Code:
    {header:'Venue Name',dataIndex:'venue_name',renderer:Ext.util.Format.htmlEncode},
    I think this is a common-enough requirement, that I'd like to see it simplified by adding a simple htmlEncode (or maybe autoEncode) boolean to the ColumnModel, so the result would look like:
    Code:
    {header:'Venue Name',dataIndex:'venue_name',htmlEncode:true}