WebApp Sec mailing list archives

Re: Preventing cross site scripting


From: "Tim Greer" <chatmaster () charter net>
Date: Thu, 19 Jun 2003 19:36:20 -0700



----- Original Message -----
From: "Andrew Beverley" <andy () andybev com>
To: <webappsec () securityfocus com>
Sent: Thursday, June 19, 2003 10:54 AM
Subject: Preventing cross site scripting


I am currently writing a web application that, as a small part of it,
needs to display an email message. Obviously the message is potentially
in html format, which to display could be sent straight to the browser.

I would like to know the best way of filtering out undesirable html. I
understand the best way is to only allow acceptable information, in this
case all the different html formatting tags.

To prevent CSS attacks, it is the most simple and trivial thing; Simply
parse the input. Change all < and > tags to &lt; and &gt; for text/HTML
display of the tag itself without it parsing it. Then, like you stated, and
is the most basic approach to security for form input, etc., is to put them
back together with *only* the HTML tags you want, such as &lt;br&gt; would
then be put back together as a line break tag <br> You can do this easily
for almost all HTML tags. For tags that could potentially be used to input
things such as anchor tags for images or hot links, etc. simply control
what's put back together.

Such as (A perl example--I'm just writing this off the top of my head, this
isn't meant to be usable per se):

/&lt;\s*a\s+href\s*=\s*['"]?(https?|ftp)://([\w.-\@:]+\.\w{2,4})(/\w.\./\$\?
)*\s*["']?&gt;/<a href="${1}://${2}${3}${4}">/;

You'd want to do better sanity checks on that and check for defined
variables, etc. (of source, and okay, not so pretty and not a solid
solution, but just a quick idea. You can allow only URL's with characters
that should be valid in almost 100% of any/all URL's that anyone should
want/need to post to a page for others to view, and you remove the
possibility of someone inputting any end HTML tag and creating their own
within the new space, as well as any characters that would otherwise close
or end the anchor tag. No one can slip anything in there--provided the idea
is complete. I.e. only word characters in domains, along with a .dots and
dashes. Although underscores can be technically legal, they are a word
character anyway and safe.

You can have the @ character and maybe a : character for links to password
protected sites for web or FTP access. It will handle IP's or domain names.
It also allows for people to put in invalid (but safe) domain names for
either http, https or ftp protocols. Optionally, a URL with whatever
characters seem most likely probable; such as word characters (obviously),
forward slashes, .dots, ? query_string, separators, etc. tilde, and so on...
whatever you want. Just be careful about allowing things that should not be
in URL's at all (or not very likely at all); such as <, >, ", and '. You can
then allow ~, !, @ ,# ,$ , %, ^ , & , =, *, :, ;, ,, ?, [, ], etc. that
would potentially be in a URL pointing to a script at a site someone wants
to link to--but only a clickable link.

This is so sickly simple and can be done within a matter of a few minutes
with some not very complicated regular expressions. These (in my opinion)
fools (or idiots) that go around screaming about how much of a "security
guru" they are, because they find out that some Microsoft service doesn't
filter their form input well, doesn't mean jack. This is all very easily
avoidable, it's hyped up to sound like it's something everyone should worry
about and so on. Yes, it's real and people should worry, but for creating
your own programs or scripts, it's something very easily avoided. I can name
off a few people that actually think they are big shots for going around
posting stupid CSS script attempts in anchor tags on every site and service
for years, finally find one in Hotmail (oh, big surprise) and try and
publicize themselves about the hype.

Really, this is truly nothing more important than simply checking the
submitted data to ensure things are in control. It's not at all difficult to
do. I don't assume you believe it is, and sorry if it seems like I'm
lecturing you, this is not what I'm doing--I'm just so sick of seeing alerts
about stupid (and silly) things as if they are as important as things that
actually are important--and mostly by these alleged "big shot" security guru
firms that don't really know what they are doing (but they they do, because
they manage to insert their lame CSS tag in some HTML source
somewhere--showing that simple, unimaginative things are doable because of a
lot of thoughtless programmers that have no business programming, doesn't
mean anything). Nonetheless, I'm always glad to see people asking and
educating themselves on how to avoid it. This comes down to a very simple
policy that every programmer should implement and adhere to; Disallow
everything by default and then only allow what you want, in a controlled
manner after that. This way, you control how things work and people can
*not* compromise your scripts/program. It is really (_that_) simple. :-)
--
Regards,
Tim Greer  chatmaster () charter net
Server administration, security, programming, consulting.


Current thread: