SQL Injection Prevention

  • Hello gurus and the newbie’s. I have a question on SQL Injection. So far I have done my own research on this subject for a while now and techniques for preventing SQL Injection ranges from Different permissions for connection from the APP layer to User Input validation. And of course I am making sure that all these prevention techniques are incorporated into our application but there is one prevention technique that I can't avoid due to the type of application we are developing and that is DYNAMIC SQL. As a result, I am looking for the best solution/technique to prevent SQL Injection (in the Database Layer) knowing that Dynamic SQL will be used in the application. My first and best solution is to write my own sp_executesql (called my_sp_executesql) and instead of developers calling the system supplied sp_executesql, they will call my_sp_executesql. Within this stored proc, I will parse the dynamically generated T-SQL Code for certain reserve words/characters like, DROP, CREATE, SETUSER, ALTER, --, ;, etc. If any of these exist, it will return a user define message to the caller. My question is, is this the best solution for preventing SQL Injection in the database layer of the application? Or is there another way, knowing that Dynamic SQL will be used in the application?

  • Please don't crosspost. see my reply here:

    SQL Injection Prevention under T-SQL

    K. Brian Kelley
    @kbriankelley

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply