9

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();
TylerH
  • 20,799
  • 66
  • 75
  • 101
door
  • 155
  • 1
  • 12
  • 1
    No, that's why you use prepared statements – JiFus Jul 12 '14 at 19:32
  • 1
    As a side note, having a variable named `$Session` might prove confusing for you or others in the future. – Boaz Jul 12 '14 at 19:34
  • http://stackoverflow.com/questions/1742066/why-is-pdo-better-for-escaping-mysql-queries-querystrings-than-mysql-real-escape – Black Sheep Jul 12 '14 at 19:43
  • @aldanux @JiFus so if I understand correctly I can't use `mysqli_real_escape_string();` with prepared statements. Because I'm working as an intern and one of the tasks I need to do is update the code from `mysql_*`? And also I want to know is it necessary to use a prepared statement where there are only fixed values? For example somebody needs to approve or deny a request and the only input that person gets is the choice of 2 buttons approve and deny and each on of the buttons writes different values which is fixed. Do I need to use a prepared statement there? – BRoebie Dec 03 '15 at 10:51

2 Answers2

12

No, if you use prepared statements everywhere in your application you are safe from SQL injection.

You must use prepared statements for all queries, not just for ones that handle user input. If you don't, your application will still be buggy and susceptible to 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.

Dharman
  • 30,962
  • 25
  • 85
  • 135
Tim
  • 2,123
  • 4
  • 27
  • 44
10

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.

Community
  • 1
  • 1
Your Common Sense
  • 156,878
  • 40
  • 214
  • 345