Re: Fixing XSS Vulns

[Tim <tim-security () sentinelchicken org>]

>             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
> (

Yes, this is the best way to avoid XSS.  (as an aside: Don't let anyone
try to tell you that you should search for "evil" html and remove it.
It is bound to fail, as it has on many people before)

>             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?

I personally think HTML quoting the data before storing it in the
database is a terrible idea.  If you ever want to put that data
somewhere else (and assuming you never will is a bad assumption, IMHO),
then you'll find yourself constantly decoding the data before using it.

Of course, you should be properly escaping before you put it in the
database, to avoid SQL injection, but that's a different issue.

HTH,
tim