Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63107
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5058C809.50005@lsces.co.uk>
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>
Date: Tue, 18 Sep 2012 15:28:12 -0400
Message-ID: <CAAyV7nHUgDLoYPYVeWBGuRc=pA4AmOAkxUzs71SBhQOTbTQnpA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043745211d59d804c9fee43d
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: ircmaxell@gmail.com (Anthony Ferrara)

--f46d043745211d59d804c9fee43d
Content-Type: text/plain; charset=ISO-8859-1

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.

--f46d043745211d59d804c9fee43d--