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ádraic Brady [mailto:padraic.br...@gmail.com] 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 <jpa...@php.net> wrote: > 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 -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
