Can parameterized statement stop all SQL injection?

Question

If yes, why are there still so many successful SQL injections? Just because some developers are too dumb to use parameterized statements?

Answer 1

SQL injection is a subset of the larger problem of code injection, where data and code are provided over the same channel and data is mistaken for code. Parameterized queries prevent this from occurring by forming the query using context about what is data and what is code.

In some specific cases, this is not sufficient. In many DBMSes, it's possible to dynamically execute SQL with stored procedures, introducing a SQL injection flaw at the DBMS level. Calling such a stored procedure using parameterized queries will not prevent the SQL injection in the procedure from being exploited. Another example can be seen in this blog post.

More commonly, developers use the functionality incorrectly. Commonly the code looks something like this when done correctly:

db.parameterize_query("select foo from bar where baz = '?'", user_input)

Some developers will concatenate strings together and then use a parameterized query, which doesn't actually make the aforementioned data/code distinction that provides the security guarantees we're looking for:

db.parameterize_query("select foo from bar where baz = '" + user_input + "'")

Correct usage of parameterized queries provides very strong, but not impenetrable, protection against SQL injection attacks.

Answer 2

To protect your application from SQL injection, perform the following steps:

Step 1. Constrain input. Step 2. Use parameters with stored procedures. Step 3. Use parameters with dynamic SQL.

Refer to http://msdn.microsoft.com/en-us/library/ff648339.aspx

Answer 3

even if prepared statements are properly used throughout the web application’s own code, SQL injection flaws may still exist if database code components construct queries from user input in an unsafe manner. The following is an example of a stored procedure that is vulnerable to SQL injection in the @name parameter:

CREATE PROCEDURE show_current_orders
(@name varchar(400) = NULL)
AS
DECLARE @sql nvarchar(4000)
SELECT @sql = ‘SELECT id_num, searchstring FROM searchorders WHERE ‘ +
‘searchstring = ‘’’ + @name + ‘’’’;
EXEC (@sql)
GO

Even if the application passes the user-supplied name value to the stored procedure in a safe manner, the procedure itself concatenates this directly into a dynamic query and therefore is vulnerable.

Answer 4

First my answer to your first question: Yes, as far as I know, by using parameterized queries, SQL injections will not be possible anymore. As to your following questions, I am not sure and can only give you my opinion on the reasons:

I think it's easier to "just" write the SQL query string by concatenate some different parts (maybe even dependent on some logical checks) together with the values to be inserted. It's just creating the query and executing it. Another advantage is that you can print (echo, output or whatever) the sql query string and then use this string for a manual query to the database engine.

When working with prepared statements, you always have at least one step more: You have to build your query (including the parameters, of course) You have to prepare the query on the server You have to bind the parameters to the actual values you want to use for your query You have to execute the query.

That's somewhat more work (and not so straightforward to program) especially for some "quick and dirty" jobs which often prove to be very long-lived...

Best regards,

Box

Answer 5

Yes, the use of prepared statements stops all SQL injections, at least in theory. In practice, parameterized statements may not be real prepared statements, e.g. PDO in PHP emulates them by default so it's open to an edge case attack.

If you're using real prepared statements, everything is safe. Well, at least as long as you don't concatenate unsafe SQL into your query as reaction to not being able to prepare table names for example.

If yes, why are there still so many successful SQL injections? Just because some developers are too dumb to use parameterized statements?

Yes, education is the main point here, and legacy code bases. Many tutorials use escaping and those can't be easily removed from the web, unfortunately.

Answer 6

I avoid absolutes in programming; there is always an exception. I highly recommend stored procedures and command objects. A majority of my back ground is with SQL Server, but I do play with MySql from time to time. There are many advantages to stored procedures including cached query plans; yes, this can be accomplished with parameters and inline SQL, but that opens up more possibilities for injection attacks and doesn't help with separation of concerns. For me it's also much easier to secure a database as my applications generally only have execute permission for said stored procedures. Without direct table/view access it's much more difficult to inject anything. If the applications user is compromised one only has permission to execute exactly what was pre-defined.

My two cents.