Securing against XSS type 1 & 2
Posted: Wed Nov 14, 2007 6:32 pm
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).
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:
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:
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
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>;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>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);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