On 09/18/2012 03:28 PM, Pádraic Brady wrote: > Hi Rasmus, > > On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: >> If we want to add more filters for more specific purposes, I am not >> completely against it, although the more specific they get the more >> churn there will be. We are not going to be able to kick out weekly >> releases to address every new nuance of these very specific filters. But >> they should be implemented as filters compatible with the filter >> extension so people can use them within that existing context. That >> doesn't preclude a more approachable function alias from also calling >> them, of course, much like the htmlspecialchars case. > > I feel it needs to be reiterated that the escaper rules are very > predictable and very seldom change as the regular expressions in the > Zend\Escaper class demonstrate. Each is bound to official standards > for Javascript, CSS and HTML respectively and most of the rules, > defined using the OWASP's recommendations as implemented in ESAPI, are > really clearcut - escape everything except alphanumerics and a small > range of "safe" characters (CSS even has NO safe chars outside > alphanumerics). HTML and URL encoding are the only permissive variants > and these are already well known in PHP.
Except the browsers all have different quirks. At the very least during the first year of its life this code it going to change a lot as the security community whacks away at it. This should start as a pecl extension so it can iterate rapidly and be available to PHP 5.3/5.4 users. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
