1. #171
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    577
    Vote Rating
    136
    joeri is a glorious beacon of light joeri is a glorious beacon of light joeri is a glorious beacon of light joeri is a glorious beacon of light joeri is a glorious beacon of light joeri is a glorious beacon of light

      0  

    Default

    Quote Originally Posted by DiscoBoy View Post
    1) What if I use input ExtJS fields, where I would use OUTPUT in the value parameter (checkbox {value: MALICIOUSCODE}). How would you address this?

    2) I have plenty of UI parts where I display server OUTPUT. Wouldn't it be better to sanitize already at the level of receiving the OUTPUT from the server, means overwriting certain MODEL/READER methods to catch malicious code already at the point when I load it from an external resource? This way I need to sanitize once and not for every UI component.

    3) The cheat sheet is quite long, did you implement checks for every mentioned case? Would you share your code? I would imagine this sanitizing is quite costful in processing time

    4) How do you sanitize strings wthat are displayed in grids/trees?
    1. The value is not serialized into html but assigned via the DOM API, so there is no risk for XSS if you assign a value in this way. There is a danger in components that use a template for rendering (combobox, dataview, grid, ...), but this is only for the output of the selected value's label / data.
    2. In my personal opinion if you do this at the model level then you are embedding knowledge about how the view layer operates into your model (because of context-aware encoding). This is not a proper way to separate MVC concerns.
    3. For XSS entity encoding we only use the htmlEncode function (with a tweak, see my ExtJS 3.4.1 overrides on this forum) to generate data for the html or html attribute context (if you use double quotes religiously then you can use htlmEncode's output in an attribute). We never put untrusted data in other contexts. If we need data inside javascript, then we implement a web service to fetch it as JSON data.
    4. Grids and trees use htmlEncode just like anything else. You have to remember to put renderer: Ext.util.Format.htmlEncode on every column.

    You are right in pointing out that htmlpurifier is only good for html text (rich text). For input sanitization of non-html data on the server we have developed a DTO-based solution in PHP which uses static annotations to validate all data in the server-side web service layer automatically. I gave a tech talk about it recently, and there's an example implementation of it that I've put up on github.

  2. #172
    Sencha User
    Join Date
    May 2009
    Posts
    143
    Vote Rating
    6
    DiscoBoy is on a distinguished road

      0  

    Default

    Quote Originally Posted by joeri View Post
    1. The value is not serialized into html but assigned via the DOM API, so there is no risk for XSS if you assign a value in this way. There is a danger in components that use a template for rendering (combobox, dataview, grid, ...), but this is only for the output of the selected value's label / data.
    2. In my personal opinion if you do this at the model level then you are embedding knowledge about how the view layer operates into your model (because of context-aware encoding). This is not a proper way to separate MVC concerns.
    3. For XSS entity encoding we only use the htmlEncode function (with a tweak, see my ExtJS 3.4.1 overrides on this forum) to generate data for the html or html attribute context (if you use double quotes religiously then you can use htlmEncode's output in an attribute). We never put untrusted data in other contexts. If we need data inside javascript, then we implement a web service to fetch it as JSON data.
    4. Grids and trees use htmlEncode just like anything else. You have to remember to put renderer: Ext.util.Format.htmlEncode on every column.

    You are right in pointing out that htmlpurifier is only good for html text (rich text). For input sanitization of non-html data on the server we have developed a DTO-based solution in PHP which uses static annotations to validate all data in the server-side web service layer automatically. I gave a tech talk about it recently, and there's an example implementation of it that I've put up on github.
    Many thanks for your replies!!! It took me a while to answer as other things kept me busy but security must be a number one priority.

    1) Yes, my question was regarding the outputting in text fields. For instance I want to show an user object in an editor view. What you mean is that the normal fields use HTML INPUTS and do not get rendered as <input value="MALICIOUS CODE"> but rather as <input ID="ext-field-12345"> and later set by JavaScript like Ext.get('ext-field-12345').setValue("MALICIOUS CODE"); Correct?
    then I really only need to look at templated fields and this means generally all my views which somehow use a template...

    My thoughts are going towards overriding Templates and Xtemplates and to always call a sanitize() function for each {value} in the template, but this might be to complex as well...what would you advice? (Because I also would like to address templates with iterations, etc. (Example: <for '.'>{value1} {value2}</for>)

    2) Might be an effective place but I agree it doesn't really fit there by the MVC logic. Otherwise MVC doesn't really tell you where to put your security level...although the security issues are caused by the view rendering (HTML)

    3) Thx, I had a look and now use the Ext.String.addCharacterEntities({"code":"char"}) function to add further mappings. You just added "/" to these encoding pairs, but why not to encode more charcters?

    4) I use an extended table class for all my trees andd grids and put the encoding function at the right places. ON the other hand all tables and data view use templates again and the renderers are just inerceptor methods. Again...wouldn't it make more sense to centrally tweak the TEMPLATE rendering and out the encoding there?

    Thx for the github link...I'm looking into this right now :-)

  3. #173
    Sencha User
    Join Date
    Apr 2014
    Posts
    8
    Vote Rating
    0
    rsnickell is on a distinguished road

      0  

    Default

    Has anyone explored fixing the html encoding at the Model level?

    Upon receiving potentially malicious responses from the server that get loaded into stores as records, the record data is ultimately what is applied to the templates in the Ext.view.Table.renderCell and Ext.view.Table.renderRow methods. Examining the fields being used in your model, you can conclude that the Ext.data.field.String field type can be overridden to Ext.util.Format.htmlEncode in the convert method.

    Code:
    Ext.define( 'Ext.overrides.data.field.String',{
        override: 'Ext.data.field.String',
    
    
        requires: [
            'Ext.util.Format'
        ],
    
    
        convert: function(v) {
            var str = this.callParent( arguments );
            return Ext.util.Format.htmlEncode( str );
        }
    });
    The result is that any component using a store for presenting data (grids, trees, etc.) or models (form load) should pickup the strings properly encoded in the resulting markup.

    This approach is only meant to address the presentation aspect of the problem.

    This appears to work in my limited testing against grids/trees.

    Thoughts?

  4. #174
    Sencha - Senior Software Engineer mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    38,211
    Vote Rating
    1045
    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

    I wouldn't override Ext.data.field.String as not every field using String will need to be encoded. Either add a config or extend String to create your own field.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Software Engineer
    ________________
    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.

  5. #175
    Sencha User
    Join Date
    Apr 2014
    Posts
    8
    Vote Rating
    0
    rsnickell is on a distinguished road

      0  

    Default

    Quote Originally Posted by mitchellsimoens View Post
    I wouldn't override Ext.data.field.String as not every field using String will need to be encoded. Either add a config or extend String to create your own field.
    Overriding the field type globally would introduce unneeded encoding. Your suggestion of creating your own field type would be better, and will require each developer to know the new field type exists and must be used.

    The only two options that I can see then are:
    1. a custom field type for encoding strings in the record
    2. mandatory renderer on each column (tree, grid, etc.) that must be specified.
    The first approach modifies the records that will be contained in stores. This could have sorting impact as the records won't contain the raw text. It's also not as close to the final rendering phase. One thing I do like about it, is that developers will have less places to touch reducing the risk of missing a renderer somewhere.

    Using the latter will require a lot of overhead(couple loc for each column and remembering to use htmlEncode in other renderers you implement), but places the html encoding closer to the context in which it will be used.

  6. #176
    Sencha User
    Join Date
    May 2009
    Posts
    143
    Vote Rating
    6
    DiscoBoy is on a distinguished road

      0  

    Default My solution so far

    Thx for feedback on this issue. My solution is not to overwrite all base classes (buttons, fields, titles, etc.) with a proper HTML entity encoding. It works but somehow I wonder why I should do this?

    I still wonder why Sencha thinks ExtJS does not need any way of securing data rendered to the browser for instance by simply converting all data to use HTML entities before the data is rendered in the user's browser?

    Other frameworks do this. ExtJS allows its user to do many security errors! For me a bad design of the framerwork. Would be interested to hear some opionions of fellow coders and the Sencha team.

    Thx!

  7. #177
    Sencha User
    Join Date
    Aug 2011
    Posts
    16
    Vote Rating
    1
    prashantjain68 is on a distinguished road

      0  

    Default

    HTMLEncoding is done to protect the victims and not the perpetrators. I agree, if someone intends to do something wrong, he cannot be stopped.

    We have 4 different front-end applications ... CLI, HTML, Android and IOS. In the future, we may have a Windows Mobile. If I start escaping or stripping out text for every single ui application, I am not sure what would be left in the data submitted by the user.

    Lets also talk about SQL Injection - Should the front end escape values to prevent SQL Injection or is this the job of the database layer? Similarly, should the backend strip out text based on the front-end application?

    I am a firm believer of ... the user should see what he saved to the database. I don't know the intent of what he has typed in. It could very well be a JavaScript code with the intent to share with other users. But I have to protect my other users (potential victims). The best solution would be ... escaping at the point of output (when writing into the DOM etc).

  8. #178
    Sencha User
    Join Date
    May 2009
    Posts
    143
    Vote Rating
    6
    DiscoBoy is on a distinguished road

      0  

    Default

    So you agree with me, that Sencha should by default HTMLencode output written to the DOM, or?

    And you're right. If you start implementing such things for every frontend this becomes a lot of work. I really wonder why Sencha gives no proper answer to this while other frameworks already decided to go down this path...

  9. #179
    Sencha User
    Join Date
    Aug 2011
    Posts
    16
    Vote Rating
    1
    prashantjain68 is on a distinguished road

      0  

    Default

    DiscoBoy,
    We use ExtJS and we are looking into the DOM XSS issues. Here are a couple of things I have noticed/ learnt ...

    - Some Ext widgets need htmlEncoding and some don't.
    - Some html elements need html encoding and some don't. DIV v/s INPUT.
    - Sencha has a mixed approach to HTMLEncoding. I have even seen properties like "htmlEncode = false ". Which means that the encoding is controlled by a boolean flag (for some components).

    To answer your question:
    At this time, I don't know what is the right answer. But I do feel that they should provide a htmlEncode boolean property at a Ext.Component level and developers can set them to true or false and they encode based on this flag.
    So yes, they should give the option to encode values.

    Unfortunately, it seems that some people at Sencha think that values should be sanitized and stored in the database. That would be a very bad design. Basically, there solution does not address all the use cases.

    We have to solve the DOM XSS problem. We will definitely NOT sanitize the values before putting them into the database. We might noop the Ext htmlEncode() functions and do something crazy. No solution yet but exploring different options at this time.

  10. #180
    Sencha User
    Join Date
    May 2009
    Posts
    143
    Vote Rating
    6
    DiscoBoy is on a distinguished road

      0  

    Default

    I agree with you that sanitizing user input is not the solution. Yes, it can help to alert you of hacks, etc. but the accepted solution by many frameworks is to HTML encode output. XSS attacks are something so beginner like and a framework like Sencha which targets business applications not even talking about such common threats is a very bad sign!

    I also found the htmlEncode option only in the DisplayField. Why nowhere else?
    - In tips?
    - In Titles?
    - In the grid?
    - In container content?

    A good solution would be to make these parts of the framework HTML ENCODE aware and let them encode by default! But to leave the option to disable this by a flag (component wise) or by a central constant.

    Sencha! Any comments here?
    You want to be a serious business framework, or?