Filtering policy and why

spookztar

Hi Guys,

All over the web, you hear the mantra: "filter input, escape output". But I'm a bit puzzled here. Why is it necessary to escape all output, if all input is properly filtered and validated when recieved?

laserlight

spookztar wrote:
Why is it necessary to escape all output, if all input is properly filtered and validated when recieved?

You might be escaping/filtering input to prevent SQL injection, but not escape/filter it to prevent against a cross site scripting attack. As such, it would be correct to escape/filter the output to prevent against a cross site scripting attack.

It might appear that this second step is unnecessary: why not just do the escaping/filtering all at once? The problem with that is that it assumes that the output is fixed to a particular format, but this might not be the case (or it might be the case now, but not later).

spookztar

Thanx for your reply.

So, are there any situations where output filtering is not necessary, or is it consequentially just everything outputted to screen?

spookztar

Ok, let me ask another way: is it necessary to filter output that is either static or generated dynamically with information supplied by oneself? Or is it simply ALL output delivered to the public space, regardless of it's origin and nature?

laserlight

spookztar wrote:
is it necessary to filter output that is either static or generated dynamically with information supplied by oneself?

Maybe. For example, suppose you were writing say, blog software. A blog post would be generated dynamically with information supplied by the blogger, but perhaps you want to provide the blogger the option of directly using client side code in his/her post instead of some kind of bbcode. In that case, it would not make sense to filter the blog post with respect to client side code since you intentionally want the user to supply arbitrary client side code.