Dynamic SQL Within A Stored Procedure Security

Question

I've got the SQL stored procedure from hell that I've created and all input parameters are parameterised for security but it's not running as quick as I'd like so I wanted to make it dynamic and so a bit more efficient.

I know I can keep my input parameters to my stored procedure, then within it create a dynamic SQL statement into which I can then pass the input parameters of the stored procedure, but are there any security implications I need to be aware of when doing this? I'm guessing not as it just another set of parameters and they should be treated the same as the parameters passed to the current stored procedure.

Obviously, producing code like this "WHERE OrderNo = ' + @orderno is asking for trouble - I will be doing 'WHERE OrderNo = @orderno' in the dynamic SQL, but is there anything else I need to be aware of? Thx MH

PS - before anyone suggests it, I can't create the SQL dynamically at the client side using LINQ or similar - it all (for various reasons) has to be contained and controlled at the database level

Answer 1

There is a form of SQL injection that many people don't think about when doing dynamic SQL in stored procedures: SQL Truncation attacks .

With a SQL truncation attack, the attacker injects a long peace of text making the used text variable overflow and lose part of the query.

This article gives more information about this.

Answer 2

Where your parameters are always Data Items, both when being passed to the StoredProc and when used in yor DynamicSQL, everything will stay safe.

Should any of your StoredProc's parameters end up being table or field names, and so forming part of the structure of the DynamicSQL itself, you introduce a new risk : That the parameter can be used to inject rogue SQL Code.

• To prevent against such an injection attack you should always validate any such parameters.

One example of how to do this would be to use the input parameter as a token, rather than substitute it directly into the DynamicSQL...

SET @SQL = @SLQ + CASE targetTable WHEN '1'  THEN 'table1'
                                   WHEN 'tx' THEN 'tableX'
                  END

Some people suggest you only need to validate on the client application. But that means that if someone becomes able to execute you SP's directly, the SP has become a point of attack. I always prefer to validate both on the client AND in the server.

EDIT Performance

Note that using DynamicSQL isn't always a guarnatee of performance increases. If you use parameterised queries, the execution plans can indeed be stored. But if the queries do vary greatly, you may still find a significant overhead in compiling the SQL.

There is also the fact that dependancy tracking is lost. It's not possible to see what tables the SP is dependant on, because the code is hidden away as strings.

I have very rarely found that DynamicSQL is needed. Often a complex query can be reformed as several optimised queries. Or the data can be re-structured to meet the new demands. Or even a rethink of both the data and the algorithm using the data. One might even be able to suggest that a dependancy on DynamicSQL is an indicator of another underlying problem.

Perhaps it's not in the scope of your question, but it would be interesting to see the actual puzzle you're facing; to see if anyone has any alternative approaches for you.