
Resolving cross site scripting issues. - rayvega
http://ayende.com/Blog/archive/2010/09/18/resolving-cross-site-scripting-issues.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+AyendeRahien+%28Ayende+%40+Rahien%29
======
joe_the_user
It's javascript injection.

But the clever method of finding the result seems as encouraging as clever
methods for finding null pointers. Sure, try initializing your memory
beforehand to a call to the debugger - (or just 0 and have that trigger the
usual exception handling). Sure you can do this but those null pointers keep
popping up. I'd assume you could find analogy for SQL injection too.

I'm more interested in techniques which prevent this from happening to begin
with. The clever techniques often only help you find stuff you have a good
idea is already there.

~~~
js4all
AFAIK for JavaScript there is no systematic protection like for CSRF (CSRF
token), but the use of a templating engine reduces the risk. You can also
order a scanning service like <http://www.godaddy.com/security/website-
security.aspx>

~~~
kijinbear
+1 for template engines.

Cheap scanning services only go so far. Any sane template engine should
automatically escape all strings when outputting an HTML/XML document, unless
the developer explicitly tells it not to. Django does this perfectly. A lot of
other modern frameworks also has secure defaults.

PHP is a PITA because it is a template engine in some sense, but it doesn't
escape anything by default. PHP's last attempt at something like auto-escaping
was magic quotes, which was an epic failure. The few times I need to write
vanilla PHP, I end up defining an escaping function and use it instead of
echo.

~~~
DanielRibeiro
You shouldn't forget that blacklisting is not enough. Whitelisting is usually
as important (specially for displaying rss full of html), and there are far
fewer open implementations.

------
js4all
Nice trick. I didn't know, that firebug & co support soft breakpoints by
inserting the javascript command "debugger;".

