Evaluating Cryptographic API Misuse Detectors for Go
Este artigo apresenta o primeiro estudo abrangente sobre o mau uso de APIs criptográficas em Go, estabelecendo uma taxonomia de 14 classes de mau uso, avaliando quatro ferramentas de detecção em 328 projetos e identificando 7.473 vulnerabilidades para destacar lacunas significativas na cobertura atual de detecção.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você está construindo uma fortaleza. Você tem as melhores e mais seguras fechaduras do mundo (APIs criptográficas) para proteger seu tesouro. Mas, se você instalar a fechadura de cabeça para baixo, usar uma chave frágil ou esquecer de trancar a porta, sua fortaleza fica tão vulnerável quanto se não tivesse fechadura alguma. É isso que acontece quando desenvolvedores "usam mal" ferramentas criptográficas: eles acreditam estar seguros porque utilizaram a tecnologia correta, mas cometeram um erro na forma como a aplicaram.
Este artigo é como uma inspeção de controle de qualidade para um tipo específico de material de construção: a linguagem de programação Go. Go é a linguagem usada para construir algumas das infraestruturas mais críticas da internet (como os sistemas que gerenciam o tráfego da internet ou protegem data centers). Embora especialistas tenham estudado esses "erros de instalação de fechaduras" em outras linguagens (como Java) por anos, ninguém havia realmente inspecionado os canteiros de obras do Go até agora.
Veja o que os pesquisadores fizeram, explicado de forma simples:
1. Os Inspetores (As Ferramentas)
Os pesquisadores reuniram quatro "inspetores de segurança" diferentes (ferramentas de software) para escanear códigos em Go em busca desses erros:
- CodeQL: Um inspetor poderoso, de estilo acadêmico, que analisa como os dados fluem pelo código.
- Gopher: Uma ferramenta especializada construída especificamente para Go, conhecida por ser muito agressiva na detecção de problemas potenciais.
- Gosec: Uma ferramenta popular, desenvolvida pela comunidade, que verifica erros de segurança comuns.
- Snyk Code: Uma ferramenta comercial que utiliza inteligência artificial e análise estática para encontrar bugs.
2. O Projeto (A Taxonomia)
Antes de iniciar a varredura, os pesquisadores criaram uma lista mestra de verificação com 14 maneiras diferentes pelas quais um desenvolvedor pode errar ao usar criptografia. Pense nisso como uma lista de erros comuns, tais como:
- Usar uma fechadura muito antiga e fraca (Algoritmos Inseguros).
- Usar uma chave muito curta ou fácil de adivinhar (Comprimento de Chave Curto).
- Esquecer de verificar se a pessoa na porta é realmente quem diz ser (Sem Validação de Chave de Host).
- Usar um padrão previsível para o mecanismo da fechadura (IVs Previsíveis).
3. A Inspeção (O Experimento)
Eles pegaram 328 projetos reais e populares em Go (como o software que executa o Kubernetes ou o Terraform) e rodaram todos os quatro inspetores neles.
- O Resultado: Os inspetores encontraram um total de 7.473 erros.
- A Surpresa: Os inspetores não concordaram entre si em absoluto.
- Gosec foi o mais ativo, encontrando o maior número de erros, mas também sinalizou muitas coisas que não eram realmente perigosas (como encontrar uma "fechadura fraca" em um arquivo de código de exemplo que ninguém usaria na vida real).
- Gopher encontrou um conjunto único de erros que os outros perderam, mas às vezes travou ou falhou ao executar em certos projetos.
- Snyk Code foi muito rápido e preciso, encontrando menos erros, mas tendo muita certeza sobre aqueles que encontrou.
- CodeQL foi o mais lento (leva muito tempo para configurar seu "banco de dados" do código), mas encontrou alguns erros muito específicos e complexos que os outros perderam.
4. O Veredito
A principal conclusão é que nenhum inspetor único é perfeito.
- Se você usar apenas uma ferramenta, pode perder um enorme buraco em sua parede porque aquela ferramenta não sabia como procurá-lo.
- Se você usar todas elas, obterá muitos "falsos alarmes" (avisos sobre coisas que não estão realmente quebradas), o que pode ser avassalador.
Os pesquisadores descobriram que as ferramentas frequentemente discordavam sobre se um trecho específico de código era realmente um erro. Por exemplo, uma ferramenta pode dizer: "Esta chave é muito curta!", enquanto outra diz: "Isso está tudo bem."
A Conclusão
Este estudo é a primeira vez que alguém verificou sistematicamente o quão bem podemos encontrar esses erros de segurança específicos em códigos Go. Eles descobriram que, embora tenhamos ferramentas para ajudar, elas atualmente são como um grupo de inspetores que falam idiomas diferentes e têm definições distintas do que é uma "fechadura quebrada".
Para manter sistemas baseados em Go seguros, engenheiros de segurança não devem confiar em apenas uma ferramenta. Em vez disso, devem usar uma combinação dessas ferramentas (um "conjunto") para capturar a maior rede possível de erros, entendendo que precisarão revisar manualmente os resultados para separar perigos reais de falsos alarmes.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.