Modernizando a manutenção de regras de SAST para detectar vulnerabilidades mais rapidamente

O Snyk Code se diferencia da maioria das ferramentas de análise estática de código por gerar e manter conjuntos de regras para seus usuários, ajudando-os a combater ameaças comuns e recém-descobertas. Um artigo recente do Hub descreveu uma nova vulnerabilidade em JavaScript chamada poluição de protótipo, que permite que invasores modifiquem ou “poluam” o protótipo de um objeto JavaScript e executem várias ações maliciosas.

Nesta publicação, vamos usar o exemplo da poluição de protótipo para mostrar como os recursos de manutenção de regras do Snyk Code ajudam desenvolvedores e profissionais de segurança a proteger suas aplicações. Não vamos explorar a poluição de protótipo em profundidade aqui, mas, se você quiser saber mais, recomendo fazer esta lição do Snyk Learn ou ler o artigo do Hub mencionado acima.

A abordagem tradicional para manter conjuntos de regras

A qualidade de uma ferramenta de teste de segurança de aplicações estáticas (SAST) — e, de forma mais ampla, das ferramentas de análise estática de código — é determinada, em grande parte, pela qualidade do seu conjunto de regras. Em termos simples, a ferramenta transforma o código-fonte em uma estrutura de dados e usa essas regras para procurar padrões maliciosos. Na maioria dos scanners modernos, as regras são escritas em um estilo pouco comum chamado programação lógica.

Escrever e manter conjuntos de regras não é uma tarefa fácil. Isso exige conhecimento aprofundado de programação lógica, além da linguagem e das bibliotecas analisadas. Depois de escrever as regras, depurá-las traz outro desafio. É preciso testá-las em código real antes de usá-las em produção, o que pode levar horas. Por isso, pesquisas¹ mostram que os desenvolvedores raramente alteram a configuração. Embora existam casos em que regras personalizadas façam sentido, na maioria das situações a ferramenta deveria simplesmente funcionar.

Observação: Há pouquíssimos casos em que regras personalizadas fazem sentido (se esse for o seu caso, fale com a gente). Na maioria das situações, a ferramenta deveria “simplesmente funcionar” — sem que você precise mexer em nada!

O Snyk Code moderniza a manutenção de regras

O Snyk Code adota uma abordagem diferente. Consideramos o conjunto de regras parte do produto e não pedimos aos clientes que mantenham essas regras para poder usar a ferramenta. Em um setor que acredita que “regras personalizadas” são um recurso indispensável de uma ferramenta SAST, a Snyk oferece uma solução mais simples. Nossos especialistas em segurança assumem a responsabilidade de criar e manter o conjunto de regras, usando um mecanismo potente e rápido para analisar um grande número de projetos de código aberto, que servem como conjunto de testes e treinamento. Os “humanos no loop” da Snyk monitoram e supervisionam os resultados continuamente, além de garantir o controle de qualidade — para que os clientes não precisem fazer isso.

Um dos engenheiros da Snyk que trabalha na manutenção de regras é Alessio Della Libera, pesquisador de segurança que entrou na Snyk há cerca de um ano. Ao falar sobre a abordagem exclusiva do Snyk Code, ele a descreveu como “[...] uma espécie de ciclo. Começar a mudar algo e verificar as alterações com base nos resultados do conjunto de dados leva alguns minutos. Poder iterar tão rapidamente ajuda muito.”

Em mais detalhes

O conjunto de treinamento de projetos de código aberto é monitorado e atualizado continuamente com base nos resultados das análises e no feedback dos usuários. Durante esse monitoramento, Libera percebeu que uma de nossas regras existentes não estava funcionando conforme os requisitos.

Depois de alterar e testar a regra, dois resultados chamaram a atenção. O projeto de código aberto appwrite.io continha uma cópia da biblioteca litespeed.js. Segundo o site do projeto, “Appwrite é uma solução auto-hospedada que oferece aos desenvolvedores um conjunto de APIs REST fáceis de usar e integrar para gerenciar as principais necessidades de back-end”. O Snyk Code identificou o mesmo problema tanto na biblioteca disponível no marketplace quanto no próprio projeto.

Em uma instância em execução do appwrite.io (por exemplo, ao acessá-la em mywebsite.com), um invasor pode chamar mywebsite.com/auth/signup?__proto__[polluted]=yes. Usando as ferramentas de desenvolvedor do navegador, você pode verificar o estado do JavaScript e verá que agora há um membro chamado polluted com o valor yes. Ao explorar esse problema, Libera descobriu que sites maliciosos poderiam usar a vulnerabilidade para iniciar um ataque de cross-site scripting (XSS).

Avisando os responsáveis pela manutenção

Depois de avisar os responsáveis pela manutenção do projeto na Appwrite, eles lançaram rapidamente correções para os pacotes appwrite/server-ce e litespeed.js. Como a aplicação é amplamente usada, também foi publicado um CVE no National Vulnerability Database.

Depois que a vulnerabilidade foi corrigida, os responsáveis pela manutenção da Appwrite ofereceram um vale-presente a Libera, que pediu que ele fosse doado em benefício da comunidade de código aberto. No geral, só podemos elogiar a forma como a Appwrite lidou com o problema de segurança. Ao levar o caso a sério e trabalhar com a comunidade para resolvê-lo, a equipe ajudou a manter o código aberto seguro.

Resumo

Ao desenvolver e manter continuamente os conjuntos de regras que impulsionam o Snyk Code, a Snyk garante um aumento constante na precisão da cobertura. Buscamos continuamente novos padrões de problemas e os implementamos, sem deixar de manter as regras existentes. Para nós, o conjunto de regras faz parte do produto — e temos a responsabilidade de criá-lo e mantê-lo.

Experimente o Snyk Code gratuitamente hoje e veja como nossa plataforma de segurança centrada em desenvolvedores ajuda você a escrever código de alta qualidade com mais eficiência do que nunca.

1 Beller, M., Bholanath, R., McIntosh, S., & Zaidman, A. (2016). "Analyzing the state of static analysis: A large-scale evaluation in open source software". 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering, SANER 2016, 1, 470–481. https://doi.org/10.1109/SANER.2016.105