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