SQL Server: Desinfección @param contra ataques de inyección

Question

Por el bien del argumento, digamos que me tengo que crear una variable local que contiene una consulta SQL que tiene una inserción:

DECLARE @insert NVARCHAR(MAX) 
SELECT @insert = 'INSERT INTO [dbo].[' + @table + '] VALUES... 
EXEC (@insert) 

Este tubo es también va a contener un valor de columna:

DECLARE @insert NVARCHAR(MAX) 
SELECT @insert = 
    'INSERT INTO [dbo].[' + @table + '] VALUES (N''' + @message + ''')' 
EXEC (@insert) 

Ahora, obviamente estoy preocupado por un ataque de inyección, y me gustaría para garantizar el valor de ese mensaje @ no puede tomar el valor de @ inserción malicioso o mal formado como una consulta a EXEC .

Esto nos lleva a mi pregunta: ¿es suficiente escaparse de los 'caracteres en @message? ¿Hay algún otro personaje que pueda aparecer en @mensaje que pueda escapar?

Ejemplo:

DECLARE @insert NVARCHAR(MAX) 
SELECT @message = REPLACE(@message,'''','''''') 
SELECT @insert = 
    'INSERT INTO [dbo].[' + @table + '] VALUES (N''' + @message + ''')' 
EXEC (@insert) 

(cuando digo "tienen que", esto se debe a mi consulta es en un procedimiento almacenado, y este procedimiento almacenado acepta @table, que es la tabla de destino a INSERT En. No estoy interesado en discutir mi arquitectura o por qué la tabla para INSERTAR se especifica "dinámicamente" a través de un parámetro de procedimiento. Por favor, abstente de comentar en este a menos que exista otra forma además de EXEC() de consultar para especificar una tabla para INSERTAR en cuando el nombre de la tabla se recibe como un parámetro de procedimiento).

Answer 1

Utilice sp_executesql y el quotename() incorporado. Este artículo, The Curse and Blessings of Dynamic SQL, es más o menos la referencia definitiva.

Answer 2

En lugar de llamar a EXEC (@somesql), sugiero usar el sp_executesql stored procedure. Específicamente, esto le permite pasar parámetros, y el sistema verificará que los parámetros sean válidos.

Answer 3

En primer lugar, podría consultar la información del esquema con T-SQL regular y asegurarse de que el nombre de la tabla exista primero. De esta forma, si tiene SQL mal formado, no se ejecutará como código. Solo será un nombre de tabla VARCHAR.

DECLARE @Table AS VARCHAR(MAX) 
DECLARE @Exists AS BIT 

SET @Table = 'Vicious malformed dynamic SQL' 

SELECT @Exists = COUNT(TABLE_NAME) 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_NAME = @Table 

IF (@Exists = 1) 
    BEGIN 
    PRINT 'Table exists' 
    -- Execute dynamic SQL. 
    END 
ELSE 
    PRINT 'Invalid table' 

(o simplemente utilizar SI EXISTE (SELECCIONAR ....))

Answer 4

Al parecer hay un límite de 128 de longitud a QUOTENAME(), incluso en 2008, de acuerdo con mi prueba, ya que espera un SQL identificador. La referencia sugiere la creación de una función quotestring(), que hace lo mismo que:

REPLACE(@variable,'''','''''') 

Por lo tanto estoy proponiendo que la respuesta es crear una función de la REPLACE() anteriores del siguiente modo:

CREATE FUNCTION quotestring(@string nvarchar(MAX)) 
RETURNS nvarchar(MAX) AS 
BEGIN 
    RETURN(REPLACE(@string,'''','''''')) 
END 

... A menos que haya entendido mal algo.