0% acharam este documento útil (0 voto)
3 visualizações4 páginas

Entendendo SQL Injection e Prevenção

SQL Injection é um ataque em que dados não higienizados são inseridos em consultas SQL, permitindo que invasores manipulem informações. Existem três tipos principais de SQL Injection: In-band, Inferential e Out-of-band, cada um com suas características específicas. Para prevenir esses ataques, é essencial usar frameworks adequados, manter sistemas atualizados e validar todos os dados recebidos dos usuários.

Enviado por

augusto cesar
Direitos autorais
© All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato DOCX, PDF, TXT ou leia on-line no Scribd
0% acharam este documento útil (0 voto)
3 visualizações4 páginas

Entendendo SQL Injection e Prevenção

SQL Injection é um ataque em que dados não higienizados são inseridos em consultas SQL, permitindo que invasores manipulem informações. Existem três tipos principais de SQL Injection: In-band, Inferential e Out-of-band, cada um com suas características específicas. Para prevenir esses ataques, é essencial usar frameworks adequados, manter sistemas atualizados e validar todos os dados recebidos dos usuários.

Enviado por

augusto cesar
Direitos autorais
© All Rights Reserved
Levamos muito a sério os direitos de conteúdo. Se você suspeita que este conteúdo é seu, reivindique-o aqui.
Formatos disponíveis
Baixe no formato DOCX, PDF, TXT ou leia on-line no Scribd

SQL Injection

SQL Injections são métodos de ataque críticos em que um aplicativo da Web inclui
diretamente dados não higienizados fornecidos pelo usuário em consultas SQL.

Tipos de SQL Injection

In-band SQLi (Classical SQLi): Se uma consulta SQL é enviada e respondida no


mesmo canal, chamamos esses SQLi In-band. É mais fácil para os invasores
explorá-los em comparação com outras categorias SQLi.

Inferential SQLi (Blind SQLi): consultas SQL que recebem uma resposta que não
pode ser vista são chamadas de SQLi inferencial. Eles são chamados de Blind SQLi
porque a resposta não pode ser vista.

Out-of-band SQLi: Se a resposta a uma consulta SQL for comunicada por um canal
diferente, esse tipo de SQLi é chamado de SQLi fora de banda. Por exemplo, se o
invasor estiver recebendo respostas às suas consultas SQL pelo DNS, isso é
chamado de SQLi fora de banda.

Como funciona ?

Hoje, os aplicativos da Web padrão geralmente recebem dados de um usuário e


usam esses dados para exibir conteúdo específico. A página de login é onde a
maioria dos ataques de SQL Injection acontecem. Vamos examinar como as
injeções de SQL funcionam por meio de um exemplo.
Geralmente, espera-se que um usuário insira seu nome de usuário e senha na
página de login. Por outro lado, o aplicativo da web usará essas informações de
nome de usuário e senha para criar uma consulta SQL como a abaixo:
SELECT * FROM users WHERE nome de usuário = ' USERNAME ' E senha =
' USER_PASSWORD '

O significado desta consulta SQL é “traga-me todas as informações sobre o usuário


da tabela de usuários cujo nome é USERNAME e cuja senha
é USER_PASSWORD ”. Se o aplicativo da web encontrar um usuário
correspondente, ele autenticará o usuário, se não puder encontrar um usuário
após a consulta ser realizada, o login não será bem-sucedido.
Digamos que seu nome de usuário seja “ john ” e sua senha seja
“ supersecretpassword ”. Quando você insere essas informações e clica no
botão de login, a consulta SQL que você vê abaixo será consultada e você poderá
entrar porque houve uma correspondência encontrada após a consulta SQL.
SELECT * FROM users WHERE username = ' john ' AND password =
' supersecretpassword '

Então, e se não usarmos esse sistema da maneira como ele foi projetado e
colocarmos um apóstrofo (') na área de nome de usuário? A consulta SQL será
como abaixo e o erro será excluído do banco de dados porque a consulta estava
com defeito.
SELECT * FROM users WHERE username = ' john ' AND password =
' supersecretpassword '

Um invasor ficaria feliz em receber uma mensagem de erro. O atacante pode


manipular as informações na mensagem de erro para sua própria vantagem e
também mostrar que ele está no caminho certo. E se o invasor inserir uma carga
útil como a abaixo na área do nome de usuário?

' OU 1=1 – -

Quando o invasor enviar a carga útil, o aplicativo da Web executará a seguinte


consulta SQL:
SELECT * FROM users WHERE username = '' OR 1=1 – - AND password =
' supersecretpassword '

No SQL, quaisquer caracteres que vierem depois de “-- -” serão percebidos como
uma linha de comentário. Então, se olharmos para a consulta acima, as consultas
que vêm depois de “-- -” não significam nada. Então, vamos remover essa parte
para simplificar as coisas antes de continuarmos a examinar a consulta SQL.

SELECT * FROM users WHERE nome de usuário = '' OR 1=1

Então agora a consulta acima se parece com isso: “ se o nome de usuário


estiver vazio ou 1=1 ”. Não é realmente importante se a área do nome de
usuário é deixada vazia ou não, porque 1 é sempre igual a 1. É por isso que esta
consulta sempre será verdadeira e provavelmente chamará a primeira listagem no
banco de dados. O invasor poderá entrar com êxito no aplicativo da Web porque
há uma correspondência.

Este exemplo é um ataque típico de injeção de SQL. É claro que os ataques de


injeção de SQL não estão limitados a este exemplo, o invasor pode usar SQL para
executar comandos no sistema com a ajuda de comandos SQL
como xp_cmdshell.

Para entender por que os ataques de injeção de SQL são tão importantes, vamos
dar uma olhada no que um ataque de injeção de SQL pode causar.
Bypass de autenticação
Execução do comando
Exfiltrando dados confidenciais
Criando/excluindo/atualizando entradas de banco de dados

Como Evitar
 Use um framework: claro que apenas usar um framework não será
suficiente para evitar um ataque de SQL Injection. É de extrema importância
usar o framework de acordo com a documentação.
Mantenha sua estrutura atualizada: mantenha seu aplicativo da Web
seguro seguindo as atualizações de segurança relacionadas à estrutura que
você usa.
Sempre limpe os dados recebidos de um usuário: nunca confie nos
dados recebidos de um usuário. Além disso, não apenas limpe os dados do
formulário, mas também faça o mesmo com outros dados (como cabeçalhos,
URLs etc.)
Evite usar consultas SQL brutas: Você pode ter o hábito de escrever
consultas SQL brutas, mas deve optar por fazer uso dos benefícios que um
framework oferece e também deve fazer uso da segurança que ele oferece.

Detectando ataques de SQL injection


Discutimos o que os invasores podem fazer com um ataque de injeção de SQL na
seção anterior. Cada um dos resultados de uma injeção de SQL mencionado acima
pode causar grandes perdas para uma instituição, portanto, como analistas de
SOC, devemos ser capazes de detectar esses ataques e tomar precauções contra
eles.
Então, como podemos detectar ataques de injeção de SQL?
Há mais de uma resposta para esta pergunta. Estes são:

Ao examinar uma solicitação da Web, verifique todas as áreas que


vêm do usuário: Como os ataques de SQL Injection não se limitam às áreas
do formulário, você também deve verificar os cabeçalhos de solicitação
HTTP, como User-Agent.
Procure por palavras-chave SQL: procure por palavras como INSERT,
SELECT, WHERE nos dados recebidos dos usuários.
Verifique se há caracteres especiais: procure apóstrofos ('), traços (-)
ou parênteses que são usados em SQL ou caracteres especiais que são
frequentemente usados em ataques SQL nos dados recebidos do usuário.
Familiarize-se com cargas úteis de SQL Injection usadas com
frequência: embora as cargas úteis SQL mudem de acordo com o aplicativo
da Web, os invasores ainda usam algumas cargas úteis comuns para
verificar vulnerabilidades de SQL Injection. Se você estiver familiarizado com
essas cargas úteis, poderá detectar facilmente cargas úteis de injeção de
SQL..
Detectando ferramentas automatizadas de injeção de SQL
Os invasores usam muitos dispositivos automatizados para detectar
vulnerabilidades de injeção de SQL. Um dos mais conhecidos é o Sqlmap. Vamos
olhar para o quadro mais amplo em vez de focar em uma ferramenta específica.
Você pode usar os métodos listados abaixo para detectar dispositivos de injeção
de SQL:

[Link] o User-Agent: Dispositivos de navegador automatizados


geralmente têm seus nomes e versões registrados. Você pode olhar para o
User-Agent para detectar esses dispositivos automatizados.
[Link] a frequência das solicitações: os dispositivos automatizados
foram projetados para enviar uma quantidade estimada de muitas
solicitações por segundo para poder testar as cargas úteis o mais rápido
possível. Um usuário normal pode enviar 1 solicitação por segundo,
portanto, você pode saber se as solicitações são feitas por um dispositivo
automatizado ou não, observando o número de solicitações por segundo.
[Link] o conteúdo da carga útil: os dispositivos automatizados
geralmente gravam seus próprios nomes em suas cargas úteis. Por exemplo,
uma carga útil de SQL Injection enviada por um dispositivo automatizado
pode ter esta aparência: sqlmap' OR 1=1
4.A carga útil é complicada: esse método de detecção nem sempre
funciona, mas com base na minha experiência, posso dizer que os
dispositivos automatizados enviam cargas úteis mais complicadas.

Simbolo %
Quando solicitamos uma página que contém caracteres especiais, essas
solicitações não são transferidas diretamente para o servidor web. Em vez disso,
nossos navegadores executam uma codificação de URL (Percent Encoding) dos
caracteres especiais e substitui cada caractere especial por uma cadeia de
caracteres que começa com % e contém 2 caracteres hexadecimais. Portanto, as
páginas que contêm o símbolo % acima são páginas que contêm caracteres
especiais.

Você também pode gostar