1. #1
    Ext User
    Join Date
    Aug 2008
    Posts
    2
    Vote Rating
    0
    Eduardholmes is on a distinguished road

      0  

    Default ExtJS lack of html encoding

    ExtJS lack of html encoding


    Hi All!,

    I'm currently evaluating using ExtJS for some of my projects and I must say it is great, the quality of the UI accomplished is amazing, and it is also very easy to use.

    However, I have a 'security concern'; it is easy to solve but I'm wondering what are the thoughts of the creators of the library about this because this to me sounds like a design decision:

    With the little experience I have using ExtJS, I have noticed that mostly the whole library does not do anything (or very little) to, for example, html-encode content.

    For example, if I use a ComboBox using a javascript array as a store, the content of the array is not html-encoded before displaying it.

    This means, that, for example, I need to specifically create code to html-encode the content to be displayed in the ComboBox before sending this data to the ExtJS ComboBox control, for example:

    aText = document.getElementById('mytext').value;
    document.cookie = 'acookie=test;expires=Tue, 18 Dec 2012 11:00:00 GMT';
    var myData =[[aText,'david'],['john','laporte']];
    var mystore = new Ext.data.SimpleStore({
    fields: ['firstname','lastname'],
    data: myData
    });

    var c = new Ext.form.ComboBox({
    store:mystore,
    typeAhead:true,
    mode:'local',
    forceSelection:true,
    triggerAction:'all',
    selectOnFocus:true,
    displayField:'firstname',
    applyTo:'combobox-local'
    });


    myData contains aText, which was obtained from the user.

    If I don't create code myself to html-encode this string before sending it to the ComboBox control, the ComboBox will not do it and I'll end up with a cross-site scripting vulnerability, or at least, html/javascript code will be rendered when it shouldn't be the case, because I should be able to trust the ComboBox to treat 'strings' as 'strings' and not have to think about the possiblity of these 'strings' becoming HTML/javascript code.

    It would be easier for the ComboBox to this for me instead of me having to think about this every time I use the control. I think the current behaviour is verry error-prone.

    For example, most frameworks like .NET have also 'web controls' and they take care of encoding data passed to them before displaying this data to the user; what effectively prevents the issue I'm mentioning; and takes away the burden of thinking about this away from the programmer and puts the trust on the framework instead (which is good from a security standpoint).

    Of course, in this simple scenario the user would be 'attacking himself', but let's think about a multi-user scenario, where, for example, user1 enters his realname and that's gets stored as part of his/her profile in the database.

    Then, another users logs into the app, user2, and wants to see the list of users including their real name; the app then goes to the database, obtains the real name for every user, and displays back that info to this othe user (user2) in ExtJs ComboBox.

    If the application did not encode the 'realname' before storing it into the database, or before sending the 'real name' to the ComboBox, this will allows user1 to execute javascript code in the context of user2; this is a xss vulnerabillity.

    Like I said, yes, a web app can encode this information before storing it into the database, or before sending it to the, for example, ComboBox control; but by the experience of using other frameworks I would expect the presentation library would do it for me.

    Yes, I know ExtJS is a javascript library (client-side) and .NET is both a server-side/client-side library, but I believe the example is still valid.

    I'd love to hear what you think about this.

    Thanks in advance!.

  2. #2
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,353
    Vote Rating
    77
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    If data needs to be encrypted/encoded, that's traditionally left up to the end developer.

  3. #3
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,353
    Vote Rating
    77
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    By the way, if data should be encrypted, SSL should be used. Also, if Ext was required to decode data, how does Ext know which algorithm to use? Being that it's a client side library, it's not feasible for them to support one or any.

  4. #4
    Ext User
    Join Date
    Aug 2008
    Posts
    2
    Vote Rating
    0
    Eduardholmes is on a distinguished road

      0  

    Default


    I'm talking about HTML-encoding to prevent xss vulnerabilities, I'm not talking about encryption/decryption.
    I think you understood wrong.

    Thanks!

  5. #5
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,353
    Vote Rating
    77
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    Quote Originally Posted by Eduardholmes View Post
    I'm talking about HTML-encoding to prevent xss vulnerabilities, I'm not talking about encryption/decryption.
    I think you understood wrong.

    Thanks!
    you're right, i'm retarded :P

    .

  6. #6
    Ext User
    Join Date
    Oct 2007
    Posts
    25
    Vote Rating
    0
    Neville Burnell is on a distinguished road

      0  

    Default


    FWIW, most of my work is with Ruby on Rails.

    In that framework, the emphasis is on the serverside to review, validate, strip, and encode data received from the browser before storing on the server [in a dbms say].

    The idea being that the browser cannot be secured, so all effort is put into securing the server.

    HTH

  7. #7
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,496
    Vote Rating
    44
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    If you manually specify the Template for your ComboBox, you can specify HTML encoding:

    http://extjs.com/deploy/dev/docs/?cl...Box&emmber=tpl

    Type the following into your Firebug console command line:

    Code:
    new Ext.XTemplate('{foo:htmlEncode}').apply({foo: '<span>bar</span>'})

  8. #8
    Sencha User
    Join Date
    Feb 2010
    Location
    Batam, Indonesia
    Posts
    2
    Vote Rating
    0
    computeraholic is on a distinguished road

      0  

    Default


    Code:
    var dirtyName = '<b>Member Name</b>';
    var cleanName = Ext.util.Format.stripTags(dirtyName);

  9. #9
    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


    +1 with regards to using server side security. A server is a controlled environment, where as the client browser and OS is out of your control.

  10. #10
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    555
    Vote Rating
    27
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      0  

    Default


    We've been over this topic many times.

    Anyway, I fall squarely in the "ext should encode by default" camp, and I'll list my argument:
    1. You shouldn't store html-encoded data in your server, because you may need to present it in different contexts than a web context (I write a web app that has a windows native counterpart displaying the same data).
    2. If you're using an RPC-like API to access the server (e.g. Ext.Direct, or JSON-RPC in my case), you shouldn't encode on the server, because you may have non-web clients accessing the same server API.
    3. Encoding for output is a view layer responsibility, in an Ext app the view layer rests fully on the client.
    4. Despite what I've heard many times, encoding on the client is neither slow nor insecure.
    5. If you're encoding on the client, Ext forces you to write a lot of boilerplate code to do that. Boilerplate code is a potential for bugs. Ext's design in this respect encourages bugs, and even worse, they are bugs that potentially expose XSS issues.