Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63119
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.185 cause and error)
Message-ID: <5058E206.60501@lsces.co.uk>
Date: Tue, 18 Sep 2012 22:05:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com> <5058A697.30903@sugarcrm.com> <CAAyV7nF82MW1gRpVpiVooCNyj7YE-eVDqjzqFX0m3X1J7Kp_UA@mail.gmail.com> <5058A8B8.3070404@sugarcrm.com> <5058A97A.4080900@ajf.me> <5058AABA.1040406@sugarcrm.com> <CAAyV7nHgJku5MqKY-D_Gk+DaSt-Wda3BJHsSzyS=yW6xENRi6w@mail.gmail.com> <5058B5A5.6090302@sugarcrm.com> <5058BA43.8010806@mrclay.org> <5058BBA6.4090702@sugarcrm.com> <CAAyV7nGZ2iinDUcUfsVeBxFC_2nF8TmbaDrMDQTK0dkmnLifow@mail.gmail.com> <5058C809.50005@lsces.co.uk> <CAAyV7nHUgDLoYPYVeWBGuRc=pA4AmOAkxUzs71SBhQOTbTQnpA@mail.gmail.com>
In-Reply-To: <CAAyV7nHUgDLoYPYVeWBGuRc=pA4AmOAkxUzs71SBhQOTbTQnpA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: lester@lsces.co.uk (Lester Caine)

Anthony Ferrara wrote:
> Lester,
>
>     Basically if you are STORING XSS intrusions then you have badly designed
>     code as there is no reason that it would be stored. If you want to 'display'
>     suspect code, then it is 'escaped' before it is stored so preventing a
>     potential problem if another viewer accesses the raw data!
>
>
> I wasn't going to reply to you, but this is just plain wrong.
>
> You should always consider ANYTHING that's outside the runtime of your
> application (not in memory of the current instance) to be insecure. Feel free to
> store XSS in your database. Because you're not going to trust it anyway. The
> second you trust content in your database, you've opened more potential attack
> vectors.
>
> The proper solution is to do context based escaping/encoding at the moment of
> output. That way you can update your escaping code if you find a bug and all
> your content will be protected. If you find a bug in your escaper when you
> escape on input, how the heck to do you propose to fix it for all the content
> already stored without looping over every single item and updating the DB table
> (also a bad design).
>
> No, you should Filter In (make sure that content meets your domain criteria, eg
> username alphanumeric, email looks like an email, etc), and Escape Out (prevent
> Injection and XSS vulnerabilities when that data leaves your application). Any
> other way of doing it is going to lead to attack vectors. But if you diligently
> Escape Out, Injection and XSS are IMPOSSIBLE. And even if you have a bug in your
> algorithm that allows an edge case, you can fix it once and have it fixed for good.
>
> And that doesn't even approach the problem where the same data will be used in
> different output contexts (which require separate escaping mechanisms). Thereby
> completely destroying any security you thought you had by pre-escaping.
>
> So no, you're wrong. It's badly designed code to escape HTML prior to storage.

I have to strongly dispute that. I will NEVER store 'dirty' html in the 
database. In fact even ckeditor ensures that the stored data is clean and can be 
output raw if necessary. *IF* a forum post, blog or wiki need to store suspect 
code as an example then it should never be stored in it's dirty form. I HAVE to 
escape it to get it IN to the database as otherwise it will not be saved. But 
perhaps what I should point out here is that the formatting tags will not be 
escaped, only the free format text. That is the only way to ensure that users 
can't 'inject' extra tags into the pages manually. I could not handle escaping 
the user input in any other way? You can't simply 'escape' the output at all?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk