[Security] XSS attacks for Extjs Applications - critical warning

[caustic]

And what about if you will show html in any case? In my opinion you have to know wich html tags are valid. For example <b>, <i>, <a> and so on. You have to eliminate <script> Tags on the backend for preventing XSS...
Another reason, if you do this in frontend (in case of ExtJS it is meaning by JavaScript) i can annul this mechanism by my XSS attack. Thats another reason for doing this on backend, wich is almost saver than frontend...

This case is very uncommon, so this is why by default ExtJS should encode every piece of user supplied data prior to displaying it, but have options to configure it to behave in insecure way just for some widgets when developer decides to.

We want ExtJS be secure by default. We don't want to reconfigure every single widget with the appropriate formatter by hand. Don't you get it?

[hendricd]

@naapuri -- Your various use-cases are dizzying (to me anyway).

On the one hand, we acknowledge that:

Servers SHOULD remove any markup they receive from clients (thus eliminating the need to escape anything outbound to clients). But, what if the server is a CMS (where markup/visual context is important the next time it's delivered)? Would you HTML-escape the content from a CMS engine? Probably could ?

Clients COULD remove any markup from data streams intended for servers (if not a CMS?).

Clearly, the client-side developer plays a pivotal role in enforcing any rules and interpreting decoding requirements.

My point is, that it's just not practical for a client-framework (like Ext) to make broad decoding decisions in isolation. The developer must ultimately decide whether its appropriate to deal with servers rules (either accept no markup in responses or always HTML-escaped eg. render anything in such a fashion that might cause something to '<blink>').

I'd like to hear how you would fix 'the <b>foo problem' I mentioned earlier.

I'd need to understand what you believe is broken first, but wouldn't you just override the Editor class or column editor instance to achieve the degree of safety you're after?

What if the developer decided to base64 encode everything to/from that grid cell?

A frame-work can't make that blanket decision for you, could it? Should it?

[caustic]

On the one hand, we acknowledge that:

Servers SHOULD remove any markup they receive from clients (thus eliminating the need to escape anything outbound to clients).

No, we do not acknowledge that silly decision. Consider the following example: It is ok for the same server to serve both desktop and web applications at the same time. In this scenario it is the ExtJS client's responsibility to encode all user data received from the server prior to displaying it to avoid XSS attacks. Desktop client simply does not bother about this kind of vulnerability.

I don't understand why so simple question sparkles so much debate. It seems like people wrongly assume that:

• Data on the server should be stored in encoded form so that web clients don't bother encoding it.
• It leads people to believe that it is the server's responsibility to encode user data received from web client prior to storing it in the database, otherwise it would be trivial to override web client's behavior (with help of FireBug or os) and expose that application to all sort of problems.

But this is plain wrong for a number of reasons. I've already provided one.

Under no circumstances web server should store escaped data in the database. Instead, every time a ExtJS client displays that data received from the server it should take care to format and sanitize it properly.

Please don't be confused about direction of data flow.

Whatever data users enter in an application, simply store it as is. Every single frontend must take care to escape that data and format it properly just before displaying it. Everything else is insecure by default.

EDIT
User entered data is still subject to business rules validation, but that is completely orthogonal problem to XSS attacks.

[mschwartz]

Any time you let users enter anything into a text box or text area, etc., you are at risk of XSS. vBulletin constantly releases new updates to fix XSS exploits, because there's so many places (like on member pages, in PMs, etc., etc.) you can enter malicious tags that can be displayed to another user. It's quite a challenging problem.

I do not think that the data should be scrubbed before going into the database. I like to do a mysqldump and grep through the ascii text for malicious looking tags to see what users are doing... The argument that the content may not be for HTML/Browser consumption is quite valid as well.

ExtJS should have nothing to do with scrubbing content. You can scrub it on the server side, which is expensive IMO, or you can scrub it on the client. For grids, you have renderer which can scrub the content before it gets rendered. Perfect! For fields you know are user entered, scrub the content.

[joeri]

For grids, you have renderer which can scrub the content before it gets rendered. Perfect! For fields you know are user entered, scrub the content.

The question isn't whether you can make it secure, it's whether it should be secure by default. The grid's default renderer uses the raw data value, while it could just as well use the htmlEncode renderer and save everyone a lot of pointless typing.

Sure, you can monkey-patch Ext so it defaults to a htmlEncode renderer, but that's besides the point. You would assume a toolkit like Ext to "do the right thing" by default, and it doesn't.

[mschwartz]

The question isn't whether you can make it secure, it's whether it should be secure by default. The grid's default renderer uses the raw data value, while it could just as well use the htmlEncode renderer and save everyone a lot of pointless typing.

Sure, you can monkey-patch Ext so it defaults to a htmlEncode renderer, but that's besides the point. You would assume a toolkit like Ext to "do the right thing" by default, and it doesn't.

The "right thing" is for ExtJS to not make any assumptions about what we're trying to render.

I assure you that monkey-patching it to undo any scrubbing ExtJS would automatically do would be far more painful than doing the scrubbing for the few user entered fields you need to protect from XSS.

The <B> tag and <email@domain.com> issues are trivial:

renderer: function(value) { return value.replace(/</g, '&gt;'); }

[Mike Robinson]

As usual, there is a flip-side to all of this: there are two computers involved here, not just one. We do not want to allow the user to insert undesirable content, and we do not want the content that they do provide to become "lost in translation."

For instance, the bulletin-board software allows me to do this:

"I am currently having a problem with the <b> tag."

If you look at the HTML that your browser received, you'll see "&lt;B&rt;" ... and you will also see how I was able to insert a couple of HTML meta-symbols of my own into this text! At no point is the host or (your) client-system becoming confused. (You can clearly see what I said "you'd see," even though a special-character must have been generated in the output in order to successfully represent a literal ampersand.) It all "just works," and that's what keeps the good folks at Jelsoft Enterprises in gravy-and-biscuits (but minus more-than-a-few hair follicles, no doubt).

So... who's "responsible" for this magick? Well, both computers are: yours, and theirs. The responsibility cannot rest with "only one of the two," or you'll wind up either with the opportunity for injection or the corruption of legitimately-entered special characters. The paradox of this whole situation is that... ExtJS (literally, "by definition ...") can't successfully address the issue "on its own."

[jburnhams]

It seems like it would be helpful to newcomers for Ext to provide config options for user facing components to toggle the automatic encoding of html entitities when displaying. For people who want their javascript to handle this it's currently a fair bit of work to create overrides / renderers / templates for all components to encode everything before display and they may not have the option of altering the backend to do it before sending.

[naapuri]

hendricd wrote:

Quote:
I'd like to hear how you would fix 'the <b>foo problem' I mentioned earlier.
I'd need to understand what you believe is broken first, but wouldn't you just override the Editor class or column editor instance to achieve the degree of safety you're after?

How I think that the example is broken: if I try to input the string "<b>foo" in a text field, it is displayed as a bold "foo", not as "<b>foo".

mschwartz wrote:

The <B> tag and <email@domain.com> issues are trivial:

renderer: function(value) { return value.replace(/</g, '&gt;'); }

Yes, this will fix the particular problem. (I'd use the htmlEncode() function, though.)

This fix implies not html escaping the data on the server (when requested via a JSON or XML request) - which has been my point of the whole discussion.

[hendricd]

I'll likely regret rekindling this, but I gave some thought to the dilemna, as it were, and from Ext's standpoint, flexibility on the entry side solves one-half of the problem.

VTypes seemed like a logical focal point, so I'll offer this one. It's designed for optional rigidity, and undoubtedly could be improved.

The focus here is a step towards disallowing 'dangerous markup' in the first place.

(function(){

    // Protect these from Firebuggers

   /* Basic: standard markup tags as: <br>  
    */
    //var safeAlphanumRe =  /<\/?[^>]+>/;
    
   /* Rigid: standard markup tags AND those structured as: &lt;br /&gt;  OR &lt;br> 
    */
    var safeAlphanumRe = /(<|\&lt\;)\/?[^>]+(>|\&gt\;)/;

    Ext.apply(Ext.form.VTypes,{ 
    
       safeAlphanum: function(value, field){
           return !safeAlphanumRe.test(String(value));
       },
       safeAlphanumMask : /[a-z0-9_]/i,
       safeAlphanumText : 'This field should only contain letters, numbers, _, and NO markup'
    });
})();

The safeAlphanumMask could be further hardened to disallow < > ; etc, but I was after a more passive approach without hindering CMS and the like.

On the rendering side: Ext.util.Format.stripTags does an OK job cleaning things up before display (but does not consider HTML-encoded strings).

Feel free to use it where you think it's appropriate. And by all means, tweak it match your servers' appetite.