Usando a injeção de SQL, os invasores podem executar comandos não autorizados em um banco de dados SQL da vítima.
Após ler este artigo, você será capaz de:
Conteúdo relacionado
Segurança de aplicativos web?
Cross-Site Request Forgery
O que é uma violação de dados?
Ataque de estouro de buffer
O que é OWASP Top 10?
Assine o theNET, uma recapitulação mensal feita pela Cloudflare dos insights mais populares da internet.
Copiar o link do artigo
A injeção de Structured Query Language (SQL*) é uma técnica de injeção de código usada para modificar ou recuperar dados de bancos de dados SQL. Ao inserir instruções SQL especializadas em um campo de entrada, um invasor pode executar comandos que permitem a recuperação de dados do banco de dados, a destruição de dados sensíveis ou outros comportamentos manipuladores.
Com a execução adequada do comando SQL, o usuário não autorizado é capaz de falsificar a identidade de um usuário mais privilegiado, possibilitando que ele mesmo ou outros administradores de banco de dados, adulterem dados existentes, modifiquem transações e saldos e recuperem e/ou destruam todos os dados do servidor.
Na computação moderna, a injeção de SQL normalmente ocorre pela internet enviando consultas SQL maliciosas para um endpoint de API fornecido por um site ou serviço (mais informações sobre isso adiante). Em sua forma mais severa, a injeção de SQL pode permitir que um invasor obtenha acesso root a uma máquina, dando a ele controle total.
*SQL é uma linguagem de programação usada para manter a maioria dos bancos de dados.
Imagine um tribunal em que um homem chamado Bob está sendo julgado e está prestes a comparecer perante um juiz. Ao preencher a papelada antes do julgamento, Bob escreve seu nome como “Bob está livre”. Quando o juiz chega ao seu caso e lê em voz alta “Agora, chamo Bob está livre”, o oficial de justiça deixa Bob ir porque o juiz disse isso.
Embora existam variações ligeiramente diferentes de SQLi, a vulnerabilidade principal é essencialmente a mesma: um campo de consulta SQL que deveria ser reservado para um tipo específico de dados, como um número, recebe informações inesperadas, como um comando. O comando, quando executado, escapa além dos limites pretendidos, permitindo um comportamento potencialmente nefasto. Um campo de consulta geralmente é preenchido a partir de dados inseridos em um formulário em uma página web.
Vejamos uma comparação simples entre instruções SQL normais e maliciosas:
Nesta consulta SQL normal, a string studentId é passada para uma instrução SQL. O objetivo é procurar na lista de alunos um aluno que corresponda ao studentId inserido. Uma vez encontrado, o registro desse aluno será devolvido. Simplificando, o comando diz “vá encontrar este usuário e me forneça seus dados”.
O código pode ser algo assim:
studentId = getRequestString("studentId");
lookupStudent = "SELECT * FROM students WHERE studentId = " + studentId
Se um estudante digitar uma ID de estudante 117 em um formulário de página web com a instrução "Digite seu número de ID de estudante".
a consulta SQL resultante será semelhante a:
SELECT * FROM students WHERE studentId = 117;
Este comando retornará o registro para o aluno específico com um studentId, que é o que o desenvolvedor que escreveu a API espera que aconteça.
Neste exemplo, um invasor insere um comando SQL ou lógica condicional no campo de entrada, ele insere um número de identificação do aluno de:
Onde normalmente a consulta pesquisaria a tabela do banco de dados pela ID correspondente, agora ela procura uma ID ou testes para ver se 1 é igual a 1. Como você poderia esperar, a afirmação é sempre verdadeira para todos os alunos na coluna e, como como resultado, o banco de dados retornará todos os dados da tabela de alunos de volta ao invasor que fizer a consulta.
SELECT * FROM students WHERE studentId = 117 OR 1=1;
A SQLi funciona visando uma interface de programação de aplicativos ou API vulnerável. Uma API neste caso é a interface de software por meio da qual um servidor recebe e responde às solicitações.
Existem ferramentas comumente usadas que permitem que um agente malicioso pesquise automaticamente em um site procurando formulários e tente inserir várias consultas de SQL que podem gerar uma resposta que os desenvolvedores de software do site não pretendiam para explorar o banco de dados.
As injeções de SQL são fáceis de implementar e, curiosamente, também bastante fáceis de evitar, dadas as práticas de desenvolvimento adequadas. A realidade é mais obscura, pois prazos apertados, desenvolvedores inexperientes e código legado geralmente resultam em práticas de segurança e qualidade de código variáveis. Um único campo vulnerável em qualquer formulário ou endpoint de API, em um site que tenha acesso a um banco de dados, pode ser suficiente para expor uma vulnerabilidade.
Existem vários métodos para reduzir o risco de violação de dados devido à injeção de SQL. Várias estratégias devem ser utilizadas, conforme as práticas recomendadas. Vamos explorar algumas das implementações mais comuns:
Para contornar as medidas de segurança, invasores inteligentes às vezes implementam ataques multivetoriais contra um site alvo. Embora um único ataque possa ser mitigado, ele também pode se tornar o foco de atenção dos administradores de banco de dados e das equipes de segurança da informação. Ataques DDoS, sequestro de DNS e outros métodos de interrupção às vezes são usados como uma distração para implementar ataques abrangentes de injeção de SQL. Como resultado, uma estratégia abrangente de mitigação de ameaças fornece a mais ampla gama de proteção. O firewall de aplicativos web,a mitigação de DDoS e a segurança de DNS da Cloudflare abrangem os principais elementos de uma estratégia de segurança holística.