Injeção de SQL e injeção de comandos

SQL injection (SQLi) ocorre quando um invasor insere ou “injeta” código SQL malicioso em um campo de entrada que depois é passado para uma consulta ao banco de dados. Como a aplicação concatena a entrada do usuário diretamente em uma instrução SQL, o banco de dados não consegue distinguir entre dados legítimos e Commands fornecidos pelo invasor. A SQLi aparece consistentemente entre as vulnerabilidades Web mais perigosas do OWASP Top 10.

Uma consulta de login vulnerável poderia ser: SELECT * FROM users WHERE username='INPUT' AND password='INPUT'. Um invasor que forneça ' OR '1'='1 como nome de usuário transforma a consulta de modo que a cláusula WHERE seja sempre verdadeira, contornando completamente a autenticação. Essa é a clássica injeção baseada em tautologia.

Os ataques de SQL injection assumem várias formas: In-band SQLi retorna os resultados diretamente na resposta HTTP (baseada em erros ou em união). A Blind SQLi infere dados por meio de respostas booleanas verdadeiras ou falsas ou de atrasos de tempo deliberados (SLEEP(5)). A Out-of-band SQLi usa canais secundários, como consultas DNS, para exfiltrar dados quando as respostas não estão visíveis.

A principal defesa contra SQL injection são as consultas parametrizadas (também chamadas de instruções preparadas). Em uma consulta parametrizada, a estrutura SQL é compilada primeiro e a entrada do usuário é passada como um parâmetro separado — ela nunca pode alterar a estrutura da consulta. Essa abordagem é independente da linguagem e muito mais confiável do que apenas higienizar a entrada.

Embora as consultas parametrizadas sejam a principal defesa, a validação de entrada fornece uma importante camada secundária. A validação por lista de permissões aceita apenas os caracteres esperados (por exemplo, somente caracteres alfanuméricos em um campo de nome de usuário) e rejeita todo o restante. A validação por lista de bloqueio impede caracteres reconhecidamente maliciosos, mas os invasores frequentemente codificam ou ofuscam as cargas maliciosas para contornar essas listas — o que torna as listas de permissões muito mais fortes.

Injeção de Commands (injeção de Commands do OS) ocorre quando uma aplicação passa uma entrada de usuário não higienizada para um shell do sistema. Diferentemente de SQL injection, que tem como alvo bancos de dados, a injeção de Commands tem como alvo o próprio sistema operacional — permitindo que invasores executem Commands arbitrários com os Privileges do processo do servidor Web. Ela é classificada como de gravidade crítica e frequentemente leva ao comprometimento completo do sistema.

Uma aplicação Web que faz ping em um endereço IP fornecido pelo usuário poderia usar: ping -c 1 INPUT. Se um invasor fornecer 8.8.8.8; cat /etc/passwd, o shell interpreta ; como um separador de Commands e executa ambos os comandos. Os operadores de injeção comuns incluem ;, &&, ||, | e a substituição de Commands por crases.

A defesa mais segura contra a injeção de Commands é evitar completamente chamar Commands do OS a partir de entradas do usuário — use funções de biblioteca que alcancem o mesmo objetivo. Quando chamadas ao shell forem inevitáveis, passe os argumentos como uma lista (nunca como uma string concatenada), desabilite a interpretação do shell, valide a entrada contra uma lista de permissões rigorosa e execute os processos com a conta de usuário de menores Privileges possível.

O Top 10 da OWASP lista a Injection (que engloba injeção de SQL, NoSQL, OS e LDAP) como um dos riscos mais críticos à segurança de aplicações. A OWASP recomenda uma abordagem de defesa em profundidade: use APIs seguras que evitem o interpretador, faça a validação positiva (lista de permissões) das entradas no lado do servidor, escape os caracteres especiais usando a sintaxe específica desse interpretador e use controles de SQL, como LIMIT, para evitar a divulgação em massa de dados.

Um Web Application Firewall (WAF) pode detectar e bloquear cargas comuns de injeção ao inspecionar solicitações HTTP em busca de padrões de assinaturas. No entanto, os WAFs podem ser contornados por meio de técnicas de codificação e não substituem práticas seguras de programação. O registro adequado de eventos da aplicação — registrando parâmetros de consulta, códigos de resposta e mensagens de erro — permite que as equipes de Security identifiquem tentativas de injeção durante a análise de incidentes.

Os ataques de injeção causaram algumas das maiores violações de dados da história. A violação da Equifax em 2017 expôs 147 milhões de registros por meio de uma falha em uma aplicação Web. Uma injeção de SQL contra a rede da Sony PlayStation comprometeu 77 milhões de contas em 2011. Esses incidentes mostram que as falhas de injeção têm um impacto extremo nos negócios: roubo de dados, multas regulatórias, danos à reputação e responsabilidade jurídica são consequências de um ataque de injeção bem-sucedido.

Teste sua compreensão dos conceitos de CompTIA Security+ (SY0-701) abordados nesta lição.

Nesta lição, você aprendeu: a injeção de SQL explora entradas não sanitizadas concatenadas em consultas ao banco de dados, a injeção de comandos passa entradas Malicious ao shell do OS por meio de operadores como ; e | e consultas parametrizadas e evitar shell=True são as principais defesas. A seguir, vamos explorar ataques de Cross-Site Scripting (XSS) e CSRF.