Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63095
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5058AD25.8010304@mrclay.org>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<5058AD25.8010304@mrclay.org>
Date: Tue, 18 Sep 2012 19:20:16 +0100
Message-ID: <CALwr1Gmnfd2cn_NXO1_onWh-ACq3A05XW5F5qoug-a9n69eH-A@mail.gmail.com>
To: Steve Clay <steve@mrclay.org>
Cc: 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,

I can add some examples but it's not clear cut all the time. For
example, contexts can nest three levels deep in some cases even ;).
HTML inside Javascript inside HTML. Then there's the boogie man of
other forms of DOM-based XSS...

So the nesting is quite simple to compose but the rules governing it
are wholly separate from this RFC and depend on the HTML output being
written. The RFC just addresses the building blocks themselves.

$e =3D new Escaper; // default to UTF-8
$e->escapeHtml($e-escapeJs($e->escapeHtml('<p>'))); // e.g. for
including <p> into markup via a Javascript string defined in a HTML
attribute interpreted as PCDATA.

Oh, and that does happen. It's far from recommended these days - we
should all start applying the new Content-Security Policy standard.

Paddy

On Tue, Sep 18, 2012 at 6:19 PM, Steve Clay <steve@mrclay.org> wrote:
> On 9/18/12 7:30 AM, P=E1draic Brady wrote:
>>
>> That's all. The RFC should be self-explanatory and feel free to pepper
>
> ...
>>
>> https://wiki.php.net/rfc/escaper
>
>
> I like where this is going and agree that PHP officially embracing an API
> would be helpful even for users stuck on old PHP versions.
>
> First issue: I've not studied the referenced PHP implementations, but in
> cases where multiple contexts seem to apply it's not clear from the RFC
> which function(s) should be used, and if multiple, how their calls would =
be
> composed. Examples:
>
> HTML style attribute: escapeHtmlAttr, escapeCss, or both?
> HTML on* attributes: escapeHtmlAttr, escapeJs, or both?
> HTML href/src attributes: escapeHtmlAttrs, escapeUrl, or both?
> HTML script/style elements: Is escapeHtml needed?
>
> I can probably correctly guess some of these, but I think ideally the met=
hod
> and class names should make this more obvious. If escapeJs is only for
> string literals in JS code (again, the name doesn't make that clear to me=
),
> what does escapeCss actually do, since string literals aren't very common=
 in
> CSS?
>
> Example code would be helpful to clarify both issues, but I still think
> naming is very important here, and with all the contexts we have to consi=
der
> the names in the RFC don't scream what to use them for.
>
> Steve
> --
> http://www.mrclay.org/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team