1. #41
    Ext User Blackhand's Avatar
    Join Date
    May 2008
    Posts
    42
    Vote Rating
    0
    Blackhand is on a distinguished road

      0  

    Default


    Your presentation layer shouldn't be scrubbing input.

    The presentation, particularly with JS frameworks, is sitting on the client, so anyone who could figure out how to do an XSS attack could probably figure out how to bypass the client side scrub/validation.

    It certainly can be added as a nicety, but that is all, your backend needs to make sure input is valid and protect from injection attacks etc. etc.

    Anyway, having Ext by default scrubbing input just means completely unnecessary overhead. The people doing it the right way will have to add an extra configuration setting to everything to switch off the behaviour.

    This is one of those really basic web app design rules, and the most overlooked one (which is why so much of the web is still susceptible to some form of injection), never trust the client.

  2. #42
    Ext User
    Join Date
    Aug 2008
    Posts
    23
    Vote Rating
    0
    Chris503 is on a distinguished road

      0  

    Default


    This is rather lame in my humble opinion.

    I never ever ever (did I mention ever) trust data from a user.

    Run it through and check for SQL injection, XSS, and anything else, check to make sure the entered email is a valid email, make sure the date they entered in the form is a valid date, you should be checking everything upon user submission (server side not client side) not upon display.

    speed alone is worth it, when adding data you are doing the cleaning one time for one record, if you do it client side (grid for example) you are doing it for every record on the page.

    If you are hard set on storing raw unfiltered data in the DB the have your code that grabs data from the db to the cleaning before passing it to ExtJS.

    at the end of the day this is your server side layer not the client side layers job.

    Also if you are set on storing unfiltered data, please please send me your website url, it would be fun to show the negitave impacts this can have on your server.

    I think the "Critical Warning" should be given to the OP clients, that their developer has developed unsecure applications...

  3. #43
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    561
    Vote Rating
    45
    joeri is a jewel in the rough joeri is a jewel in the rough joeri is a jewel in the rough

      1  

    Default


    Can we agree on a set of best practices here?

    My go at it:

    To avoid XSS attacks:
    - If you're saving HTML-marked up code in the database, strip it before storing it of "dangerous code", using something like html purifier.
    - If you're storing plain text, convert it to html entities when rendering (this should be an option to automagically do throughout your rendering layer).
    - Always perform referrer validation (or token validation) once a user obtains a session, so another website can't just use a hidden iframe and "fake" an action from the user.

    To avoid SQL injection:
    - Always use bind variables. If you must concatenate queries together (sometimes it can't be avoided), use the quoting functions of your DB library.

    To avoid mail injection:
    - Use a server-side mailer library that cleans up the user-submitted content so headers are stripped / converted.

    What Ext must do for XSS security:
    - Automatically html-encode server-provided text for rendering (I think this is what the OP was driving at). This should be the default behavior in all cases, but it should be possible to disable it.
    - Offer a mechanism to automatically send a token along with every request (is this possible today?), to avoid hidden iframe XSS attacks. Referrer validation can be implemented purely on the server-side, but it is less secure.

  4. #44
    Ext User
    Join Date
    Aug 2008
    Posts
    10
    Vote Rating
    4
    caustic is on a distinguished road

      0  

    Default


    Quote Originally Posted by Chris503 View Post
    Also if you are set on storing unfiltered data, please please send me your website url, it would be fun to show the negitave impacts this can have on your server.
    Take for example this forum. Or any Drupal installation. By the way, read Handle text in a secure fashion from its documentation.

    When handling and outputting text in HTML, you need to be careful that proper filtering or escaping is done. Otherwise there might be bugs when users try to use angle brackets or ampersands, or worse you could open up XSS exploits.
    When handling data, the golden rule is to store exactly what the user typed. When a user edits a post they created earlier, the form should contain the same things as it did when they first submitted it. This means that conversions are performed when content is output, not when saved to the database.

  5. #45
    Ext User
    Join Date
    Aug 2008
    Posts
    10
    Vote Rating
    4
    caustic is on a distinguished road

      1  

    Default


    Quote Originally Posted by joeri View Post
    What Ext must do for XSS security:
    - Automatically html-encode server-provided text for rendering (I think this is what the OP was driving at). This should be the default behavior in all cases, but it should be possible to disable it.
    Several people have already suggested this behavior for ExtJS, and I'm for it too.

  6. #46
    Sencha - Community Support Team jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    DC Area =)
    Posts
    16,364
    Vote Rating
    81
    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


    a couple of overrides should be easy to craft to create this behavior.

  7. #47
    Ext User
    Join Date
    Apr 2008
    Location
    Lincoln, NE
    Posts
    235
    Vote Rating
    0
    jpnet is an unknown quantity at this point

      -1  

    Default


    I don't understand why there is such a debate about this. Web security 101 states that the server should not trust ANYTHING submitted by the client. Therefore, it's pointless to include "scrubbing" functionality in ExtJS and even more foolish if your server side code trusts the "scrubbing." Any user can install Greasemonkey/Firebug and change the behavior of a piece of javascript code.

    -JP

  8. #48
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    561
    Vote Rating
    45
    joeri is a jewel in the rough joeri is a jewel in the rough joeri is a jewel in the rough

      1  

    Default


    jpnet, I think the debate isn't about scrubbing when submitting data to the server, but about scrubbing / escaping when showing data fetched from the server to the user. This is not really about security, but more about convenience.

  9. #49
    Ext User
    Join Date
    May 2008
    Posts
    16
    Vote Rating
    1
    naapuri is on a distinguished road

      1  

    Default


    This seems to be a fundamental decision by the Ext team to ignore the XSS problem by forcing the user to remember to type all these encodeHtml calls *everywhere*. And this isn't only about the Grid component. It's everywhere. And yes, it IS a feature, too - it's very handy to be able to put html code to a checkbox label or a grid column header. But in order to make it easy to write secure applications, it just should be an explicit choice by the user, not the default action.

    Take the Ext Template sample: http://extjs.com/deploy/dev/examples/core/templates.js

    If this was a real-world application, the data would be delivered from the server with JSON or XML. It's fair to assume that the data itself is "plain-text". So why should the server-side JSON/XML encoder part care for HTML encoding? It shouldn't. The renderer should. IMHO, the data transfer format should as clean as possible.

    Of course, there is a solution in the Template system. Just remember to type {var:encodeHtml} in EVERY variable. I think this is where it goes wrong. Security should be "switched on" by default, so the user could only *intentionally* break the model. (Maybe here by something like "{var:raw}".

    I think most other frameworks do the sane thing by default. This is another reason why this is dangerous: people are more or less used to a "secure by default" kind of model.

    Ext.js is naturally impossible to fix now, since it would break many applications. My suggestions:

    * Fix the Ext.js examples to CLEARLY point out how to write XSS safe code. For example, in the Template sample, add an entry with the text "foo & bar" and add :encodeHtml to every var output in the template. OR: Add an entry with the text "foo & bar" and write a comment saying "NB! For XSS safety, all the data has been html encoded in the server". All examples should be as simple as possible, but security isn't something that can EVER be left out "for simplicity".

    * Fix the API docs in the same way.

    * For Ext 3.0 (?), the possibility of a "secure by default" model should be researched. It would be a massive, incompatible change.


    For now, I'll continue writing the encodeHtml calls everywhere - both server-side and client-side. Maybe I'll just use Apps Hungarian notation (usFoo and sFoo for unsafe and safe strings) for all variable names.

  10. #50
    Ext User
    Join Date
    Mar 2007
    Posts
    67
    Vote Rating
    0
    ApocalypseCow is on a distinguished road

      0  

    Default


    So the default behaviour would be that your server would knowingly send unsafe data to the client for cleanup/display? sorry but that doesn't sound right to me.