Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63058
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: <CALwr1GkacT0OoU1UmhmfdskBfKxf6H2SbUv-wQOhT2jySe=YsQ@mail.gmail.com>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<CAKxcST9tvBLGsg9iKzGk6u26p0SJqgPJ73RLXkE3GK8d7RnNMA@mail.gmail.com>
	<CAKxcST_S9KVaRhDGSU3ZwRFFCvaK0W=qLA2zf+YXWYZRZ+t5zg@mail.gmail.com>
	<CALwr1GkacT0OoU1UmhmfdskBfKxf6H2SbUv-wQOhT2jySe=YsQ@mail.gmail.com>
Date: Tue, 18 Sep 2012 13:28:16 +0100
Message-ID: <CALwr1Gk5LozX8CPKST2zBzYOL+RVkaT6JMAnUoifztHbSX2-JQ@mail.gmail.com>
To: 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 Paul,

The thing is that filter_var() is strongly associated with input
sanitisation whereas Escaper addresses the other end of output. Also,
escaping is inextricably linked to character encoding - we can't run
into situations where the functions are specific to something like
UTF-8 when the character encodings used in real life are far more
diverse. Additionally, the RFC was an attempt to make escaping as
explicit and restrictive as possible - give a user too many options,
or too many dispersed units of functionality, and they'll invariably
confuse and misinterpret themselves to Hell ;).

Note: There is a stack of folk, for example, who use the ext/filter
URL validator for HTTP validation - it also passes php:// and
javascript:// URLs. If we're not explicit, they won't ever notice when
they're doing it wrong.

Paddy

On Tue, Sep 18, 2012 at 12:34 PM, Paul Dragoonis <dragoonis@gmail.com> wrot=
e:
> On Tue, Sep 18, 2012 at 12:32 PM, Paul Dragoonis <dragoonis@gmail.com> wr=
ote:
>> Hi Paddy,
>>
>> Couldn't this just be a new option for the filter_var() function?
>>
>> $clean =3D filter_var($_POST['someVar'], XSS_CLEAN);
>
> I see from your RFC that you have a bunch of functions, I believe all
> these could be options to filter_var, ie.: FILTER_ESCAPE_[URL, JS,
> CSS, HTMLATTR].
>
> - Paul.
>
>>
>> - Paul.
>>
>> On Tue, Sep 18, 2012 at 12:30 PM, P=E1draic Brady <padraic.brady@gmail.c=
om> wrote:
>>> Hi all,
>>>
>>> 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
>>>
>>> Best regards,
>>> Paddy
>>>
>>> --
>>> 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
>>>



--
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team


--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team