Rasmus Lerdorf wrote:
I don't actually see it as a per-script thing. Obviously the ini would be per-dir Apache configurable, but I see this as being something set across the board on a dedicated server that defines the security policy of that server. Shared servers are most likely not going to be able to
Uh, that's a big goal but also asking for trouble. As you pointed out there is a different rule on what's safe for a specific input variable based on what it's used for (e.g. SQL, output, shell arg) and what's not. Wouldn't one have to set up default filters for every possible use to be safe then, i.e. a combination of all filters?
Well, if you set a global filter you set an extremely strict one. Like only letting a-z through or the equivalent in your charset, for example. Want a number? Tough, call the filter function to get at it. The idea is to force people to think about how to filter each piece of data they need, and if they forget one it will still work, but what gets through will be extremely limited.
Another major point would be to handle UTF8 properly, something which is not easily handled by regular expressions, right?
The preg* functions support UTF8. But yes, the filters need to understand charsets correctly.
-Rasmus
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
