[Esapi-dev] XSS: Filter vs Encode?

[Dave Wichers]

I think encoding before putting something in a database is almost always a
BAD IDEA. Once its in the database, you never know how its going to be used
in the future. If you encode it, then its for a specific context, and its
difficult to know that  it will always be used in that context. XSS had 4-5
different contexts for example. And I might put it into a PDF, send it to be
TV, send it in an email, and a zillion other things all of which will be
broken except for the 1 context it was encoded for.

So, validate as best you can before putting it into the database and if its
not valid, don't include it. And then when you get it out, encode it for the
proper context you are including it in, in case something evil slipped
through the validator.

I've seen too many encoding screw-ups, like Ryan's Song on the guide on
my cable box, which is why I recommend avoiding encoding before storage in a
DB.

-Dave

-----Original Message-----
From: esapi-dev-bounces at lists.owasp.org
[mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Jeffrey Walton
Sent: Sunday, December 11, 2011 12:27 AM
To: Kevin W. Wall
Cc: esapi-dev at lists.owasp.org
Subject: Re: [Esapi-dev] XSS: Filter vs Encode?

On Sun, Dec 11, 2011 at 12:20 AM, Kevin W. Wall <kevin.w.wall at gmail.com>
wrote:
> On Dec 10, 2011 11:56 PM, "Jeffrey Walton" <noloader at gmail.com> wrote:
>>
>> According to ASP.net and their tutorials (and at least one book I've 
>> looked at), data is inserted into the database unfiltered but later 
>> encoded to counter XSS.
>>
>> I'm not sure I agree with inserting contaminated data into the 
>> database. I think there's a potential for abuse: for example, suppose 
>> a page is later added which omits encoding.
>>
>> What is the preferred method of sanitizing input?

> This is the so-called persistant XSS case.
Right. That's why I don't understand why one would stuff it in the database
and hope to fix it via an encoder. But I'm not a clever web programmer.

> When possible, you should always validate input. But that is not 
> always possible. Sometimes a 3rd party app may be collecting input 
> into the DB. Sometimes you need to collect general input for comments 
> or whatever & are required to accept ALL input characters. Whatever 
> the reason, that's why you filter the output by properly encoding it.
OK. The argument that was made in the book stated the author preferred to
'search un-escaped text' (or something to that effect).

> So, in a nutshell, do BOTH when possible. When not, at least escape 
> the output for the appropriate context.
Gotcha. Thanks Kevin and Jerry.

Jeff
_______________________________________________
Esapi-dev mailing list
Esapi-dev at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-dev