On Feb 2, 2005, at 3:53 PM, Rasmus Lerdorf wrote:

We have seen definitively that many application writers do not know how to properly validate data. And yes, it is another ini thing to worry about, and yes it will be painful, but I don't think we can continue to ignore this. I also think that people who actually write good and secure web apps in PHP won't have too many problems with this. It will just be an additional tool they can use if it is available. For people who don't know what they are doing or don't care about security, it may very well break their applications, but those applications most likely should be broken.

I absolutely agree that a problem exists. However, I am not sure that an optional external filtering solution will solve the problem. Especially if the option breaks too much stuff for most people to turn it on.


On the other hand, just the existence of the option, even if rarely used will still result in obscure bug reports and a steeper learning curve.

I would like to be wrong.

On Feb 4, 2005, at 4:00 AM, Rasmus Lerdorf wrote:

And everyone here understands that &{ needs to be stripped or entitied as well, right? How many non-internals folks do you think know that?

Which is why whitelists for input are better than blacklists. If a strict global blacklist oriented filter causes the programmer to bypass it and go for the raw input, then they are in the same boat regarding this stuff.


Independently of the external filtering, a set of standard whitelist oriented filtering functions would be a good idea.

There may also be some other areas where quoting requirements and filtering requirements might be made more obvious.

For example, if you use external input inside the replacement parameter of preg_replace, you have to quote it. However, many people don't realize that, or that the quoting rules for the replacement parameter are different than the quoting rules for the search pattern parameter. A preg_replacement_quote function might highlight this issue.

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



Reply via email to