RE: Fixing XSS Vulns

["Smith, Johnathon (KEYPEOPLE RESOURCES INC)" <johnathon.smith-eds () eds com>]

If security is your concern, which it obviously is since you are a
member of this list, you absolutely should encode all input from users.
The advantage of writing the trigger is that if someone forgets to
encode the input, it will still get encoded and it gives a centralized
place to manage all the encoding.  

However, in my humble opinion, html encoding should be done at input
capture time as I believe you should always sanitize data as close to
its source as possible.

To answer your specific questions, there is nothing wrong with encoding
it on capture and in fact you should do so.  You have not stated what
platform you code on, but if you are coding in .Net, you can review this
page with recommendations:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/
html/PAGHT000002.asp.

If you read the recommendations (also read on how to protect against SQL
injection), you will see that the issue at hand is just one of many
considerations you should take into account.  You should also make sure
that you validate the data such as if you want an integer, make sure
only an integer is passed, and you should also encode output to protect
your visitors.

It doesn't matter if the input is only for output to the web, it can
still do considerable damage.  One last thought also is that if you were
using .Net, you would not have to write any custom code, as there are
already classes that do this, thus saving you coding time.



-----Original Message-----
From: wilsonc [mailto:wilsonc () mantech-wva com] 
Sent: Friday, August 12, 2005 8:41 AM
To: webappsec () securityfocus com
Subject: Fixing XSS Vulns 

            I'm a new developer to a project, and I've found that our
web app is wide open for XSS exploits. (thankfully, its not in
production use).
I'm not a security expert, but I did some googling and found that the
standard procedure is basically to "encode" the string before displaying
it to the user, so that specific characters are transformed into their
HTML 'escape sequence'. For example, the left paren, '(' would be
encoded to be (

            A more experience developer has suggested that instead of
writing a function to do this when we display, we write a trigger to
encode/filter on capture. I explained to him that it would be that
HTML-specific 'escape sequences' would then be stored in the database,
and what I learned from googling. He feels confident that our data will
only be displayed through a web app, and not through any kind of
reporting module, and he feels the trigger to encode text is a cleaner
implementation.
Assuming your data was only going to be displayed back to the user via
the same website that captured the input, is there anything wrong with
encoding the string on capture?

--CW