Re: Re: sql injection protection

From: Date: Mon, 23 Jan 2012 22:35:06 +0000
Subject: Re: Re: sql injection protection
References: 1 2 3 4 5 6 7 8  Groups: php.general 
Request: Send a blank email to php-general+get-316379@lists.php.net to get a copy of this message
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...

« previous php.general (#316379) next »