Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63141
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: <5059E3A2.3090805@ajf.me>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<5058AD25.8010304@mrclay.org>
	<5058AFD7.7080703@ajf.me>
	<CALwr1GkgjB4NWEaWDb6QHpvqALhfn_ut=OLKVcWfKAzjdfePkQ@mail.gmail.com>
	<5059E3A2.3090805@ajf.me>
Date: Wed, 19 Sep 2012 16:36:23 +0100
Message-ID: <CALwr1Gm6KCHTDd0jQqkWTcOxFhxQXawZAyqhTzrkgp4eYY9W2Q@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,
>
> Who's he? :)

Everybody knows Steve! :P I know at least 10!

>> 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.
>
> The naming is unclear just now though.

Than I suggest including "For" in all of them. escapeForHtml,
escapeForUrl, etc. That should clear it up somewhat that we're not
targeting whole blocks of HTML/JS/CSS.

>> For example, I'd prefer escapeForCss vs escapeCSSStringLiteral though
>> both would be valid English literal alternatives to escapeCss.
>
> You can't just have escapeForCSS, you need two functions: one for CSS
> identifier names (.identifier, #identifier, etc.), and one for CSS string=
s
> (background-image: url('string'); or content: 'string')

Not really, the target here is breaking out of a CSS or HTML context.
If you allow users to alter identifiers or properties than escaping is
just wrong - you should be sanitising instead to make sure the CSS is
still well formed and agrees to a whitelist of allowed ids/props.

> Also, escapeForJS isn't very clear, you should explicitly specify you're
> escaping a string of text for a JavaScript string literal. I don't think =
you
> can escape JS identifier names.

JS is purely for literal values and not any JS variables/statements or
anything else. Those can never ever be subject to any form of
untrusted input.

Paddy


--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team