SQL Injection - Um problema antigo, ainda presente.
Resumo:
Este artigo tem como objetivo demonstrar que a vulnerabilidade causada por
implementações incorretas no código das aplicações, ainda se encontram em uso,
apesar de já existirem boas práticas que se aplicadas, impedem ou mitigam que a
ameaça de SQL Injection aconteça.
Introdução
Antes de mais nada, qual seria a definição de SQL Injection ? Conforme descrito na
Wikipedia, essa seria a definição clássica:
Injeção de SQL (do inglês SQL Injection) é um tipo de ameaça de
segurança que se aproveita de falhas em sistemas que interagem
com bases de dados através de comandos SQL, onde o atacante
consegue inserir uma instrução SQL personalizada e indevida
dentro de uma consulta (SQL query) através da entradas de dados
de uma aplicação, como formulários ou URL de uma aplicação.
Segundo este link ( https://www.esecurityplanet.com/networks/how-was-sql-injection-
discovered/ ), o primeiro caso de SQL Injection foi investigado em 1998. Então, na
presente data deste artigo, estamos falando de uma ameaça conhecida há 23 anos. E
na seção seguinte, mostraremos que ela ainda está presente
Há ameaça, atualmente
Recentemente, um colaborador da nossa Equipe de DBAs me enviou o link abaixo com
o ranking de diversas vulnerabilidades em aplicações:
A Common Weakness Enumeration (CWE™), é uma comunidade voltada a identificar
vulnerabilidades de software e hardware, ajudando em sua classificação e
categorização. No trabalho acima, a CWE usou as seguintes as base de dados
National Vulnerability Database (NVD) do National Institute of Standards and
Technology (NIST):
- Common Vulnerabilities and Exposures (CVE®).
- Common Vulnerability Scoring System (CVSS)
A ameaça SQL Injection, classificada com o código CWE-89 aparece na posição
número 6. Um problema com 23 anos de idade, ainda se encontra no top 10, junto com
“vulnerabilidades” mais recentes e modernas.
O assunto ainda é explorado pela Academia, como pode ser visto em artigos recentes:
R. Zuech, J. Hancock and T. M. Khoshgoftaar, “Detecting SQL
Injection Web Attacks Using Ensemble Learners and Data
Sampling,” 2021 IEEE International Conference on Cyber Security
and Resilience (CSR), 2021, pp. 27-34, doi:
10.1109/CSR51186.2021.9527990.
Z. Marashdeh, K. Suwais and M. Alia, “A Survey on SQL Injection
Attack: Detection and Challenges,” 2021 International Conference
on Information Technology (ICIT), 2021, pp. 957-962, doi:
10.1109/ICIT52682.2021.9491117.
Max Maaß, Henning Pridöhl, Dominik Herrmann, and Matthias
Hollick. 2021. Best Practices for Notification Studiesfor Security and
Privacy Issues on the Internet. In The 16th International Conference
on Availability, Reliability and Security (ARES 2021). Association for
Computing Machinery, New York, NY, USA, Article 90, 1–10.
DOI: https://doi.org/10.1145/3465481.3470081
Vivien Weinfurter, Amrei Sophia Kirmaier, Philipp Brune, and
Bianca Bergande. 2021. Raising Awareness for IT Security in
Higher Education – A Teaching Experiment on SQL Injection for
Non-Computer Science Majors. Proceedings of the 26th ACM
Conference on Innovation and Technology in Computer Science
Education V. 2. Association for Computing Machinery, New York,
NY, USA, 619–620. DOI: https://doi.org/10.1145/3456565.3460035
Vivien Weinfurter, Amrei Sophia Kirmaier, Philipp Brune, and
Bianca Bergande. 2021. Raising Awareness for IT Security in
Higher Education – A Teaching Experiment on SQL Injection for
Non-Computer Science Majors. Proceedings of the 26th ACM
Conference on Innovation and Technology in Computer Science
Education V. 2. Association for Computing Machinery, New York,
NY, USA, 619–620. DOI: https://doi.org/10.1145/3456565.3460035
Medidas Preventivas
O SQLi inicialmente não era uma vulnerabilidade. Do ponto de vista de programação,
inicialmente é mais simples montar uma instrução SQL concatenando “strings” e
variáveis do que usar “prepared statments”
Eu me recordo que, certa época, a linguagem PHP tinha a fama de facilitar o SQL
Injection. Talvez, devido a sua popularidade. Mas, esta facilidade é aplicável para
qualquer linguagem de programação.
Quando, há alguns anos, recebemos a missão de desenvolver um sistema em PHP
com Oracle, eu tive a preocupação de explorar este assunto. Felizmente, a própria
Oracle disponibilizou um ebook, que demonstrava a forma correta de se programar
para mitigar o SQLi.
O livro está disponível nesse link:
O exemplo acima, extraído do livro, mostra um dos efeitos colaterais se usar o código
mais seguro. O desenvolvedor escreve mais. Escrever um SQL dinâmico com diversas
SQL Injection – Um problema antigo, ainda presente.5opções de filtro tornam o código mais denso. Mas em contrapartida mais seguro.
Algumas linguagens mais recentes, como o Javascript suportado por Node.js também
oferecem alternativas para se evitar o SQLi. A Oracle, por exemplo, desenvolveu um
add-on para Node.js chamado node-oracledb que permite a execução de prepared
statments com bind variables.
Obviamente, os exemplos acima demonstram o uso de um código de mais baixo nível,
com declaração explicita do SQL e acesso direto ao banco de dados.
O plano de ação para mitigar o SQLi pode ser proposto para duas áreas, conforme é
descrito a seguir.
Ações por parte da Área de Desenvolvimento
- Usar “Prepared Statements” ao invés de SQL com concatenação de variáveis;
- Tratar os campos de entrada dos formulários, verificando os tipos de dados, limitando o tamanho dos dados de entrada, analisando e substituindo caracteres especiais etc;
- Usar uma framework ORM (Object Relational Mappers) como Hibernate, Entity Framework, Sequelize, etc… Praticamente, todas as linguagens de programação mais populares tem uma framework ORM disponível;
Obs: A facilidade do ORM pode ter um efeito colateral, que
pode causar certa preocupação ao DBA. Este efeito é o
surgimento de SQLs gigantes que oneram o banco de dados.
Mas, se o código estiver disponível, existem alternativas para a
otimização.
Ações por parte da Área de Infraestrutura
O plano de ação para mitigar o SQLi pode ser proposto para duas áreas, conforme é
descrito a seguir.
- Monitorar o código SQL executado no banco de dados e notificar a Área de Desenvolvimento sobre SQLs suspeitos ou onerosos (tarefa executada pela Polo IT através do DBA CENTER!);
- Usar um WAF (Web Application Firewall). Ele não detecta necessariamente um SQLi, mas ao analisar as URLs que são submetidas ao sistema, ele pode identificar URLs maliciosas que potencialmente podem executar um SQLi.
- Usar Database Firewall. Este produto, entre outras funcionalidades, detecta potenciais ameaças com SQLi. Existem diversos fornecedores, que atendem aos bancos de dados mais populares. A Polo IT recomenda o uso do Oracle Database Firewall, que além de trabalhar com Oracle, suporta SQL Server, PostgreSQL, MySQL, DB2 entre outros produtos ( https://www.oracle.com/pt/database/technologies/security/audit-vault-firewall.html).
- Limitar as permissões das tabelas em um sistema, especialmente em tabelas críticas do dicionário de dados, bem como tabelas críticas do negócio . Esta atividade é um trabalho em conjunto entre a Área de Desenvolvimento e o DBA. Muitos sistemas possuem o seu usuário de aplicação com privilégio de DBA, SYSADMIN ou similar. Caso o hacker tenha sucesso no SQLi, a possibilidade dele extrair informações que possam ampliar seu raio de ataque seriam minimizadas ao se adotar esta abordagem.
- Criptografar as colunas sensíveis. Muitas bases de dados, com informações de login e senha foram capturadas através de SQLi, e a coluna da senha estava com o texto em sua forma literal. Obviamente, um hacker mais técnico ao perceber que o dado está criptografado, ele pode partir em busca da chave para decifrar, mas a depender da forma como essa técnica foi implementada, esta tarefa será bem mais difícil de ser implementada.
Conclusão
Tratar as situações possíveis de SQLi, é apenas uma das diversas atividades que a
Área de TI precisa se preocupar em relação às questões de segurança. E no momento
atual, com a Lei Geral de Proteção de Dados, este assunto deve ser tratado com
extremo cuidado e atenção. Este artigo demonstra que o problema é atual, e que o
esforço para mitigá-lo não está restrito apenas a Área de Desenvolvimento. A Polo IT,
como empresa especializada em Bancos de Dados, está disponível para prestar
consultoria especializada e apoiar as organizações a tornarem-se mais seguras.
Constantino Jacob Miguel
Sócio e gestor de tecnologia na Polo IT
DBA e Professor em Banco de Dados
Oracle Autonoumous Database Cloud Specialist
Oracle Cloud Infrastructure Architect