Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63089
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ravensight.org from 209.85.219.42 cause and error)
To: <internals@lists.php.net>
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> <CALwr1GkLMrenFjv49kE1a-i4vN3sVr2Rr1wRUgBWGg3=V34How@mail.gmail.com>
In-Reply-To: <CALwr1GkLMrenFjv49kE1a-i4vN3sVr2Rr1wRUgBWGg3=V34How@mail.gmail.com>
Date: Tue, 18 Sep 2012 12:58:25 -0500
Message-ID: <011201cd95c7$33d43c30$9b7cb490$@org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
thread-index: Ac2VwzL51ADB1yDqRrKEQvA47MfxcgAAGUdw
Content-Language: en-us
Subject: RE: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: bryan@ravensight.org ("Bryan C. Geraghty")

Hello everyone,

Paddy is correct here. The purpose of this API is output ENCODING which =
is a
very good thing. This discussion provides a very good case for a point I
made via Twitter this morning: In this RFC, all uses of the term =
"escape"
should be replaced by the term "encode".

This is not solely a problem with this RFC. The term "escape" is being =
used
developers in the industry when they mean "encoding". This is bad thing
because, from a security perspective, escaping is exactly the opposite =
of
encoding.

- Escaping is done by setting up a black-list and replacing those =
elements
with an approved variant.
- Encoding is done by converting all of the input data into the target
format. Some bytes may end up being exactly the same but they are all
processed.

I understand why people on this list are associating the functionality
defined in this RFC with filtering because the name is leading them =
astray.

Besides the fundamental difference in the definitions of each item, the
security industry is using the term "encoding"; take a look at the OWASP
documentation for a quick example.

If we want developers with little application security background to be =
able
to understand these things, we need to be consistent.

Bryan

-----Original Message-----
From: P=E1draic Brady [mailto:padraic.brady@gmail.com]=20
Sent: Tuesday, September 18, 2012 12:29 PM
To: jpauli
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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=20
>> 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=20
>> available to all PHP programmers without resorting to userland=20
>> solutions. Existing functions are widely misused, misconfigured or=20
>> 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=20
>> vulnerability in web applications (depending on whose data you use).=20
>> 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=20
>>>> surrounding how to properly escape data. To try and offset this,=20
>>>> I've written articles, attempted to raise awareness and wrote the=20
>>>> Zend\Escaper class for Zend Framework. Symfony 2's Twig has since=20
>>>> adopted similar measures in line with its own focus on security.
>>>>
>>>> That's all. The RFC should be self-explanatory and feel free to=20
>>>> pepper me with questions. As the RFC notes, I'm obviously not a C=20
>>>> programmer so I'm reliant on finding a volunteer who's willing to=20
>>>> 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,=20
>>> why can't this be a composer-installable class, implemented in PHP?=20
>>> It solves the issue that you need to find a volunteer, as well as=20
>>> that updating it is a lot easier, and, you don't have to rely on=20
>>> shared hosters having it enabled.
>>>
>>> I realize that you want to have this generally available, but for=20
>>> that we have ext/filter - which is not really used too much I=20
>>> *think*. Why would this be different? IMO, we should make a composer =

>>> installable package for this, and then litter all our escaping=20
>>> related document pages with links to this new package.
>>>
>>> cheers,
>>> Derick
>>>
>>> --
>>> http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a=20
>>> 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,=20
>> 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=20
> it's done, it's OK, but unfortunately, that's not the case, as XSS=20
> 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



--
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