Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63136
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5058AFD7.7080703@ajf.me>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<5058AD25.8010304@mrclay.org>
	<5058AFD7.7080703@ajf.me>
Date: Wed, 19 Sep 2012 15:07:43 +0100
Message-ID: <CALwr1GkgjB4NWEaWDb6QHpvqALhfn_ut=OLKVcWfKAzjdfePkQ@mail.gmail.com>
To: Andrew Faulds <ajf@ajf.me>
Cc: Steve Clay <steve@mrclay.org>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: padraic.brady@gmail.com (=?ISO-8859-1?Q?P=E1draic_Brady?=)

Hi Steve,

Missed this one in the rush of emails...

> I echo this. I think some clearer names might help, I think something lik=
e
> these:
>
> escapeHTMLAttribute for attributes, escapeHTMLText for text inside <eleme=
nt>
> tags, escapeXMLAttribute and escapeXMLContent, escapeJSStringLiteral,
> escapeCSSIdentifier, and another needs adding (for url('*') things),
> escapeCSSStringLiteral.

The ESAPI API uses encodeForHTML, encodeForCss, etc. We can name these
in a few different styles which would all be semantically correct but
my own sentiment is often to keep the naming simple.

For example, I'd prefer escapeForCss vs escapeCSSStringLiteral though
both would be valid English literal alternatives to escapeCss.

It's also worth bearing in mind that these escaping functions are
distinct and separate from the concept of sanitisation or a sanitising
filter. For each escaping option there is a sanitisation alternative
where untrusted input (whether from a user, database or 3rd party
service) contains markup you want to allow through "unescaped". For
example, a feed aggregator would need to output HTML from a 3rd party
feed and it may contain URLs that also need to be validated.

HTML, of course, has HTMLPurifier - easily the best HTML sanitiser.
URLs must always be validated to a known good whitelist (not
filter_var() only).

CSS can also be sanitised if the user has access to properties and not
just the property values.

Paddy

--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team