On Tue, Sep 18, 2012 at 2:27 PM, Pádraic Brady <padraic.br...@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 <der...@php.net> wrote:
>> On Tue, 18 Sep 2012, Pádraic 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 all
>> 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ádraic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
> --
> Pádraic 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to