4 questions... which is basically all it comes to.. After all this back and forth emails, I think we should nail down these questions cause they are still not completely covered in my mind. question 1 If you use the PHP filters & sanitizations, and you plan on using PDO with binded params, are you absolutely safe? And if not, why? What are the other ways for them to still make it in - even with PD0 and binded params properly in place? Just curious. question 2 If you use the PHP filters & sanitizations, and for some reason, you CANNOT use PDO, what do you do against those situations where the user input is expected to be coming as a string and it's perfectly OK for it to be in say, around 1000 chars! For example, you are receiving a guest book comment. Use b64? But isn't with b64 search capability go down the drain? So we basically give up on search? Can we not come up with a solution which allows the search but yet still safe? What do we do? question 3 is there really no way to stop the user input's if char set is not utf8? Can we not enforce the userinput to be in UTF8 only and reject all input? If there is such a way, wouldn't we better of using mysq-_real_escape to allow both search and be safe? Or is there really no way to understand the incoming user input char set by PHP? question 4 do you have any white paper or any article that covers your most recommended solution against lengthy user input while you still want the search to work? you seem to know a lot and I think you should have at at least an article where we people can discuss the article at the bottom? It's always useful. If you don't have one, I strongly recommend you come up with one cause I'm sure it will be useful. On Mon, Jan 23, 2012 at 2:35 PM, Alex Nikitin <niksoft@xxxxxxxxx> wrote: > Start off with the fact that that article is from 2006, and its > written by a programmer... > >> I was simply asking expert opinion with the intention to learn. >> There is so much docs out there (I mean not just out there but at top >> security sites like owasp ) that recommends database specific escape >> solution as one of the viable alternatives. > > Escaping can work with a very specific set of circumstances, and it > can be secure, however it fails as a security practice, and thus fails > as a security solution. > >> You make it seem like anyone who does not use PDO ( for one reason or >> another ), and rely on the mysql_real_escape_string can be by passed >> and SQL injected. > > I can't tell you for sure, however any project that uses it as their > sole mean of sql injection protection can be exploited, yes. Just > because OWASP says that it is a solution, doesn't mean that it's a > good solution. Sometimes it's the only solution, yes, but it should > not be the only security practice. > >> So you're saying the mysql_real_escape_string() isn't 100% secure either? >> Crikey, if that's true, then I'm willing to bet A LOT of scripts are >> "vulnerable" to this problem. > > Any script that uses escaping as the sole means of protection, or > doesn't do good checking, which is a lot of scripts. But i mean i hope > it's no surprise, a lot of the web is vulnerable... > >> Is there a fix that doesn't involve perpared statements? Perhaps a >> function that checks for this problem, and filters it? My >> charset/encoding knowledge is a bit limited, so I'd very much >> appreciate an answer. Thanks! > > Sure, i have already mentioned it... The glorious base 64 hack... > >> Is it really that simple? It's hard to believe that all these >> implementations out there that honors the recommended filter & >> database specific escape mechanisms would *easily* be vulnerable by >> simply someone sending ut7, is that what you are saying? > > A lot are... likewise UTF16, and even UTF8 can often be an issue. The > issue with escaping is knowing what characters are "bad", if you think > you can escape a ' - tick and be safe, think again, in utf there are > dozens if not hundreds of characters that can represent a tick in > various circumstances. Again escaping fails as a security practice. > Yes it can work and make your code uninjectable, but it still fails as > a solution, even if secure... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
