Rasmus Lerdorf wrote:
But the general idea is to provide an optional filter that people can enable in their ini file. This will strip out any XSS, quotes, braces,
I assume this will include PHP functions to do the filtering as well? (Forgive me if we already have this now, I haven't looked at 5.0 enough yet :-))
Right,a function to filter user data through any of the filters will be provided as well.
$age = pfilter(POST, 'age', FILTER_DIGITS); $addr = pfilter(POST, 'addr', FILTER_ALNUM); $body = pfilter(REQUEST, 'body', FILTER_TAGS); $raw = pfilter(COOKIE,'cook', FILTER_RAW);
Sounds like a good idea (even though the name pfilter reminds me too much of packet filter :-)). A catch-all could be handy too, e.g.
pfilter(REQUEST, DEFAULT, FILTER_TAGS);
I just made up the pfilter name. I really don't care what it is called. Figured filter() was a bit too generic and likely to step on existing user-space functions out there.
which filters anything not handled before. Surely you can come up with a better interface but I hope you get the idea. Being able to define a default filter but still override it for certain variables is what I mean. (Also important would be that FILTER_TAGS is more robust than strip_tags which has some loopholes IIRC)
strip_tags only has loopholes if you allow some tags through. But yes, this would be a very strict get rid of all tags filter and it needs to be charset aware.
A bit off-topic: I'm sure variable tainting has been discussed before, can some give the final opinion, was it found unsuitable/too much work/too inefficient or was it just post-poned (maybe indefinitely)?
It is really hard to do this correctly. Most user data in a web app is multi-purpose in the sense that it is often both displayed and inserted into a database, for example. The untaint rules are vastly different for these two purposes. Throw in a few more and you have a mess on your hands. Just because you untainted it for one purpose doesn't mean it is safe for another, so I don't really see how a single taint flag can be all that effective. I would rather see context-specific access function that retrieves the data for a specific purpose. In this case implemented by calling pfilter with a given filter.
And just to clarify, since I added the hook to do this long ago, there aren't actually any PHP changes needed. It can be completely handled in a pecl extension. It just becomes a matter of whether/when to include it with PHP.
-Rasmus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
