Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Do I need to escape my variables if I use MySQLi prepared statements?

If I use MySQLi prepared statements like below:

$stmt = $con1->prepare("UPDATE Login SET Session='LoggedOut' where Session=?");
$stmt->bind_param('s',$Session);
$stmt->execute();
$stmt->close();

Do I still need to escape my variables like $Session with mysqli_real_escape_string(); like below:

$Session = mysqli_real_escape_string($con1, $_COOKIE['Session']);
$stmt = $con1->prepare("UPDATE Login SET Session='LoggedOut' where Session=?");
$stmt->bind_param('s',$Session);
$stmt->execute();
$stmt->close();
like image 855
door Avatar asked Jul 12 '14 19:07

door


People also ask

Do I need to use mysqli_real_escape_string with prepared statements?

Do I still need to used mysqli_real_escape_string when used prepared statements in PHP? The simple answer is no. The way it used to work is that you would take form input data, put that into a variable, and inject that data into your MySQL query in order to add that data to the database.

Which function is used in MySQLi with prepared statements?

There's also a function to simply free the memory associated with the MySQLi result and prepared statement, respectively: $result->free() and $stmt->free() .

Should I always use prepared statements?

You should always prefer working with prepared statements for the security benefits. They all but eliminate vulnerability to SQL injection, without you having to worry about SQL-escaping values. If you have a query that doesn't run often, though (less than once per request), a prepared statement can take longer to run.

Should I use PHP prepared statements?

In reference to the data and storing it, as stated in the comments, you can never and should never trust any user related input. Unless you are 101% sure the data being used to manipulate said databases/values is hard-coded into your app, you must use prepared statements.


2 Answers

No, if you use prepared statements everywhere in your application you are safe from SQL injection. However, an important "gotcha" is 2nd order injection attacks which happen when some queries use prepared statements and others don't.

According to this answer of a similar question on SO:

prepared statements / parameterized queries are sufficient to prevent 1st order injection on that statement. If you use un-checked dynamic sql anywhere else in your application you are still vulnerable to 2nd order injection.

In summary, prepared statements create a separation between the data being sent and the SQL query itself, ensuring that the data can not be misinterpreted as the SQL query. However, an attacker can still enter SQL as data, and although it will not be executed when it is first stored if you are using prepared statements, you must still use caution when retrieving said results. Prepared statements protect your application in that particular place, but because SQL is still allowed to be stored in the database, your application is unsafe if you're later using that data without parameterization.

like image 72
Tim Avatar answered Oct 03 '22 16:10

Tim


Nope you don't.

This is the only answer you need.

All the muddled talk in the other answer is just irrelevant. The guy is trying to tell you that if you are foolish enough not to use prepared statements all over the place, then you're in danger. Which is quite obvious, and irrelevant to a prepared statement itself.

like image 28
Your Common Sense Avatar answered Oct 03 '22 15:10

Your Common Sense