Início / dba / Perguntas / 136273
Accepted
Matthew Verstraete
Asked: 2016-04-23 11:30:57 +0800 CST

Ainda devemos usar QUOTENAME para proteger contra ataques de injeção?

  • 772

Eu estava olhando para um procedimento armazenado antigo hoje e notei que estava usando quotenameos parâmetros de entrada. Depois de fazer algumas pesquisas para descobrir o que isso faz exatamente, me deparei com este site . Agora entendo o que ele faz e como usá-lo, mas o site diz que é usado como uma mitigação de ataques de SQL Injection. Quando eu costumava desenvolver aplicativos que consultavam diretamente um banco de dados, usando asp.net, eu usava os parâmetros ADO.Net para passar a entrada do usuário como um valor literal e nunca me preocupava em protegê-lo em meus procedimentos armazenados.

Agora estou escrevendo um procedimento armazenado que será usado por aplicativos que não escrevo, então preciso tentar me proteger de ataques de injeção no nível do procedimento, é quotenamea melhor maneira de fazer isso ou existe uma função mais nova/melhor método?

Código que me levou a esse padrão de pensamento ( @parm1é um parâmetro de entrada do usuário):

'SELECT project [Project], project_desc [Description], 
        customer [Customer], cpnyid [Company]
FROM PJPROJ (nolock)
where project like ' + quotename(@parm1,'''') + '
sql-server-2008 t-sql

1 respostas

  1. Best Answer

    Sim, as coisas não mudaram muito nesta área, você deve usar quotenamepara qualquer nome de objeto do servidor SQL que seja usado em SQL dinâmico (especialmente se eles forem fornecidos externamente ao seu código). Assim como a mitigação de injeção de SQL, isso também significa que seu código funcionará corretamente para nomes de identificadores não padrão.

    A função é apropriada apenas para nomes de objetos (por exemplo, tabela, coluna, nomes de banco de dados).

    Você deve tentar parametrizar todo o resto e usar sp_executesql, passando parâmetros em vez de concatená-los na string de consulta.

    O artigo definitivo sobre este tópico ainda é The Curse and Blessings of Dynamic SQL

    Editar. Agora que você forneceu o código, vejo que está passando o segundo parâmetro 'para adicionar as aspas externas e escapar de aspas simples dobrando-as antes de injetá-las na string. Este não é um bom uso de quotename. Ele falhará (retornará nulo) se a string for maior que 128 caracteres.

    Além disso, ainda pode deixar possibilidades de injeção de SQL se a string contiver U+02BC em vez do apóstrofo padrão e, em seguida, a string for atribuída a um varchar após o saneamento ( onde pode ser silenciosamente convertida em um apóstrofo regular )

    A forma correta de fazer isso é deixar a consulta parametrizada. E então passe o @parm1valor parasys.sp_executesql

    DECLARE @Sql NVARCHAR(MAX);

SET @Sql = '
SELECT project      [Project],
       project_desc [Description],
       customer     [Customer],
       cpnyid       [Company]
FROM   PJPROJ (nolock)
WHERE  project LIKE @parm1 
';

EXEC sys.sp_executesql
  @Sql,
  N'@parm1 varchar(100)',
  @parm1 = 'foobar%';
    • 17

relate perguntas