Re: Fixing XSS Vulns

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

> To my way of thinking, you ultimately can't get out of taking data at
> all input borders and immediately decoding to the application's
> internal representation, then only encoding just before crossing
> output borders, and *only* doing the appropriate encoding for the
> needed representation for the output, and then ensuring that each
> distinct component does this properly.  One implication for design
> might be to keep all "cross-border" transactions as centralized as
> possible, but I don't know how easy this can be done in practice.  Not
> sure if this paragraph makes sense, so I apologize ahead of time.

I think this is dead on.  In the broad sense of preventing all types of
injection attacks (whether it be XSS, SQL injection, shell injection,
HTTP Response Splitting, mail header injection, etc) this is how you
have to think about coding your applications.

I firmly believe that this approach to encoding/decoding should come
first, and then when you can, validate input from users as much as you
can.  Why not focus on validation first?  Because some data *you just
can't validate*.  Sometimes special characters just have to be allowed
into an application, based on functional requirements.  You shouldn't
pit your security controls against your functional requirements, because
you know security will always lose that battle.

Not to say validation isn't bad.  You should always validate based on
your datatypes, but sometimes those datatypes will be blobs, and all
you can do then is quote/encode/escape.

tim