Page 1 of 1

Securing against XSS type 1 & 2

Posted: Wed Nov 14, 2007 6:32 pm
by alex.barylski
I have spent some time considering where best in a application to secure incoming data which is then output to screen, using htmlentities or htmlspecialchars.

The answer will likely vary greatly depending on the architecture you have developed for your application, however assuming a model 2 (MVC) implementation, where do you feel it is best to secure against XSS?

For simplicity I will focus on the one kind of scernario: PHP code outputs dynamic URL's for example, pagers (next, prev, home, last, etc).

Code: Select all

echo '<a href="index.php?page='.$_GET[''page].'"'>Some Link</a>;
Here are my list of possible remedies:

1) Use JS to secure all XSS exploits.

How: Execute a quick filter on all href/src attributes and convert all special characters into HTML entities.

Advantages: Easy to implement, easy to track, centralized, and only executed when JS enabled - XSS doesn't apply when JS disabled?

Disadvantages: Possibly convert intentional href/src attributes with entities, thus rendering some intended functionality useless? This could possibly be avoided by simply following convention of *NOT* using inline javascript in href, etc.

Wrong:

Code: Select all

<a href="javascript: alert('Hello World')">Say Hello</a>
Basically the gist of the idea is to only ever have URL's which point to valid addresses without any JS so converting HTML entities would have no negative effect???

2) Use template helpers.

I was poking around the sypmphony docs the other day and stumbled upon their template helpers section. Similar to Smarty I'm not sure I see *real* value behind using those helpers over just punching out the HTML manually, but...

If you had a template helper such as:

Code: Select all

make_link($href, $title, $class, $id);
Because of the issue of XSS has recently sparked my interest, I can now see an easy "centralized" method to securing incoming data before being directly output to screen for re-rendering.

You could possibly call htmlspecialchars() inside the helper and thus not worry about XSS so long as you call this helper when generating each link.

Advantages Centralized location.

Disadvantages: Requires strict developer discipline to always use template helper and not echo href/src elements directly. Additionally it may have some unnessecary processing on server if the first method is accurate and valid.?.

3) Secure in model/controller

The last time I asked a similar question in these forums I had a few relies suggesting the model was the location to secure incoming data, likewise, at the time I was securing this data in the controller.

The advantages and disadvantages are to specific to your MVC implementation, so I will leave those details out.

All I have to say, is that it has never made sense to me to secure data in the model, if it's not particularly model data, such as the page index counter used in pagination scripts, etc.

Where do you feel it is best to secure you HTML from XSS epxloits???

Cheers :)

Posted: Thu Nov 15, 2007 1:19 am
by John Cartwright
The view, of course. Most decent framework setups will try to make escaping the information as seamless as possible. Instead of having your view variables explicitly escaped, make that the default behavior.

Just want to make a note: javascript is not the only form of XSS injection (html in forms) and using javascript as a form of protection should never be relied on.

Posted: Thu Nov 15, 2007 1:26 am
by John Cartwright
Just want to clarify a bit why I said the view.

The main reason is because you do not want the data to persist as htmlentities()'ed throughout your application. Lets say you immediatly htmlentity() your data and pass it along to the model to be saved in the database.. then you'll be storing the entitied version of the data, and not what was originally given. By only applying the escaping during output, you maintain the original data without the threat of XSS injection.

Posted: Thu Nov 15, 2007 3:20 am
by s.dot
Yeah, the view, definitely. Most templating engines even come with built in functions (similiar or identical to php's excape functions) to escape data.

Now, whether you'd do it in php

Code: Select all

$tpl->assign('link', htmlentities($link, ENT_QUOTES));
or in the tpl

Code: Select all

{function($link)}
I don't know.

When making my decisions on where to put something like that, I think to myself "is it aesthetics, or functionality". It's a tough call in this case. You are potential changing the data (the look of it), but in itself that provides no functionality, although, overall, it provides the functionality of a more secure application.

Posted: Thu Nov 15, 2007 5:38 am
by Jenk
number 1 is void, you cannot, under any circumstance, rely on JS.

I'm sure this is about the 5th thread in a row asking at which point in the application is it best to escape/filter data :?

Posted: Thu Nov 15, 2007 11:25 am
by Maugrim_The_Reaper
Probably because the Zend Framework does it the second the data is filtered by default ;). You either have to disable the default filter-then-escape method, or reverse it (ugh) before it hits a Model.

Javascript is useless - it's too limited in scope, and too easily messed up by browsers or caching.

Escaping is usually best done in the View, before anything's outputted. Template engines usually have an escape() method or tag (whether view helper or not) for the purpose. If you only send scalar data to the View, there's the possibility of automating escaping to some degree so it's less a manual burden.

Posted: Thu Nov 15, 2007 2:48 pm
by alex.barylski
While I agree it makes most sense to secure data in the "view". Does this not still require developer discipline to call the appropriate escape methods?

I'm wondering if just running your whole output buffer through HTML_Purifier would do the trick - convience at the sake of performance but at least security in tis regard is handled in a single location. Easy to enabled or disabled, etc...

Posted: Sat Nov 17, 2007 12:13 pm
by Ambush Commander
Hockey: That would fail completely, for two reasons:

1. Legitimate scripts you'd want in your application (i.e. Javascript YOU wrote/linked to) would be scrubbed out
2. HTML Purifier doesn't currently support validating full HTML pages, only the stuff inside BODY tags

Posted: Sat Nov 17, 2007 12:43 pm
by kyberfabrikken
Maugrim_The_Reaper wrote:If you only send scalar data to the View, there's the possibility of automating escaping to some degree so it's less a manual burden.
You can do this with objects too. Just create a proxy around it, which returns scalars escaped and objects as wrapped in (new) proxies.

Posted: Mon Nov 19, 2007 4:06 pm
by alex.barylski
Hockey: That would fail completely, for two reasons:

1. Legitimate scripts you'd want in your application (i.e. Javascript YOU wrote/linked to) would be scrubbed out
2. HTML Purifier doesn't currently support validating full HTML pages, only the stuff inside BODY tags
I don't use inline JavaScript so anything cleansed inside href/src links would be fine.

As for the second point. Do XSS exploits occur in any place other than <body> - at least under the context of type 1 and 2 that I specified?

Posted: Tue Nov 20, 2007 2:36 pm
by Ambush Commander
Yes. The biggie is a <script> in the <head> section

Posted: Tue Nov 20, 2007 4:25 pm
by alex.barylski
I'm missing something.

I don't use inline javascript (intentionally) so running my HTML through any cleaner (HTML purifier or not) such as a regex which htmlspecialchars() on each href wouldn't cause any undesired side effects.

I strip all <script> tags from incoming data so I fail to see how any XSS exploits could be carried out, DOM injection or otherwise.

I dought I would use HTML purifier on an HTML source, as I imagine it's slightly faster to just use some simple regex to escape href attributes.

I actually occasionally use inline javascript (I take what I said back) however it's usually inside an onlick with hardcoded values which cannot be manipulated by end users, such as common XSS exploits which inject into href tags used by pagers, etc.

I understand that HTML purifier by itself is not a secure solution, however considering my conventions and approach, how is this insecure?

Cheers :)