Securing against XSS type 1 & 2

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Securing against XSS type 1 & 2

Post 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 :)
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post 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.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post 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.
User avatar
s.dot
Tranquility In Moderation
Posts: 5001
Joined: Sun Feb 06, 2005 7:18 pm
Location: Indiana

Post 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.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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 :?
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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...
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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
User avatar
kyberfabrikken
Forum Commoner
Posts: 84
Joined: Tue Jul 20, 2004 10:27 am

Post 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.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Yes. The biggie is a <script> in the <head> section
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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 :)
Post Reply