Results 1 to 5 of 5

Thread: Security Issue with input in Grids and how to avoid it?

  1. #1
    Ext User
    Join Date
    Sep 2008
    Location
    Germany
    Posts
    961
    Vote Rating
    1
      0  

    Default Security Issue with input in Grids and how to avoid it?

    user moldoe point in his thread http://www.extjs.com/forum/showthread.php?t=85345 about html in headers also to one other interesting issue:

    a user input is rendered as html:

    try it yourself here:
    http://www.extjs.com/examples/explor...l#editablegrid

    enter in column "company name":
    PHP Code:
    Company Name <a href="#" onclick="alert('hello');"click </A
    i think in this case it is a security problem and it should switched off by default.

    and give a addtional switch to allow it like:
    PHP Code:
    setHtmlDecodeUserInput(false
    Attached Images Attached Images
    This forum needs your help: you got hints from the community and now you have fixed your code? dont just reply with "now its fixed" or "i found the error"! please take the time to post also an detailed answer with the working code.

    GreaseMonkey Script for a GXT-only Forum: it hides ExtJs here: New Posts Search Results Advanced Search form Category overview http://www.extjs.com/forum/showthrea...041#post410041

  2. #2
    Sencha Premium Member
    Join Date
    Sep 2007
    Posts
    13,976
    Vote Rating
    131
      0  

    Default

    You should never ever trust data from users. There are valid points when you want to allow this. You can override postprocessvalue of the editor to encode it, if you need it encoded.

    As the framework can never know, if you need it encoded or not, there is no way we can do this. It is up to the developer to decide, if you want to allow this or not.

  3. #3
    Ext User
    Join Date
    Sep 2008
    Location
    Germany
    Posts
    961
    Vote Rating
    1
      0  

    Default

    but for the security reason the grideditor should by default encode it. and not the other way.
    This forum needs your help: you got hints from the community and now you have fixed your code? dont just reply with "now its fixed" or "i found the error"! please take the time to post also an detailed answer with the working code.

    GreaseMonkey Script for a GXT-only Forum: it hides ExtJs here: New Posts Search Results Advanced Search form Category overview http://www.extjs.com/forum/showthrea...041#post410041

  4. #4
    Sencha Premium Member
    Join Date
    Sep 2007
    Posts
    13,976
    Vote Rating
    131
      0  

    Default

    No it should not. You, the developer, are the only one that knows if it should do that or not. There are valid reasons to allow markup. This change will even brake the examples.

    The editor has a postprocessmethod that you need to override if you are not trusting the user input.


    The underlaying framework can never know what you want to do with the data. So it should NEVER EVER change it.

  5. #5
    Ext GWT Premium Member
    Join Date
    Jul 2008
    Posts
    101
    Vote Rating
    0
      0  

    Default

    I understand both of your arguments.

    Why can't GXT just have one global switch like GXT.setXSSSafe(boolean)?
    This would be perfectly backwards compatible and the users of the lib could decide what they want to do?

    I would prefer that all components in the framework are XSS Safe by default and when I am really sure, that there's no problem, I'd switch this off for those (few) cases (or call another function)

    to make this point more clear

    e.g. TabItem.setText() uses setInnerHtml under the covers: which is really nasty: then the function should at least be called TabItem.setHtml()!!
    so we, as your users, must be aware of all the places in your lib where you use setInnerHtml() - you must admit that this really unsexy..


    • myGrid.setXSSSafe(true/false)
    • myTabItem.setXSSSafe(false) or maybe
      • myTabItem.setText()
      • myTabItem.setHtml()

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •