6

I am doing some research in web security, and the reviser of my article said:

"It should be clear that to avoid SQL Injection, the application should use prepared statements, stored procedures and escape input"

My question is: Is one of these methods isn't enough? Ok, prepared statements or stored procedures are better than a simple escape, but if I use PDO, why i should escape the input or have a stored procedure? Does this make sense?

ridecar2
  • 1,968
  • 16
  • 34
Daniel
  • 578
  • 1
  • 8
  • 22
  • 1
    From reading your question I get the impression that you are interpreting the phrase *‘prepared statements, stored procedures and escape input’* like *‘(prepared statements or stored procedures) and escape input’*. :) To be honest (although it may be silly of me), I would interpret it as *‘prepared statements or stored procedures or escape input’*. – Andriy M Jan 03 '12 at 16:22

3 Answers3

8

I would change the reviser's wording to:

It should be clear that to avoid SQL Injection, the application should use prepared statements, escape input, or filter application data before interpolating into an SQL string.

It's not necessary to escape a value if you're going to pass as a parameter. In fact, you should not, because you'll insert literal backslashes into your data.

You need to interpolate strings into your SQL statement when you can't use a query parameter. Examples include:

  • Table names and column names, which have their own syntax for delimited identifiers. These must be part of the SQL query at prepare time, so the RDBMS can parse and validate them.

  • SQL keywords, which should be sanitized but cannot be escaped because they are not delimited.

  • Other syntax or expressions.

  • Some cases where literal values must be provided at prepare time, e.g. MySQL's fulltext functions do not support parameters for the search pattern.

Stored procedures are not a defense against SQL injection. You can prepare and execute unsafe dynamic SQL statements inside a stored procedure. See http://thedailywtf.com/Articles/For-the-Ease-of-Maintenance.aspx for a great story about that.

I cover all these cases in my presentation SQL Injection Myths and Fallacies. That may be a helpful resource for you.

I also cover SQL injection defense in a chapter of my book, SQL Antipatterns Volume 1: Avoiding the Pitfalls of Database Programming.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
4

If i use PDO, why i should [es]scape the input or have a stored procedure?

As long as you always use PDO, I don't see a reason to bother with input escaping or SPs.

Matt Ball
  • 354,903
  • 100
  • 647
  • 710
2

When in doubt, ask yourself: will this piece of plain input data be escaped by some API down the line? Most of the time they will, except when you manually build SQL sentences from input data.

You should not escape if you use PDO. You should not escape if you use JDBC Prepared Statements with parameters. Similarly, most other APIs also take care of this. Stored procedures are not even concerned with escaped data and using them will not magically avoid SQL injection security issues if the input data is not escaped in the SQL that runs the procedure.

Always SQL-Escape data that you put in SQL sentences. Never SQL-Escape data outside SQL sentences.

jjmontes
  • 24,679
  • 4
  • 39
  • 51