Sql-server – Security Risks with having Test Stored Procedures that have SQL Injection Vulnerability

No, stored procedures do not prevent SQL injection. Here's an actual example (from an in-house app someone created where I work) of a stored procedure that unfortunately permits SQL injection:

This sql server code:

CREATE PROCEDURE [dbo].[sp_colunmName2]   
    @columnName as nvarchar(30),
    @type as nvarchar(30), 
    @searchText as nvarchar(30)           
AS
BEGIN
    DECLARE @SQLStatement NVARCHAR(4000)
    BEGIN
        SELECT @SQLStatement = 'select * from Stations where ' 
            + @columnName + ' ' + @type + ' ' + '''' + @searchText + '''' 
        EXEC(@SQLStatement)
    END      
END
GO

roughly equivalent to postgres:

CREATE or replace FUNCTION public.sp_colunmName2 (
    columnName  varchar(30),
    type varchar(30), 
    searchText  varchar(30) ) RETURNS SETOF stations LANGUAGE plpgsql            
AS
$$
DECLARE SQLStatement VARCHAR(4000);
BEGIN
    SQLStatement = 'select * from Stations where ' 
            || columnName || ' ' || type || ' ' || ''''|| searchText || '''';
    RETURN QUERY EXECUTE  SQLStatement;
END
$$;

The developer's idea was to create a versatile search procedure, but the result is that the WHERE clause can contain anything the user wants, allowing a visit from little Bobby Tables.

Whether you use SQL statements or stored procedure doesn't matter. What matters is whether your SQL uses parameters or concatenated strings. Parameters prevent SQL injection; concatenated strings allow SQL injection.

I do not think that your requirements are complete as there are reasons that your prior attempts did not work that are not reflected in the stated Requirements. You mentioned in attempted solution #1 that you need to be able to debug the code / know what version it is, and the client needs to be able to replicate the code. Are these two issues current requirements?

If the need for replication is still a requirement, then that conflicts with the requirement to be "compiled (secured)".

I will assume that the client's server is something they have full sa access to such that DENYing the VIEW ANY DEFINITION permission is not a viable approach.

One thing to try is taking the T-SQL of your Stored Procedures and encapsulating each one, unchanged, into CLR Stored Procedures. You would place one or more related Stored Procedures into an Assembly. Here are some thoughts about this:

• Assemblies conveniently have a version number that can be seen in the sys.assemblies catalog view, SSMS (right-click on the Assembly to view the Properties), and the ASSEMBLYPROPERTY function.
• You probably don't want to put all of the Stored Procedures into a single Assembly, but you also don't want to have one Assembly per Stored Procedure. You can have one class file per Stored Procedure and several of those included in a single Assembly.
• All of the Assemblies should use WITH PERMISSION_SET = SAFE
• The only code in each CLR Stored Procedure would be:
  • Create a SqlCommand with a CommandType of CommandType.Text and CommandText set to the current T-SQL Stored Procedure content
  • No SqlConnection should be needed (if it is, then it is just "context connection=true")
  • Map the SqlParameterCollection of the SqlCommand to the input parameters of the CLR Stored Procedure
  • Call SqlContext.Pipe.ExecuteAndSend(_YourSqlCommand);
• The Assembly and related Stored Procedures would be loaded into each Client DB
• CLR Stored Procedures are not able to be replicated, but that could probably be worked around