Menu

Tutorial de teste de injeção de SQL (exemplo e prevenção de ataque de injeção de SQL)

  • Principal
  • Teste Da Web
  • Tutorial de teste de injeção de SQL (exemplo e prevenção de ataque de injeção de SQL)

sql injection testing tutorial example

Experimente Nosso Instrumento Para Eliminar Problemas

perguntas da entrevista j2ee para desenvolvedores sênior

Exemplos de injeção de SQL e maneiras de evitar ataques de injeção de SQL em aplicativos da Web

Ao testar um site ou sistema, o objetivo do testador é garantir que o produto testado seja o mais protegido possível.

O teste de segurança geralmente é executado para essa finalidade. Para realizar este tipo de teste, inicialmente, precisamos considerar quais ataques são mais prováveis ​​de acontecer. SQL Injection é um desses ataques.

Exemplo e prevenção de anexo de injeção SQL

SQL Injection é considerado um dos ataques mais comuns, pois pode trazer consequências graves e prejudiciais para o seu sistema e dados confidenciais.

O que você aprenderá:

O que é SQL Injection?

Algumas das entradas do usuário podem ser usadas no enquadramento Instruções SQL que são executados pelo aplicativo no banco de dados. É possível que um aplicativo NÃO manipule as entradas fornecidas pelo usuário adequadamente.

Se esse é o caso, um usuário mal-intencionado pode fornecer entradas inesperadas ao aplicativo que são então usadas para enquadrar e executar instruções SQL no banco de dados. Isso é chamado de injeção de SQL. As consequências de tal ação podem ser alarmantes.

Como o próprio nome indica, o objetivo do ataque de injeção de SQL é injetar o código SQL malicioso.

Cada campo de um site é como uma porta para o banco de dados. No formulário de login, o usuário insere os dados de login, no campo de pesquisa o usuário insere um texto de pesquisa, no formulário de salvamento de dados o usuário insere os dados a serem salvos. Todos esses dados indicados vão para o banco de dados.

Em vez de dados corretos, se qualquer código malicioso for inserido, então há a possibilidade de algum dano sério acontecer ao banco de dados e a todo o sistema.

A injeção SQL é realizada com a linguagem de programação SQL. SQL (Structured Query Language) é usado para gerenciar os dados mantidos no banco de dados. Portanto, durante esse ataque, esse código de linguagem de programação está sendo usado como uma injeção maliciosa.

Este é um dos ataques mais populares, pois os bancos de dados são usados ​​para quase todas as tecnologias.

Muitos aplicativos usam algum tipo de banco de dados. Um aplicativo em teste pode ter uma interface de usuário que aceita entrada do usuário que é usada para realizar as seguintes tarefas:

# 1) Mostre os dados armazenados relevantes para o usuário, por exemplo o aplicativo verifica as credenciais do usuário usando as informações de login inseridas pelo usuário e expõe apenas a funcionalidade e os dados relevantes para o usuário

#dois) Salve os dados inseridos pelo usuário no banco de dados, por exemplo uma vez que o usuário preenche um formulário e o envia, o aplicativo prossegue para salvar os dados no banco de dados; esses dados são então disponibilizados para o usuário na mesma sessão, bem como nas sessões subsequentes

Riscos de injeção de SQL

Hoje em dia, um banco de dados está sendo usado para quase todos os sistemas e sites, pois os dados devem ser armazenados em algum lugar.

Como dados confidenciais são armazenados no banco de dados, há mais riscos envolvidos na segurança do sistema. Se qualquer site pessoal ou dados de blog forem roubados, não haverá muito dano em comparação com os dados que seriam roubados do sistema bancário.

O principal objetivo deste ataque é hackear o banco de dados do sistema, portanto, as consequências desse ataque podem ser realmente prejudiciais.

As seguintes coisas podem resultar da injeção de SQL

  • Hackear a conta de outra pessoa.
  • Roubo e cópia de dados confidenciais de um site ou sistema.
  • Alterar os dados confidenciais do sistema.
  • Excluindo dados confidenciais do sistema.
  • O usuário pode fazer login no aplicativo como outro usuário, até mesmo como administrador.
  • O usuário pode visualizar informações privadas pertencentes a outros usuários, por exemplo detalhes dos perfis de outros usuários, detalhes da transação, etc.
  • O usuário pode alterar as informações de configuração do aplicativo e os dados de outros usuários.
  • O usuário pode modificar a estrutura do banco de dados; até mesmo excluir tabelas no banco de dados do aplicativo.
  • O usuário pode assumir o controle do servidor de banco de dados e executar comandos nele à vontade.

Os riscos listados acima podem realmente ser considerados sérios, pois restaurar um banco de dados ou seus dados pode custar muito. A recuperação dos dados e do sistema perdidos pode custar reputação e dinheiro à sua empresa. Portanto, é altamente recomendável proteger seu sistema contra este tipo de ataque e considerar o Teste de Segurança como um bom investimento na reputação de seu produto e empresa.

Como testador, gostaria de comentar que testar contra possíveis ataques é uma boa prática, mesmo que Teste de Segurança não foi planejado. Dessa forma, você pode proteger e testar o produto contra casos inesperados e usuários mal-intencionados.

A Essência Deste Ataque

Conforme mencionado anteriormente, a essência desse ataque é invadir o banco de dados com fins maliciosos.

Para realizar este Teste de Segurança, inicialmente, você precisa encontrar as partes vulneráveis ​​do sistema e, em seguida, enviar o código SQL malicioso para o banco de dados. Se esse ataque for possível para um sistema, o código SQL malicioso apropriado será enviado e ações prejudiciais podem ser executadas no banco de dados.

Cada campo de um site é como uma porta para o banco de dados. Qualquer dado ou entrada que costumamos inserir em qualquer campo do sistema ou site vai para a consulta do banco de dados. Portanto, em vez de dados corretos, se digitarmos algum código malicioso, ele pode ser executado na consulta de banco de dados e trazer consequências danosas.

Ferramenta Recomendada

# 1) Kiuwan

banner kiuwan

Encontre e corrija vulnerabilidades com facilidade, como injeção de SQL em seu código, em cada estágio do SDLC. Kiuwan é compatível com os padrões de segurança mais rigorosos, incluindo OWASP, CWE, SANS 25, HIPPA e mais.

Integre Kiuwan em seu IDE para feedback instantâneo durante o desenvolvimento. Kiuwan oferece suporte a todas as principais linguagens de programação e se integra às principais ferramentas DevOps.

=> Digitalize o seu código gratuitamente

Para realizar este ataque, temos que mudar o ato e o propósito de uma consulta de banco de dados apropriada. Um dos métodos possíveis para realizá-lo é fazer a consulta sempre verdadeira e depois inserir o código malicioso. Alterar a consulta do banco de dados para sempre verdadeiro pode ser executado com código simples como ‘ou 1 = 1; -.

Essence of SQL Injection

Os testadores devem ter em mente que, ao verificar se a alteração da consulta para sempre verdadeiro pode ser realizada ou não, devem ser tentadas aspas diferentes - simples e duplas. Portanto, se tentamos código como ‘ou 1 = 1; -, também devemos tentar o código com aspas duplas“ ou 1 = 1; -.

Essensce de SQL Injection

Por exemplo, vamos considerar que temos uma consulta, que está procurando a palavra inserida na tabela do banco de dados:

selecione * das notas nt onde nt.subject = ‘search_word‘;

Portanto, em vez da palavra de pesquisa, se inserirmos uma consulta de injeção SQL 'ou 1 = 1; -, a consulta se tornará sempre verdadeira.

selecione * das notas nt onde nt.subject = ‘‘ ou 1 = 1; -

Neste caso, o parâmetro “assunto“ é fechado com a citação e então temos o código ou 1 = 1, o que torna a consulta sempre verdadeira. Com o sinal “-“ comentamos o resto do código da consulta, que não será executado. É uma das maneiras mais populares e fáceis de começar a controlar a consulta.

Alguns outros códigos também podem ser usados ​​para tornar a consulta sempre verdadeira, como:

  • ‘Ou‘ abc ’=‘ abc ‘; -
  • ‘Ou‘ ‘=‘ ‘; -

A parte mais importante aqui é que depois do sinal de vírgula podemos inserir qualquer código malicioso que gostaríamos de executar.

Por exemplo, pode ser ‘ou 1 = 1; soltar notas da mesa; -

Drop Table Notes

Se essa injeção for possível, qualquer outro código malicioso pode ser escrito. Nesse caso, dependerá apenas do conhecimento e da intenção do usuário malicioso. Como verificar a injeção de SQL?

A verificação dessa vulnerabilidade pode ser realizada com muita facilidade. Às vezes, é suficiente digitar ‘ou“ assinar nos campos testados. Se retornar alguma mensagem inesperada ou extraordinária, podemos ter certeza de que a injeção SQL é possível para esse campo.

Por exemplo , se você receber uma mensagem de erro como 'Erro interno do servidor' como resultado da pesquisa, podemos ter certeza de que esse ataque é possível nessa parte do sistema.

Outros resultados que podem notificar um possível ataque incluem:

  • Página em branco carregada.
  • Nenhuma mensagem de erro ou sucesso - a funcionalidade e a página não reagem à entrada.
  • Mensagem de sucesso para código malicioso.

Vamos dar uma olhada em como isso funciona na prática.

Por exemplo, Vamos testar se uma janela de login apropriada é vulnerável a SQL Injection. Para isso, no campo do endereço de e-mail ou senha, basta digitar o sinal conforme mostrado abaixo.

Endereço de email

Se tal entrada retornar resultados como mensagem de erro ‘Erro interno do servidor’ ou qualquer outro resultado impróprio listado, então podemos quase ter certeza de que este ataque é possível para aquele campo.

Erro do Servidor Interno

Muito complicado Código de injeção SQL também pode ser tentado. Gostaria de mencionar que, em minha carreira, não encontrei nenhum caso em que houvesse a mensagem 'Erro interno do servidor' como resultado do sinal, mas às vezes os campos não reagiam para códigos SQL mais complicados.

Portanto, verificar a injeção de SQL com aspas simples 'é uma maneira bastante confiável de verificar se esse ataque é possível ou não.

Se a aspa simples não retornar nenhum resultado impróprio, podemos tentar inserir aspas duplas e verificar os resultados.

Citação única

Além disso, o código SQL para alterar a consulta para sempre verdadeiro pode ser considerado uma forma de verificar se esse ataque é possível ou não. Ele fecha o parâmetro e altera a consulta para ‘verdadeiro’. Portanto, se não for validada, tal entrada também pode retornar algum resultado inesperado e informar o mesmo, que este ataque é possível neste caso.

Essensce de SQL Injection

A verificação de possíveis ataques SQL também pode ser realizada a partir do link do site. Suponha que temos o link de um site como http://www.testing.com/books=1 . Neste caso, ‘books’ é um parâmetro e ‘1’ é seu valor. Se no link fornecido escrevermos 'sinal em vez de 1, verificaremos a possível injeção.

Portanto, ligue http://www.testing.com/books= será como um teste se o ataque SQL é possível para o site http://www.testing.com ou não.

Testando Link

Neste caso, se o link http://www.testing.com/books= retorna uma mensagem de erro como 'Erro interno do servidor' ou uma página em branco ou qualquer outra mensagem de erro inesperada, então também podemos ter certeza de que a injeção de SQL é possível para esse site. Posteriormente, podemos tentar enviar um código SQL mais complicado por meio do link do site.

Para verificar se esse ataque é possível por meio do link do site ou não, um código como ‘ou 1 = 1; - também pode ser enviado.

Testando links

Como um testador de software experiente, gostaria de lembrar que não apenas a mensagem de erro inesperada pode ser considerada uma vulnerabilidade de injeção SQL. Muitos testadores verificam possíveis ataques apenas de acordo com mensagens de erro.

No entanto, deve ser lembrado que nenhuma mensagem de erro de validação ou mensagem de sucesso para código malicioso também pode ser um sinal de que esse ataque é possível.

Teste de segurança de aplicativos da Web contra injeção de SQL

Testes de segurança de aplicativos da web explicados com exemplos simples:

Como as consequências de permitir essa técnica de vulnerabilidade podem ser graves, segue-se que esse ataque deve ser testado durante o teste de segurança de um aplicativo. Agora, com uma visão geral dessa técnica, vamos entender alguns exemplos práticos de injeção de SQL.

Importante: Este teste de injeção de SQL deve ser testado apenas no ambiente de teste.

Se o aplicativo tiver uma página de login, é possível que o aplicativo use SQL dinâmico, como a instrução abaixo. Espera-se que esta instrução retorne pelo menos uma única linha com os detalhes do usuário da tabela Usuários como o conjunto de resultados quando houver uma linha com o nome de usuário e a senha inseridos na instrução SQL.

SELECIONE * DE Usuários ONDE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & '’; '

Se o testador inserir John como strUserName (na caixa de texto para nome de usuário) e Smith como strPassword (na caixa de texto para senha), a instrução SQL acima se tornará:

SELECT * FROM Users WHERE User_Name = 'John' AND Password = 'Smith’;

Se o testador inserisse John’– como strUserName e não strPassword, a instrução SQL se tornaria:

SELECT * FROM Users WHERE User_Name = 'John'-- AND Password = 'Smith’;

Observe que a parte da instrução SQL após John é transformada em um comentário. Se houver algum usuário com o nome de usuário John na tabela Usuários, o aplicativo pode permitir que o testador efetue login como o usuário John. O testador agora pode visualizar as informações privadas do usuário John.

E se o testador não souber o nome de nenhum usuário existente do aplicativo? Nesse caso, o testador pode tentar nomes de usuário comuns como admin, administrador e sysadmin. Se nenhum desses usuários existir no banco de dados, o testador pode inserir John 'ou' x '=' x como strUserName e Smith 'ou' x '=' x como strPassword. Isso faria com que a instrução SQL se tornasse como a abaixo.

SELECT * FROM Users WHERE User_Name = 'John' or 'x'='x' AND Password = 'Smith’ or ‘x’=’x’;

Visto que a condição ‘x’ = ’x’ é sempre verdadeira, o conjunto de resultados consistiria em todas as linhas da tabela Usuários. O aplicativo pode permitir que o testador faça login como o primeiro usuário na tabela Usuários.

Importante: o testador deve solicitar ao administrador do banco de dados ou ao desenvolvedor que copie a tabela em questão antes de tentar os ataques a seguir.

Se o testador inserir John ’; DROP table users_details; ’- como strUserName e qualquer coisa como strPassword, a instrução SQL se tornaria como a abaixo.

SELECT * FROM Users WHERE User_Name = ‘John’; DROP table users_details;’ –‘ AND Password = 'Smith';

Esta declaração pode fazer com que a tabela “users_details” seja permanentemente excluída do banco de dados.

Embora os exemplos acima tratem do uso da técnica de injeção de SQL apenas na página de login, o testador deve testar essa técnica em todas as páginas do aplicativo que aceitam entrada do usuário em formato textual, por exemplo, páginas de pesquisa, páginas de feedback, etc.

A injeção de SQL pode ser possível em aplicativos que usam SSL. Mesmo um firewall pode não ser capaz de proteger o aplicativo contra essa técnica.

Tentei explicar essa técnica de ataque de uma forma simples. Eu gostaria de reiterar que este ataque deve ser testado apenas em um ambiente de teste e não no ambiente de desenvolvimento, ambiente de produção ou qualquer outro ambiente.

diferença entre o caso de teste e o cenário de teste

Em vez de testar manualmente se o aplicativo é vulnerável a ataques de SQL ou não, pode-se usar um Web Vulnerability Scanner que verifica essa vulnerabilidade.

Leitura relacionada: Teste de segurança do aplicativo da Web . Verifique isso para obter mais detalhes sobre as diferentes vulnerabilidades da web.

Partes vulneráveis ​​deste ataque

Antes de iniciar o processo de teste, todo testador sincero deve saber mais ou menos quais partes seriam mais vulneráveis ​​a um possível ataque.

Também é uma boa prática planejar qual campo do sistema deve ser testado exatamente e em que ordem. Em minha carreira de teste, aprendi que não é uma boa ideia testar campos contra ataques SQL aleatoriamente, pois alguns campos podem ser perdidos.

Como esse ataque está sendo executado no banco de dados, todas as partes do sistema de entrada de dados, campos de entrada e links de sites estão vulneráveis.

As partes vulneráveis ​​incluem:

  • Campos de login
  • Campos de busca
  • Campos de comentário
  • Qualquer outra entrada de dados e campos de salvamento
  • Links do site

É importante notar que ao testar esse ataque não é suficiente verificar apenas um ou alguns campos. É bastante comum que um campo esteja protegido contra SQL Injection, mas outro não. Portanto, é importante não se esquecer de testar todos os campos do site.

Automatizando testes de injeção de SQL

Como alguns sistemas ou sites testados podem ser bastante complicados e conter dados confidenciais, o teste manual pode ser muito difícil e também leva muito tempo. Portanto, testar esse ataque com ferramentas especiais pode ser muito útil às vezes.

Uma dessas ferramentas de injeção de SQL é SOAP UI . Se tivermos testes de regressão automatizados no nível da API, também podemos alternar a verificação contra esse ataque usando esta ferramenta. Na ferramenta SOAP UI, já existem modelos de código preparados para verificação contra esse ataque. Esses modelos também podem ser complementados por seu próprio código escrito.

É uma ferramenta bastante confiável.

No entanto, um teste já deve ser automatizado no nível da API, o que não é tão fácil. Outra maneira possível de testar automaticamente é usando vários plug-ins de navegador.

Deve ser mencionado que, mesmo que as ferramentas automatizadas economizem seu tempo, nem sempre são consideradas muito confiáveis. Se estivermos testando um sistema bancário ou qualquer site com dados muito confidenciais, é altamente recomendável testá-lo manualmente. Onde você pode ver os resultados exatos e analisá-los. Além disso, neste caso, podemos ter certeza de que nada foi ignorado.

Comparação com outros ataques

O SQL Injection pode ser considerado um dos ataques mais sérios, pois influencia o banco de dados e pode causar sérios danos aos seus dados e a todo o sistema.

Com certeza pode ter consequências mais sérias do que uma injeção de Javascript ou uma injeção de HTML, já que ambas são executadas no lado do cliente. Para efeito de comparação, com este ataque, você pode ter acesso a todo o banco de dados.

Deve ser mencionado que, para testar contra este ataque, você deve ter um conhecimento muito bom da linguagem de programação SQL e, em geral, você deve saber como as consultas de banco de dados estão funcionando. Além disso, ao realizar este ataque de injeção, você deve ser mais cuidadoso e observador, pois qualquer imprecisão pode ser deixada como vulnerabilidade de SQL.

Conclusão

Espero que você tenha uma ideia clara do que é injeção de SQL e como devemos evitar esses ataques.

No entanto, é altamente recomendável testar esse tipo de ataque sempre que um sistema ou site com um banco de dados estiver sendo testado. Qualquer banco de dados deixado ou vulnerabilidades do sistema podem custar a reputação de uma empresa e muitos recursos para restaurar todo o sistema.

Como o teste contra esta injeção ajuda a encontrar o máximo vulnerabilidades de segurança importantes , também é recomendável investir em seu conhecimento e ferramentas de teste.

Se o teste de segurança for planejado, o teste contra injeção de SQL deve ser planejado como uma das primeiras partes do teste.

Você já encontrou alguma injeção SQL típica? Sinta-se à vontade para compartilhar suas experiências na seção de comentários abaixo.

Leitura recomendada

^