Re: Re: sql injection protection
| From: | Alex Nikitin | 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...