[Security] XSS attacks for Extjs Applications - critical warning

[MrSparks]

@joeri,
Incorrect, you should always have Server Side protection/validation/encoding/decoding etc to ensure that the data that’s being sent or received by the client is as you require/is to the specification you impose.

You are right to say there is no single way to encode, the dev must come up with the correct method to suite the data.

You are also (sort of) right to say that having multiple methods is an overhead. A simple condition check (server side) is all that’s needed to determine if the data being sent from the client is to spec.

Remember, you should always have both client and server side protection/validation/encoding/decoding etc in applications. The client can “NEVER” be trusted, therefore the last bastion of protection and control is the server.

The Server is under your control, the Client is not.

[evant]

@joeri We're looking at having some kind of global config that will htmlEncode <stuff>, the things that immediately spring to mind are grids/trees/combos, however it's difficult to know where to draw the line for this (think templates, renderTpl, Element.update).

[joeri]

You are right to say there is no single way to encode, the dev must come up with the correct method to suite the data.

Please don't confuse data with context. You encode to suit the context. The context is separate from the type of data. For example, I may show a user's first and last name in a tooltip (HTML attribute) and in a panel (HTML element). In that case I have to encode the same data in two different ways. According to you I would be sending the same data twice from server to client. That's a hack in my opinion.

I come from the perspective of having shared web services between ExtJS and Android / iOS. The web service has to return data in unencoded form for the mobile platforms. In this example I would have to send the data in three different formats. Ugly, ugly, ugly. And completely unnecessary, because...

Remember, you should always have both client and server side protection/validation/encoding/decoding etc in applications. The client can “NEVER” be trusted, therefore the last bastion of protection and control is the server.

The Server is under your control, the Client is not.

That is true but irrelevant in this discussion. You say that encoding on the server is safer because the client cannot be trusted. What is to prevent a user from having an ExtJS override that automatically de-encodes the data coming back from your web service before it gets injected into the page? Bingo: "XSS attack". But that's not what XSS is.

XSS protection is about protecting your user against hidden page modification by a stranger. The only "trust" you need to have here is that your or your user control all changes to the page. In other words, you need to trust that the ExtJS code you're sending isn't modified in transit, and that no other code gets injected into the page. Encoding on the client can guarantee that just as easily (in fact more easily) as encoding on the server.

What you are right on is that the client cannot be trusted to send valid data back to the server, which is why the server always must do input validation and authentication / authorization checks. But that's an orthogonal issue from XSS, which is best solved on the client.

[similian]

I would like to be more clear. My problem is not that EXT JS does not support proper html encoding in some places. Its more serious.

Ext Js breaks in simple json data containing " characters.

For example:
the following json:

{        "name": "this is some awesome object",
         "description": "containing a secret html property i will not show to anyone",
        "otherAttribute": "poop \" goes the weasel !"
}

This is valid JSON

Suddenly when I call the store. My page halts.
I look into the source and in some strange place i find this.

<div internalid="201911863024" 
raw="
name:this is some awesome object;
description:containing a secret html property i will not show to anyone;
otherAttribute:poop " goes the weasel !.....

suddenly the page shows ' goes the weasel !'

As you noticed the " is unescaped very well. Yet not reencoded internally.
Which breaks the page, and this is a XSS threat not created solely by the ui yet very much encouraged by it.

This is where I have to start developing server side responses that fix my not so smart ui.
And quadruple reencode double quotes.

[MrSparks]

XSS protection is about protecting your user against hidden page modification by a stranger.

That’s an Interesting way of looking at it but it's placing the trust on the user, which of course you can never do. Fundamentally if the sever side controls have been developed correctly, there is no way a stranger could have injected malicious content into the data in the first place. Of course there’s always man in the middle attacks but that’s a different problem.

Am I right in thinking that your issue is, you are potentially connecting to untrusted sources of data (web services etc provided by someone else) and you are worried that someone might have compromised that data?

If that’s the case you will need to add a server side layer for XSS protection between EXT JS and the untrusted source.

[joeri]

That’s an Interesting way of looking at it but it's placing the trust on the user, which of course you can never do.

You are supporting my argument. The user can always mess up his own page, regardless of what you do on the server.

Let's go into specifics, please explain how this code can be hacked:

success: function(data) {
   panel.body.update(Ext.util.Format.htmlEncode(data));
}

echo $DB->fetchOne("SELECT TEXT FROM MYDATA WHERE ID = :id", array("id" => "1234")); 

(Assume that htmlEncode follows the encoding rules of the ESAPI encoder, which it doesn't right now.)

[MrSparks]

Let's go into specifics, please explain how this code can be hacked:

In its simplest 101 form....

Right click, save page as, edit page / recraft the source path's and adjust the code to suite your malicious needs, save changes, run page.

[joeri]

OK, now explain why this code can't be hacked the same way:

success: function(data) {
   panel.body.update(data);
}

echo htmlentities(
$DB->fetchOne("SELECT TEXT FROM MYDATA WHERE ID = :id", array("id" => "1234")),
ENT_QUOTES); 

[MrSparks]

You've listed server and client side code. Are you just talking about 1 or both?

[joeri]

You've listed server and client side code. Are you just talking about 1 or both?

I'm talking about the interaction between client and server.

I'm trying to get my point across that encoding on the server doesn't offer more protection against XSS than encoding on the client. Any scenario you think up that involves someone hacking the client-side encoding can equally apply to a situation where the encoding happens server-side.

If you're encoding on the server your code can be made as secure as when you're encoding on the client. But I maintain that it's the wrong place because its further removed from the rendering code, and the rendering code is the only code that really knows which encoding context is the current context. The risk for security issues is bigger, not smaller, if you're encoding on the server.