Re: Fixing XSS Vulns

[RSnake <rsnake () shocking com>]

        I'm assuming by your description that you found my website at
http://ha.ckers.org/xss.html and by your description I think you
understand the problem.  As long as you have no intention of outputting
any HTML, I think you're safe using the method you have described (as
long as your database element is large enough to handle the increased
size of your encoded text, which can be a huge issue in large scale,
applications that require millions of records, which is why many people
choose to convert on output rather than input).  The downside of doing
it on output is when you have multiple people working on the application
they all have to remember to encode the data on output, whereas if it is
encoded ahead of time you don't have to do anything with the data.  This
is also a handy way to avoid SQL injection, btw.  The upside of doing it
after the fact is that you can still search on the data and you have the
text exactly as they typed it.  However, if you want to allow some
whitelisted HTML (like <FONT tags for instance) that is where it gets
tricky and simply using encoding falls down pretty quickly without a lot
more work.

On Fri, 12 Aug 2005, wilsonc wrote:

>            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
> &#40;
>
>            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

-R

The information in this email is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to
this email by anyone else is unauthorized.  If you are not the
intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it is 
expressly prohibited and may be unlawful.