Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
SQL Injection é o processo pelo qual um utilizador malicioso insere Transact-SQL instruções em vez de entradas válidas. Se a entrada for passada diretamente para o servidor sem ser validada e se a aplicação executar inadvertidamente o código injetado, o ataque pode danificar ou destruir dados.
Qualquer procedimento que construa instruções SQL deve ser revisto quanto a vulnerabilidades de injeção, pois o SQL Server executará todas as consultas sintaticamente válidas que recebe. Até mesmo dados parametrizados podem ser manipulados por um atacante habilidoso e determinado. Se usar SQL dinâmico, certifique-se de parametrizar os seus comandos e nunca inclua valores de parâmetros diretamente na cadeia de consulta.
Anatomia de um ataque de injeção SQL
O processo de injeção funciona encerrando prematuramente uma cadeia de texto e anexando um novo comando. Como o comando inserido pode ter cadeias adicionais adicionadas antes de ser executado, o malfeito termina a cadeia injetada com a marca de comentário "--". O texto subsequente é ignorado no momento da execução. Múltiplos comandos podem ser inseridos usando um delimitador de ponto e vírgula (;)).
Desde que o código SQL injetado seja sintaticamente correto, a adulteração não pode ser detetada programaticamente. Por isso, deve validar todas as entradas do utilizador e rever cuidadosamente o código que executa comandos SQL construídos no servidor que está a usar. Nunca concatene a entrada do utilizador que não esteja validada. A concatenação de cadeias de caracteres é o principal ponto de entrada para a injeção de script.
Aqui ficam algumas orientações úteis:
Nunca construir Transact-SQL instruções diretamente a partir da entrada do utilizador; Use procedimentos armazenados para validar a entrada do utilizador.
Valide a entrada do utilizador testando o tipo, comprimento, formato e alcance. Use a função Transact-SQL QUOTENAME() para escapar dos nomes dos sistemas ou a função REPLACE() para escapar de qualquer carácter numa cadeia.
Implemente múltiplas camadas de validação em cada camada da sua aplicação.
Teste o tamanho e o tipo de dados da entrada e imponha limites apropriados. Isso pode ajudar a evitar saturações deliberadas de buffer.
Teste o conteúdo das variáveis de cadeia de caracteres e aceite apenas os valores esperados. Rejeitar entradas que contenham dados binários, sequências de escape e caracteres de comentário.
Quando estiver a trabalhar com documentos XML, valide todos os dados contra o seu esquema à medida que são introduzidos.
Em ambientes de múltiplos níveis, todos os dados devem ser validados antes de serem admitidos na zona de confiança.
Não aceite as seguintes strings nos campos a partir dos quais os nomes dos ficheiros podem ser construídos: AUX, CLOCK$, COM1 até COM8, CON, CONFIG$, LPT1 até LPT8, NUL e PRN.
Utilize SqlParameter objetos com procedimentos armazenados e comandos para fornecer verificação de tipos e validação de comprimento.
Utilize as expressões Regex no código do cliente para filtrar caracteres inválidos.
Estratégias SQL dinâmicas
Executar instruções SQL criadas dinamicamente no seu código procedural quebra a cadeia de propriedade, fazendo com que o SQL Server verifique as permissões do chamador contra os objetos acedidos pelo SQL dinâmico.
O SQL Server tem métodos para conceder aos utilizadores acesso a dados usando procedimentos armazenados e funções definidas pelo utilizador que executam SQL dinâmico.
Usar a impersonação com a cláusula Transact-SQL EXECUTE AS.
Assinar procedimentos armazenados com certificados.
EXECUTAR COMO
A cláusula EXECUTE AS substitui as permissões do chamador pelas do utilizador especificadas na cláusula EXECUTE AS. Procedimentos armazenados aninhados ou gatilhos são executados no contexto de segurança do utilizador proxy. Isto pode quebrar aplicações que dependem de segurança ao nível da linha ou que exigem auditoria. Algumas funções que retornam a identidade do utilizador devolvem o utilizador especificado na cláusula EXECUTE AS, e não o chamador original. O contexto de execução é revertido para o chamador original apenas uma vez concluída a execução do procedimento ou quando uma instrução REVERT é emitida.
Assinatura do certificado
Quando um procedimento armazenado que foi assinado com um certificado é executado, as permissões concedidas ao utilizador do certificado são fundidas com as do chamador. O contexto de execução mantém-se o mesmo; O utilizador do certificado não se faz passar pelo chamador. Assinar procedimentos armazenados requer vários passos para ser implementado. Cada vez que o procedimento é modificado, tem de ser re-assinado.
Acesso entre bases de dados
A cadeia de propriedade entre bases de dados não funciona em casos em que são executadas instruções SQL criadas dinamicamente. Pode contornar isto no SQL Server criando um procedimento armazenado que acede a dados noutra base de dados e assinando o procedimento com um certificado que existe em ambas as bases de dados. Isto dá aos utilizadores acesso aos recursos da base de dados utilizados pelo procedimento sem lhes conceder acesso ou permissões à base de dados.
Recursos externos
Para obter mais informações, consulte os seguintes recursos.
| Resource | Description |
|---|---|
| Procedimentos Armazenados e Injeção de SQL na Documentação Online do SQL Server | Os tópicos descrevem como criar procedimentos armazenados e como funciona o SQL Injection. |