Qualidade de Software
5 Vulnerabilidades Recorrentes em Aplicações Delphi. E por que elas podem ficar fora do radar do AppSec?
As vulnerabilidades em aplicações Delphi raramente aparecem no radar de segurança, mas isso não significa que elas não existam. Sistemas em Delphi podem ser encontrados em operações críticas de bancos, seguradoras, empresas de saúde e indústrias. Muitos deles estão em produção há mais de uma década. É código estável, testado pelo tempo e difícil de substituir.
Mas “estável” não é sinônimo de “seguro”.
O problema é que a maior parte do mercado de AppSec (ferramentas de SAST, times de segurança, conteúdo técnico) simplesmente não fala sobre Delphi. Além disso, as plataformas mais conhecidas — Fortify, Checkmarx, HCL AppScan, Synopsys Coverity — não oferecem suporte à linguagem. Resultado: sistemas Delphi acabam ficando fora do radar de segurança, não porque sejam menos vulneráveis, mas porque ninguém está analisando.
Neste artigo, reunimos as vulnerabilidades mais comuns encontradas em aplicações Delphi legadas. São os pontos que qualquer time de tecnologia ou segurança deveria revisar antes de uma auditoria, de uma certificação de compliance ou, idealmente, antes de um incidente.
Por que essas vulnerabilidades passam despercebidas
Antes de entrar na lista, vale entender por que esses riscos raramente aparecem no radar dos times de segurança:
- Lacuna de suporte: as ferramentas de SAST mais conhecidas do mercado não cobrem Delphi, então nenhuma varredura automática é feita nesses sistemas.
- Ausência de automação: sem uma ferramenta rodando de forma contínua, nada é revisado de forma sistemática. Por isso, tudo depende de esforço manual.
- Código legado: sistemas antigos, muitas vezes sem documentação atualizada, tornam a revisão manual lenta e sujeita a falhas.
- Indisponibilidade do código-fonte: em muitos casos, o fonte original se perdeu ou o fornecedor não existe mais, restando apenas o binário para análise.
- Testes pontuais: quando existe alguma verificação, ela costuma acontecer apenas em um pentest ou auditoria de compliance, não de forma contínua ao longo do ciclo de desenvolvimento.
É essa combinação de fatores, e não a ausência real de risco, que explica por que sistemas Delphi seguem operando sem cobertura de segurança adequada.
1. SQL Injection via concatenação direta de queries
É, de longe, a vulnerabilidades em aplicações Delphi mais comum em sistemas mais antigos. Ou seja, componentes de acesso a dados como BDE, ADO ou dbExpress frequentemente foram implementados com queries montadas por concatenação de strings, sem uso de parâmetros (Params) ou prepared statements.
Isso abre espaço para injeção de SQL diretamente por campos de formulário, especialmente em sistemas onde a validação de entrada foi implementada de forma inconsistente entre telas.
Como identificar: buscar no código por “SQL.Text :=” ou “SQL.Add” concatenando variáveis diretamente, sem uso de ParamByName.
2. Credenciais e segredos armazenados sem proteção
Não é raro encontrar strings de conexão, senhas de banco de dados ou chaves de API gravadas diretamente no código-fonte, em arquivos .ini/.cfg em texto claro, ou até em propriedades salvas no próprio .dfm.
Esse padrão, comum em aplicações desenvolvidas antes da adoção de práticas modernas de gestão de segredos. Por isso, se torna um risco crítico quando o executável ou o código-fonte podem ser acessados — inclusive por engenharia reversa do binário.
Como identificar: varredura por padrões de string suspeitos (senhas, connection strings, tokens) em arquivos-fonte, .dfm, .ini e .reg do projeto.
3. Falta de criptografia em comunicação de rede
Aplicações Delphi que usam componentes de socket (como os da biblioteca Indy) para comunicação entre cliente e servidor às vezes trafegam dados sensíveis sem TLS, ou com versões de TLS desatualizadas mantidas por compatibilidade com clientes antigos.
Isso é particularmente crítico em sistemas financeiros e de saúde, onde, muitas vezes sob a premissa (equivocada) de que “é rede interna, não precisa criptografar”, dados de clientes trafegam entre estações de trabalho e servidores internos.
Como identificar: revisar configuração de componentes TIdTCPClient/TIdTCPServer e verificar se há uso de TIdSSLIOHandlerSocketOpenSSL (ou equivalente) com versões de protocolo atualizadas.
4. Regras de negócio e validação de segurança no lado do cliente
Em muitas aplicações desktop Delphi, regras de autorização (quem pode ver o quê, quem pode aprovar o quê) foram implementadas na camada de apresentação, no próprio executável do cliente, em vez de serem validadas no servidor ou banco de dados.
Isso significa que, em teoria, alterar o comportamento de uma tela ou interceptar uma chamada pode ser suficiente para burlar uma regra de negócio que deveria ser uma barreira de segurança.
Como identificar: mapear onde estão as validações de permissão/autorização do sistema — se estiverem concentradas no cliente, é um sinal de alerta.
5. Componentes e bibliotecas de terceiros desatualizados
Muitos sistemas Delphi legados dependem de componentes de terceiros (DLLs, pacotes VCL, bibliotecas de integração) que não recebem atualização há anos. Em alguns casos, isso ocorre porque o fornecedor não existe mais.
Isso cria um risco de cadeia de suprimentos (supply chain): vulnerabilidades em aplicações Delphi conhecidas em versões antigas dessas dependências continuam expostas, mesmo que o código proprietário da empresa esteja bem escrito.
Como identificar: um inventário de componentes (SBOM) é o primeiro passo — sem ele, é praticamente impossível saber quais dependências estão desatualizadas ou comprometidas.
6. Ausência de testes de segurança automatizados no ciclo de desenvolvimento
Esse não é bem uma “vulnerabilidade” no código, mas é a causa raiz de quase todas as anteriores: a maioria dos times que mantêm sistemas Delphi não tem nenhuma ferramenta de SAST rodando de forma contínua, simplesmente porque as ferramentas mais conhecidas do mercado não suportam a linguagem.
Sem análise estática recorrente, cada um dos pontos acima só é descoberto manualmente. Geralmente, isso acontece tarde demais — em um pentest pontual, uma auditoria de compliance ou, no pior cenário, depois de um incidente.
O que fazer com essa lista
Nenhum desses pontos é motivo para reescrever o sistema do zero. Aliás, normalmente essa nem é uma opção real para quem depende de uma aplicação Delphi crítica em produção. O caminho mais realista é mapear onde estão essas vulnerabilidades por meio de análise estática de código (SAST) compatível com Delphi, priorizar as correções pelo risco real e, quando não houver mais acesso ao código-fonte, recorrer a análise binária.
É exatamente essa lacuna que soluções tradicionais de AppSec deixam em aberto. É por isso que a Better Now trouxe para o Brasil o DerScanner, uma das poucas ferramentas de SAST do mercado com suporte nativo a Delphi (entre 43 linguagens suportadas), incluindo análise binária para os casos em que o código-fonte não está mais disponível.
Se sua empresa mantém sistemas críticos em Delphi e nunca passou por uma análise de segurança estruturada, vale conhecer a solução → Better Now & DerScanner
Descubra agora em qual nível de maturidade sua empresa está
*Seus dados são tratados com segurança e em conformidade com a LGPD.
Para mais informações, consulte a nossa Política de Privacidade.