Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63080
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: <CAMUwpuSfd1U6aA_7o6d2jGm-i0PsLAf1MqKF8zvtcfzGFMGEXQ@mail.gmail.com>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<alpine.DEB.2.02.1209180809010.28929@whisky.home.derickrethans.nl>
	<CALwr1GnjwyE=yipK6UNkOm9m31LDDbpbcdgmr_nf0cUo+zOedw@mail.gmail.com>
	<CALwr1G=DOKmjudFFEAFY+6hmUh3q+qNe1ntWY1FLXP5GChLZdA@mail.gmail.com>
	<CAMUwpuSfd1U6aA_7o6d2jGm-i0PsLAf1MqKF8zvtcfzGFMGEXQ@mail.gmail.com>
Date: Tue, 18 Sep 2012 18:29:14 +0100
Message-ID: <CALwr1GkLMrenFjv49kE1a-i4vN3sVr2Rr1wRUgBWGg3=V34How@mail.gmail.com>
To: jpauli <jpauli@php.net>
Cc: 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 Julien,

I think you're mixing these up. The RFC addresses escaping or encoding
of data on output to HTML/XML (e.g. PHP templates or Twig). It doesn't
act as an input filter to catch attempted XSS/SQLi where fuzzing can
disguise the attempt and wheedle its way past countless regular
expressions - these are always broken in time. In this specific case,
the rules for escaping are well known and very rarely change unless
HTML sees some very dramatic changes in how tags and attributes are
defined.

Paddy

On Tue, Sep 18, 2012 at 5:31 PM, jpauli <jpauli@php.net> wrote:
> On Tue, Sep 18, 2012 at 2:27 PM, P=E1draic Brady <padraic.brady@gmail.com=
> wrote:
>> Hi Derick,
>>
>> This is already available over composer. The RFC contains links to the
>> two frameworks which have implemented Escapers in line with the RFC.
>>
>> The point of the RFC is to ensure a consistent API for escaping is
>> available to all PHP programmers without resorting to userland
>> solutions. Existing functions are widely misused, misconfigured or
>> have builtin security issues yet are popularly advanced as "escaping"
>> for XSS.
>>
>> XSS is also...XSS. It's either the first or second most common
>> vulnerability in web applications (depending on whose data you use). I
>> think it warrants PHP distributing a proper solution out of the box.
>>
>> Paddy
>>
>> On Tue, Sep 18, 2012 at 1:11 PM, Derick Rethans <derick@php.net> wrote:
>>> On Tue, 18 Sep 2012, P=E1draic Brady wrote:
>>>
>>>> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
>>>> The RFC is a proposal to implement a standardised means of escaping
>>>> data which is being output into XML/HTML.
>>>>
>>>> Cross-Site Scripting remains one of the most common vulnerabilities in
>>>> web applications and there is a continued lack of understanding
>>>> surrounding how to properly escape data. To try and offset this, I've
>>>> written articles, attempted to raise awareness and wrote the
>>>> Zend\Escaper class for Zend Framework. Symfony 2's Twig has since
>>>> adopted similar measures in line with its own focus on security.
>>>>
>>>> That's all. The RFC should be self-explanatory and feel free to pepper
>>>> me with questions. As the RFC notes, I'm obviously not a C programmer
>>>> so I'm reliant on finding a volunteer who's willing to take this one
>>>> under their wing (or into their basement - whichever works).
>>>>
>>>> https://wiki.php.net/rfc/escaper
>>>
>>> I understand that this is really beneficial to have, but, I wonder, why
>>> can't this be a composer-installable class, implemented in PHP? It
>>> solves the issue that you need to find a volunteer, as well as that
>>> updating it is a lot easier, and, you don't have to rely on shared
>>> hosters having it enabled.
>>>
>>> I realize that you want to have this
>>> generally available, but for that we have ext/filter - which is not
>>> really used too much I *think*. Why would this be different? IMO, we
>>> should make a composer installable package for this, and then litter al=
l
>>> our escaping related document pages with links to this new package.
>>>
>>> cheers,
>>> Derick
>>>
>>> --
>>> http://derickrethans.nl | http://xdebug.org
>>> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
>>> twitter: @derickr and @xdebug
>>> Posted with an email client that doesn't mangle email: alpine
>>
>>
>>
>> --
>> P=E1draic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>> Zend Framework Community Review Team
>>
>>
>> --
>> P=E1draic Brady
>>
>> http://blog.astrumfutura.com
>> http://www.survivethedeepend.com
>> Zend Framework Community Review Team
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> Implementing this to Core may be very nice, but as well very hard to do.
> String escaping is a pain to implement in C. One would tell : once
> it's done, it's OK, but unfortunately, that's not the case, as XSS
> rules evolve throught time as the attacks evolve.
>
> See the escape modules web servers tried to push (mod_security and its
> counterpart in Nginx), its PITA to maintain if you want something that
> covers a large area.
> By the way : why not let the web server do this as nowadays, they seem
> to manage that problem ?
>
> Julien.P



--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team