views:

1252

answers:

4

I've seen lots of articles and questions about mysqli, and all of them claim that it protects against sql injections. But is it fool proof, or is there still some way to get around it. I'm not interested in cross site scripting or phishing attacks, only sql injections.

What I should have said to begin with is that I am using prepared statements. That is what I meant with mysqli. If I use prepared statements without any string concatenation, then is it foolproof?

+1  A: 

mysqli is just a middleware so you don't expose your database engine in php.

But if your query is something like

SELECT * FROM a_table WHERE something = ".$_var.";
and $var= ";DROP TABLE a_table;";"

It will still work

fmsf
+2  A: 

It doesn't protect from sql injections any better than the old mysql module, just makes doing it easier for the developer, who can now use prepared statements instead of calling mysql_real_escape_string.

RommeDeSerieux
A: 

If you use its object-oriented interface, then you're protected against sql injections (because you don't feed any SQL to the objects). If you use SQL then you're responsible not to inject anything unintentional there.

Joonas Pulakka
+6  A: 

But is it fool proof, or is there still some way to get around it.

No, you have to know what you're doing. If you use bound parameters (A feature that MySqli comes with), you are completely safe from injection type attacks from this attack vector. This doesn't prevent you - the programmer - from embedding strings directly, and thereby enabling injection attacks. You have to use the feature as intended.

Re: Edit

What I should have said to begin with is that I am using prepared statements. That is what I meant with mysqli. If I use prepared statements without any string concatenation, then is it foolproof?

Foolproof is still such a dangerous word. But you are safe from injection attacks for the variables that are bound through prepared statements. This is because bound parameters are transmitted separately from the SQL query. With the "traditional" embed-string approach, the database server needs to parse the input and there are lots of edge cases in that (Charsets etc.). When the data and the query are sent separate, there is no actual parsing going on (At least not parsing of the variable data).

troelskn