Prolepse SQL Injection - SQL Server part 2

Analise todas as entradas:

Sempre valide entrada de usuário testando tipo, comprimento, formato e intervalo. Quando você estiver implementando precauções contra entrada mal-intencionada, considere os cenários de arquitetura e implantação de seu aplicativo. Lembre-se de que programas projetados para executar em um ambiente seguro podem ser copiados para um ambiente sem segurança. As sugestões seguintes devem ser consideradas práticas recomendadas:

• Teste o tamanho e tipo de dados de entrada e imponha limites apropriados. Isso pode ajudar a impedir excesso deliberado de buffer.
• Teste o conteúdo de variáveis de cadeia de caracteres e só aceite valores esperados. Rejeite entradas que contenham dados binários, seqüências de escape e caracteres de comentário. Isso pode ajudar a impedir injeção de script e proteger contra explorações de excesso de buffer.
• Quando você estiver trabalhando com documentos XML, valide todos os dados em seu esquema à medida que são inseridos.
• Nunca construa instruções Transact-SQL diretamente da entrada do usuário.
• Use procedimentos armazenados para validar entrada de usuário.
• Em ambientes de várias camadas, todos os dados devem ser validados antes de serem admitidos à zona de confiança. Os dados que não passam pelo processo de validação devem ser rejeitados e um erro deve ser retornado à camada anterior.
• Implemente várias camadas de validação. Precauções tomadas contra usuários casualmente mal-intencionados podem ser ineficazes contra determinados invasores. Uma prática mais recomendada é validar a entrada na interface do usuário e em todos os pontos subseqüentes onde ele cruza um limite confiável.
  Por exemplo, a validação de dados em um aplicativo cliente pode evitar injeção de script simples. No entanto, se a próxima camada assumir que sua entrada já foi validada, qualquer usuário mal-intencionado que possa contornar um cliente poderá ter acesso irrestrito ao sistema.
• Nunca concatene entrada de usuário que não seja validada. A concatenação de cadeia de caracteres é o ponto principal de entrada de injeção de script.
• Não aceite as seguintes cadeias de caracteres em campos dos quais nomes de arquivos podem ser construídos: AUX, CLOCK$, COM1 a COM8, CON, CONFIG$, LPT1 a LPT8, NUL e PRN.

Sempre que puder, rejeite entrada que contenha os caracteres a seguir.

Use parâmetros SQL de tipo seguro

A coleção Parâmetros no SQL Server fornece verificação de tipo e validação de comprimento. Se você usar a coleção Parâmetros, a entrada será tratada como um valor literal e não como código executável. Um benefício adicional de usar a coleção Parâmetros é que você pode impor verificações de tipo e comprimento. Valores fora do intervalo irão disparar uma exceção. O seguinte fragmento de código mostra o uso da coleção Parâmetros:

SqlDataAdapter myCommand = new SqlDataAdapter("Usuario", conn);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@ID_Usuario",
SqlDbType.VarChar, 11);

parm.Value = Login.Text;

Nesse exemplo, o parâmetro @ID_Usuario é tratado como um valor literal e não como código executável. Esse valor é verificado quanto ao tipo e comprimento. Se o valor @ID_Usuario não estiver de acordo com o tipo especificado e as restrições de comprimento, uma exceção será gerada.

Filtrando a entrada

A filtragem de entrada também pode ser útil para proteger contra injeção de SQL, removendo caracteres de escape. Porém, por causa do número grande de caracteres que podem causar problemas, essa não é uma defesa confiável. O exemplo a seguir procura o delimitador de cadeia de caracteres.

private string SafeSqlLiteral(string inputSQL)
{
  return inputSQL.Replace("'", "''");
}

Cláusulas LIKE

Observe que se você estiver usando uma cláusula LIKE, os caracteres curinga ainda poderão escapar:

s = s.Replace("[", "[[]");
s = s.Replace("%", "[%]");
s = s.Replace("_", "[_]");

Revisando código para injeção SQL

Você deveria revisar todos os códigos que chamam EXECUTE, EXEC ou sp_executesql. Você pode usar consultas semelhantes à que segue para ajudá-lo a identificar procedimentos que contenham essas instruções.

SELECT object_Name(id) FROM syscomments
WHERE UPPER(text) LIKE '%EXECUTE  (%' 
OR UPPER(text) LIKE '%EXECUTE  (%'
OR UPPER(text) LIKE '%EXECUTE  (%' 
OR UPPER(text) LIKE '%EXECUTE  (%'
OR UPPER(text) LIKE '%EXEC (%' 
OR UPPER(text) LIKE '%EXEC (%'
OR UPPER(text) LIKE '%EXEC (%' 
OR UPPER(text) LIKE '%EXEC (%'
OR UPPER(text) LIKE '%SP_EXECUTESQL%'

SET @temp = N'select * from dbo.vendas where cidade ='''

+ REPLACE (@cidade,'''','''''') + N'''' 

Pensando em tudo isso a Microsoft lançou um kit de ferramentas que pretende auxiliar desenvolvedores e administradores de websites a bloquear e erradicar a recente onda de ataques de SQL Injection (Injeção SQL). 

As ferramentas são:

Scrawlr -   Examina os arquivos do site e simultaneamente analisa os parâmetros usados em cada página buscando por vulnerabilidades do injeção SQL. 

Microsoft Source Code Analyzer for SQL Injection -  Chamada de MSCASI, esta é uma ferramenta de análise estática para análise dos códigos em ASP. Para executá-la é necessário ter acesso ao código fonte da página. 

URLScan 3.1 -  Esta ferramenta restringe os tipos de solicitações HTTP que o IIS (Internet Information Services) irá processar. Ao bloquear alguns tipos específicos de solicitações, a ferramenta pode prevenir certos ataques.

Existe ainda formas de, por comandos em SQL, executar comandos arbitrários dentro do server que roda o sql server. Por exemplo, poderia obter o dir de um c: ou até mesmo criar e apagar arquivos dentro da máquina. Mas isso, é um outro assunto. Por hora, lembramos que todas essas situações descritas poderiam ser executadas em sites com SQL Server. 

Segurança é coisa séria e vale a pena tomar todas as precauções ao nosso alcance para preservar nossos dados e nossos empregos ...

Nos próximos tópicos falamos mais sobre cada uma das ferramentas.
Grande abraços