On 21 Mar 2004 Chris Shiflett wrote: > I would never argue that something is an absolute defense, but I would > characterize my recommendation as a best practice.
Fair enough. > > I agree with you that checking for valid characters is safer than > > checking for malicious characters, but even the former is not absolute. > > Not absolute in what sense? Making sure something is valid is pretty > absolute; Yes, agreed. It just that validation against input criteria doesn't guarantee that it's not an attack. > the only possible flaws are flaws in "making sure something is > valid." For example, I feel confident that no one can show me a string > that I would consider a valid first name that is also an SQL injection > attack. I'm sure that's correct. However I'm not sure the algorithm to definitively decide which is which is so obvious. > http://phundamentals.nyphp.org/PH_storingretrieving.php FYI, this site seems to be down. I've tried it several times over the last few days and it always times out. > This doesn't work for everyone. I can think of several examples where > users would be submitting HTML and/or PHP code. I wouldn't want to delete > some of their data. Of course. I was only referring to my specific case, where that's not an issue. > I applaud your efforts in data filtering, because almost all PHP > vulnerabilities that I read about are a result of the author completely > failing to perform any data filtering at all (which is inexcusable). > However, might I suggest that you take a slightly different approach. > Verify that the data is exactly what you expect it to be, and then escape > and/or encode it when necessary. Just to clarify ... are you saying that you feel it's better to specifically validate and encode each field according to its own requirements rather than use a global algorithm? I can understand that ... right now I do both, global checks first followed by field-specific validation and encoding / escaping. > For unvalidated data, do nothing with it until you have validated it with > your data filtering logic. A good software architecture should make it > easy for the developer to keep up with this (naming conventions are also > very helpful for this). Good point on the naming conventions. I tend to keep the raw data in _POST and the validated data inside an array of "control" objects within my data entry "form" object, so the differentiation is structural rather than by name. > This actually sounds like a strong approach to me. I assume that you > surround all data in an SQL statement with single quotes (not just integer > values). In fact, this is almost exactly what I am suggesting. I do not > think you have an SQL injection vulnerability, unless what your code does > strays from this description somehow. Yes, I use single quotes on everything. I was doing it only for strings and dates, but after reading some of the MySQL security info I added single quotes to the numeric values as well. > Also, if your applications never allow the user to submit HTML or PHP, > stripping tags is fine. But, you might be interested in letting your > regular expression catch this, so that you can log attacks. Attackers > certainly profile your applications - why not profile their attacks? It > can potentially help us all. Good point ... but then I am vulnerable to errors in my own algorithm, I figured the folks writing PHP were likely to have more experience with it than I did. However it would be fairly easy to check if strip_tags did anything by comparing string lengths, and log the change if there was one. > > I also haven't looked at what this does to nested attacks of various > > kinds and whether there is a way to use multiple iterations or escapes > > in the input data to bypass the filtering (pointers to articles which > > discuss this would be welcome). > > The point of escaping or encoding would be lost if it didn't work for all > possible data. I know of no articles for this, nor can I think of anyone > who would bother writing one. :-) That's true, but as there is no mention in the documentation, I have no idea whether functions like mysql_escape_string properly handle things like strings which have already been escaped, whether strip_tags will take care of something like <t<tagag, and so on. stripslashes is specifically documented as handling only one round of backslashes -- do I need to call it in a loop? Thinking through whether this matters is tricky. In other words I can imagine classes of problems that the existing tools may or may not solve, and it's a bit of a chore to investigate so I was hoping someone else had already done so :-). Thanks for all of the comments. -- Tom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
