Bem-vindo ao nosso blogue.

Vamos ao ataque à cadeia de abastecimento do tj-actions/changed-files. Leia o TL;DR, o que deve fazer, o que aconteceu e mais informações.

TL;DR

- O tj-actions/changed-files O GitHub Action, que é atualmente utilizado em mais de 23.000 repositórios, foi comprometido, tendo sido divulgados segredos através de registos de fluxo de trabalho e afetado milhares de pipelines de CI.

- Todas as versões marcadas foram modificadas, tornando insegura a fixação baseada em marcações. Os repositórios públicos são os que correm maior risco, mas os repositórios privados também devem verificar a sua exposição.

- Os passos imediatos incluem a identificação dos fluxos de trabalho afectados, a remoção de todas as referências à ação comprometida, a rotação de segredos e a verificação de registos de actividades suspeitas.

Resposta da Aikido: Lançámos uma nova regra SAST que assinala qualquer utilização com gravidade crítica (Pontuação 100). O Aikido pode fixar automaticamente as suas acções no Github para evitar este tipo de exploração no futuro.

Em primeiro lugar, o que é que deve fazer?

Verificar se é afetado pelo j-actions/changed-files ataque à cadeia de abastecimento:

A) Procurar tj-acções na sua base de código

B) Utilize esta consulta do Github para encontrar referências à ação GitHub afetada nos repositórios da sua organização (substitua [your-org] pelo nome da sua organização).

Deixar de utilizar tj-actions/changed-files o mais rapidamente possível e remover todas as referências à ação comprometida.

Rode os segredos dos pipelines afectados e verifique os registos dos seus serviços (de terceiros) quanto à utilização suspeita dos tokens expostos; concentre-se primeiro nos repositórios com registos de CI runner acessíveis ao público.

Vamos ao ataque: O que é que aconteceu?

Um incidente de segurança envolvendo o tj-actions/changed-files O GitHub Action foi identificado em meados de março de 2025. Os atacantes introduziram código malicioso que expôs segredos de CI/CD através de registos de fluxo de trabalho. Relatado pela primeira vez pela Step Security, o incidente foi atribuído ao CVE-2025-30066.

Embora ainda não haja clareza sobre o que aconteceu e como o código foi enviado, a maioria dos relatórios indica que o invasor comprometeu um Token de Acesso Pessoal (PAT) do GitHub vinculado à conta tj-actions-bot, o que permitiu ao invasor fazer modificações não autorizadas, injetar código malicioso e manipular tags de versão.

Cronologia dos acontecimentos:

Antes de 14 de março de 2025: O código malicioso começou a afetar os repositórios afectados, causando a fuga de segredos para registos públicos.

14 de março de 2025: Os investigadores de segurança identificaram o compromisso e aumentaram a consciencialização.

15 de março de 2025: O script malicioso alojado no GitHub Gist foi removido. O repositório comprometido foi brevemente colocado offline para reverter as alterações maliciosas e mais tarde restaurado sem os commits prejudiciais.

15 de março de 2025: O repositório está novamente online com uma declaração sobre o ataque; o mantenedor também comentou sobre o ataque.

Embora a ameaça imediata tenha sido resolvida, as versões em cache da ação comprometida podem continuar a representar um risco. É necessária uma atenuação proactiva para proteger as credenciais sensíveis.

Qual é o impacto do ataque tj-actions/changed-files?

Repositórios que utilizam tj-actions/changed-filesespecialmente as públicas, correm o risco de divulgar os segredos utilizados nos seus pipelies. Estes segredos foram expostos nos registos do fluxo de trabalho pelo código malicioso do agente da ameaça. Embora não tenha ocorrido nenhuma exfiltração de dados externa confirmada, os registos dos repositórios públicos podem ser acedidos por agentes maliciosos. Os repositórios privados são menos afectados, mas devem avaliar a sua exposição e rodar os segredos se forem afectados.

Repositórios públicos: Risco elevado devido à exposição pública de registos de fluxo de trabalho que contêm segredos.

Repositórios privados: Risco menor, mas ter segredos activos expostos nos registos do seu fluxo de trabalho continua a ser um risco significativo.

Utilizadores de acções em cache: Os fluxos de trabalho que colocaram em cache a ação comprometida podem continuar a estar em risco até que as caches sejam eliminadas.

Como é que o Aikido pode ajudar?

Lançámos um nova regra SAST que assinala qualquer tj-actions/changed-files utilização com gravidade crítica (Pontuação 100). Se já utiliza o Aikido, está protegido. Se não tiver uma conta Aikido, pode ligar-se e verificar a sua configuração em poucos segundos.

Para além deste ataque, o Aikido também fixa automaticamente as suas acções no Github para evitar este tipo de exploração no futuro.

E o nosso feed proprietário de ameaças de malware - Aikido Intel - detecta malware em 3 minutos após o lançamento no npm, pypi, e será alargado às acções do Github em breve.

Facilitamos o acesso à sua cadeia de fornecimento de software e avisamo-lo atempadamente de novos riscos e ataques.

Saiba mais sobre o ataque:

- Uma análise sobre "Compreensão e recriação do ataque à cadeia de fornecimento tj-actions/changed-files" pelo analista da Latio, James Berthoty. James também mostra como recriar o ataque no seu próprio ambiente para testar o seu sensor (tenha cuidado).

- A Step Security, que primeiro comunicou o ataque, publicou uma análise de investigação: "Deteção Harden-Runner: a ação tj-actions/changed-files está comprometida"

- Ver CVE-2023-51664

Porque é que estão aqui?

Quer saber a verdadeira resposta a duas perguntas sobre a segurança do Docker:

O Docker é seguro para utilização em produção?

‍Sime não. O Docker usa um modelo de segurança que se baseia em namespaces e isolamento de recursos, tornando os processos mais seguros contra ataques específicos do que executar seus aplicativos diretamente de uma VM em nuvem ou sistema bare metal. Apesar dessa camada, ainda existem muitas maneiras de os invasores acessarem seu contêiner, permitindo que eles leiam informações confidenciais, executem ataques de negação de serviço (DoS) ou até mesmo obtenham acesso root ao sistema host.

Como posso melhorar a segurança do meu Docker (de uma forma não muito dolorosa)?

‍Vamosguiá-lo através das vulnerabilidades mais comuns e graves do Docker, pulando as recomendações básicas que você encontrará em todo o Google, como usar imagens oficiais e manter seu host atualizado. Em vez disso, vamos levá-lo diretamente para novas opções de docker e linhas de Dockerfile que tornarão sua nova implantação de contêiner Docker padrão muito mais segura do que nunca.

A lista de verificação de segurança do Docker sem barreiras

Tornar os sistemas de ficheiros em contentor apenas de leitura

O que é que ganha?

Evita que um atacante edite o ambiente de tempo de execução do seu contentor Docker, o que poderia permitir-lhe recolher informações úteis sobre a sua infraestrutura, reunir dados do utilizador ou conduzir diretamente um ataque DOS ou ransomware.

Como é que se define?

Existem duas opções, em tempo de execução ou na configuração do Docker Compose.

Em tempo de execução: docker run --read-only your-app:v1.0.1

No seu ficheiro Docker Compose:

serviços:
webapp:
image: your-app:v1.0.1read_only: true
...

Escalada de privilégios de bloqueio

O que é que ganha?

Você impede que seu contêiner Docker - ou um invasor que esteja mexendo no contêiner - habilite novos privilégios, até mesmo no nível de raiz, com setuid ou setgid. Com acesso mais permissivo ao seu contêiner, um invasor pode acessar credenciais na forma de senhas ou chaves para partes conectadas da sua implantação, como um banco de dados.

Como é que se define?

Mais uma vez, em tempo de execução ou na configuração do Docker Compose.

Em tempo de execução: docker run --security-opt=no-new-privileges your-app:v1.0.1

No seu ficheiro Docker Compose:

serviços: 
	webapp:    
		image: your-app:v1.0.1    
		security_opt:      
			- no-new-privileges:true    
...

Isolar as suas redes de contentor para contentor

O que é que ganha?

Por defeito, o Docker permite que todos os contentores comuniquem através da rede docker0, o que pode permitir que um atacante se desloque lateralmente de um contentor comprometido para outro. Se você tiver serviços discretos A e B em contentores Y e ZSe as redes de um utilizador final não precisam de comunicar diretamente, isolar as suas redes proporciona a mesma experiência ao utilizador final e impede o movimento lateral para uma melhor segurança do Docker.

Como é que se define?

É possível especificar redes Docker em tempo de execução ou na configuração do Docker Compose. No entanto, primeiro é necessário criar a rede:

docker network create your-isolated-network (rede isolada)

Em tempo de execução, adicione o --Opção de reden: docker run --network your-isolated-network your-app:v1.0.1

Ou a opção equivalente no seu ficheiro Docker Compose:

serviços: 
	webapp:    
    	 image: your-app:v1.0.1    
        networks:     
        	- sua-rede-isolada    
		...

Definir um utilizador não-root adequado

O que é que ganha?

O utilizador predefinido num contentor é raiz, com um uid de 0. Ao especificar um utilizador distinto, evita que um atacante aumente os seus privilégios para outro utilizador que possa tomar medidas sem restrições, como o root, o que anularia quaisquer outras medidas de segurança do Docker que tenha trabalhado arduamente para implementar.

Como é que se define?

Crie o seu utilizador durante o processo de construção ou em tempo de execução. Em tempo de execução, é possível criar o utilizador pela primeira vez ou substituir a função UTILIZADOR que já definiu na construção.

Durante o processo de construção, no seu Dockerfile:

...
EXECUTAR groupadd -r seu-utilizador
EXECUTAR useradd -r -g seu-utilizador seu-utilizador
UTILIZADOR meuutilizador
...

‍

Em tempo de execução: docker run -u seu-usuário sua-app:v1.0.1

Largar as capacidades do kernel Linux

O que é que ganha?

Por padrão, os contêineres do Docker podem usar um conjunto restrito de recursos do kernel do Linux. Você pode pensar que o pessoal do Docker criou esse conjunto restrito para ser completamente seguro, mas muitos recursos existem para compatibilidade e simplicidade. Por exemplo, os contentores predefinidos podem alterar arbitrariamente a propriedade dos ficheiros, alterar o seu diretório raiz, manipular UIDs de processos e ler sockets. Ao eliminar alguns ou todos esses recursos, você minimiza o número de vetores de ataque.

Como é que se define?

É possível eliminar capacidades e definir novas capacidades em tempo de execução. Por exemplo, pode eliminar todas as capacidades do kernel e permitir ao seu contentor apenas a capacidade de alterar a propriedade dos ficheiros existentes.

docker run --cap-drop ALL --cap-add CHOWN your-app:v1.0.1

‍

Ou para o Docker Compose:

serviços:
	webapp:
    	 image: your-app:v1.0.1
        cap_drop: 
        	- TODOS
        cap_add: 
        	- CHOWN
        ...

Prevenir as bombas de garfo

O que é que ganha?

Fork bombs são um tipo de ataque DoS que replica infinitamente um processo existente. Em primeiro lugar, reduzem o desempenho e restringem os recursos, o que inevitavelmente aumenta os custos e pode, em última análise, fazer crashar os seus contentores ou o sistema anfitrião. Uma vez iniciada uma fork bomb, não há outra forma de a parar para além de reiniciar o contentor ou o anfitrião.

Como é que se define?

Em tempo de execução, pode limitar o número de processos (PIDs) que o seu contentor pode criar.

docker run --pids-limit 99 sua-app:v1.0.1

‍

Ou com o Docker Compose:

serviços:
	webapp:
		imagem: your-app:v1.0.1
deploy
			limites:
				pids: 99

‍

Melhore a segurança do Docker monitorizando as suas dependências de código aberto

O que é que ganha?

Os aplicativos que você conteinerizou para implantação com o Docker provavelmente têm uma ampla árvore de dependências.

Como é que se define?

A forma mais "não-BS" é com a análise de dependências de código aberto do Aikido. A nossa monitorização contínua analisa projectos escritos em mais de uma dúzia de idiomas com base na presença de ficheiros de bloqueio na sua aplicação e fornece uma visão geral instantânea das vulnerabilidades e malware. Com a triagem automática que filtra os falsos positivos, o Aikido dá-lhe conselhos de correção com os quais pode começar a trabalhar imediatamente... e não apenas depois de ler uma dúzia de outros documentos de referência e problemas do GitHub.

Na Aikido, adoramos projectos open-source estabelecidos como o Trivy, o Syft e o Grype. Também sabemos por experiência própria que utilizá-los isoladamente não é uma experiência particularmente boa para o programador. Por baixo do capô, o Aikido melhora estes projectos com regras personalizadas para colmatar lacunas e revelar falhas de segurança que não conseguiria encontrar de outra forma. Ao contrário de encadear várias ferramentas de código aberto, o Aikido liberta-o da necessidade de construir um script de verificação ou criar um trabalho personalizado no seu CI/CD.

Utilizar apenas imagens fiáveis para segurança do Docker

O que é que ganha?

O Docker Content Trust (DCT) é um sistema para assinar e validar o conteúdo e a integridade das imagens oficiais que extrai dos registos do Docker, como o Docker Hub. Extrair apenas imagens assinadas pelo autor dá-lhe mais garantias de que não foram adulteradas para criar vulnerabilidades na sua implementação.

Como é que se define?

A forma mais fácil é definir a variável de ambiente na sua shell, o que o impede a si ou a qualquer outra pessoa de trabalhar com imagens não confiáveis.

exportDOCKER_CONTENT_TRUST=1
docker run ...

Ou pode definir a variável de ambiente sempre que executar o Docker:

DOCKER_CONTENT_TRUST=1 docker run ...

Atualizar tempos de execução de fim de vida (EOL)

O que é que ganha?

Uma recomendação comum para a segurança de contentores Docker é fixar imagens e dependências a uma versão específica em vez de mais recente. Em teoria, isso impede-o de utilizar inconscientemente novas imagens, mesmo que tenham sido adulteradas, que introduzem novas vulnerabilidades.

Como é que se define?

Existem alguns projectos de código aberto disponíveis para o ajudar a descobrir EOLs e a preparar-se melhor. O projeto endoflife.date(repositório GitHub) rastreia mais de 300 produtos, agregando dados de várias fontes e disponibilizando-os através de uma API pública. Tem algumas opções com o endoflife.date e projectos semelhantes:

• Verifique manualmente se o projeto tem actualizações nas dependências de que as suas aplicações dependem e crie bilhetes ou problemas para as actualizações necessárias.
• Escreva um script (Bash, Python, etc.) para obter as datas de EOL das dependências da API e execute-o regularmente, como um cron job.
• Incorpore a API pública, ou esse script personalizado, na sua plataforma de CI para falhar as compilações que usam um projeto que está próximo ou atingiu o EOL.

Como desenvolvedor, entendemos que seu tempo é valioso e muitas vezes limitado. É aqui que o Aikido pode proporcionar uma sensação de segurança - o nosso recurso de verificação EOL rastreia o seu código e contentores, dando prioridade aos tempos de execução com maior impacto e exposição, como o Node.js ou um servidor Web Nginx. Como de costume, não apenas automatizamos a coleta de informações, mas também fornecemos alertas com a gravidade apropriada para informar, e não sobrecarregar.

Limitar a utilização de recursos do contentor

O que é que ganha?

Por padrão, os contêineres não têm restrições de recursos e usarão tanta memória ou CPU quanto o agendador do host. Limitar o uso de recursos de um contêiner específico pode minimizar o impacto de um ataque DoS. Em vez de fazer crashar o seu contentor ou sistema anfitrião devido a uma Exceção de Memória, o ataque DoS em curso terá "apenas" um impacto negativo na experiência do utilizador final.

Como é que se define?

Em tempo de execução, é possível utilizar o -memória e --cpus para definir limites para a utilização da memória e da CPU, respetivamente. A opção de memória assume números com g para gigabytes e m para megabytes, enquanto a opção de CPU reflecte o limite de CPUs dedicadas disponíveis para o contentor e os seus processos.

docker run --memory="1g" --cpus="2" sua-app:v1.0.1

Isto também funciona com o Docker Compose:

serviços:
	webapp:
    	 image: your-app:v1.0.1
        deploy: 
            limites:
            	 cpus: '2'
                memória: 1G 
         ...

O seu comando final e as opções do Compose para a segurança do Docker

Até agora, já viu algumas dicas de segurança do Docker e as opções ou configurações relevantes da CLI para as acompanhar, o que significa que está bastante entusiasmado para as implementar ou sobrecarregado com a forma de as juntar todas. Abaixo, reunimos todas as recomendações em um único comando ou modelo de configuração, que o ajudará a começar a implantar contêineres Docker mais seguros imediatamente.

Obviamente, irá querer alterar algumas das opções - como o nome de utilizador não-root, capacidades do kernel, limites de recursos - com base nas necessidades da sua aplicação.

exportDOCKER_CONTENT_TRUST=1
docker run \ 
    --read-only \ 
   --security-opt=no-new-privileges\ 
    --network your-isolated-network \ 
    --cap-drop ALL 
    --cap-add CHOWN \ 
    --pids-limit 99 \ 
    --memory="1g" --cpus="2" \ 
    --user=seu-utilizador \ 
    ...                 # OUTRAS OPÇÕES VÃO AQUI  
    sua-app:v1.0.1

Pode até querer criar um alias drun com a shell do seu anfitrião que pode invocar sem ter de se lembrar de todos esses detalhes.

função drun  { 
docker run \ 
    	--read-only \ 
       --security-opt=no-new-privileges\ 
        --network your-isolated-network \ 
        --cap-drop ALL 
        --cap-add CHOWN \ 
        --pids-limit 99 \ 
        --memory="1g" --cpus="2" \ 
        --user=seu-utilizador \ 
       $1 \ 
       $2
}

De seguida, execute o seu alias da seguinte forma, com as suas opções e o nome da imagem: drun -it your-app:v1.0.1

Se for do tipo que gosta do Docker Compose, pode adaptar todas as mesmas opções num novo modelo de base do Docker Compose a partir do qual pode trabalhar no futuro:

serviços:
	webapp:
    	 image: your-app:v1.0.1
        read_only: true
        security_opt:
           - no-new-privileges:true
        networks: 
           - sua-rede-isolada
        cap_drop: 
           - ALL
        cap_add: 
           - CHOWN
        deploy: 
        	limits:
        		 pids: 9
        		 cpus: '2'
        		memory: 1G 
        ...               # OUTRAS OPÇÕES VÃO AQUI

Bónus: Executar o Docker com contentores sem raiz

Quando você instala o Docker em qualquer sistema, seu daemon opera com privilégios de nível de raiz. Mesmo que ative todas as opções acima e evite o escalonamento de privilégios dentro de um contentor Docker, o resto do tempo de execução do contentor no seu sistema anfitrião continua a ter privilégios de raiz. Isso inevitavelmente amplia sua superfície de ataque.

A solução são os contentores sem raiz, que um utilizador sem privilégios pode criar e gerir. A ausência de privilégios de raiz significa muito menos problemas de segurança para o seu sistema anfitrião.

Gostaríamos de poder ajudá-lo a usar contêineres sem raiz com uma única opção ou comando, mas não é tão simples assim. Você pode encontrar instruções detalhadas no site Rootless Containers, incluindo um guia de instruções para o Docker.

O que se segue para a sua segurança Docker?

‍

Se você aprendeu alguma coisa com essa experiência, é que a segurança de contêineres é uma operação de cauda longa. Há sempre mais listas de verificação de endurecimento e artigos aprofundados para ler sobre como bloquear seus contêineres no Docker ou seu primo mais antigo e muitas vezes incompreendido, o Kubernetes. Não é possível almejar uma segurança de contêineres sem falhas - criar tempo em sua agenda de desenvolvimento ocupada para abordar a segurança e, em seguida, fazer melhorias incrementais com base no impacto e na gravidade, irá percorrer um longo caminho ao longo do tempo.

Para o ajudar a maximizar esse processo contínuo e a dar prioridade às correcções que irão melhorar significativamente a segurança das suas aplicações, existe o Aikido. Acabámos de angariar uma Série A de 17 milhões de dólares para a nossa plataforma de segurança para programadores "no BS" e gostaríamos que se juntasse a nós.

Porque é que estão aqui?

Já ouviu falar de ataques de injeção de SQL em JavaScript, mas não tem a certeza absoluta de como são na prática ou se precisa de se preocupar com eles. Talvez esteja a tentar perceber o quão grave pode ser.

Em suma, se está a criar aplicações que utilizam bases de dados SQL, como MySQL e PostgreSQL, está em risco - não está a salvo dos métodos de ataque que assolam os programadores e as suas bases de dados há décadas. Como programador, a responsabilidade recai sobre si para implementar guardrails que protejam os dados do utilizador e garantir que a sua infraestrutura subjacente nunca é invadida, explorada ou comandada.

Todas as novas ferramentas dizem que o estão a ajudar, mas apenas tornam o desenvolvimento mais complexo.

Pode adicionar um mapeador objeto-relacional (ORM) como o Sequelize e o TypeORM para simplificar a forma como trabalha com bases de dados SQL como o MySQL e o PostgreSQL, mas não o isentam completamente de riscos. As firewalls de aplicações Web (WAFs) ajudam a bloquear ataques ao nível da rede, mas requerem infra-estruturas dispendiosas e manutenção constante. Os scanners de código podem ajudá-lo a identificar falhas óbvias, mas fazem muito menos pelas incógnitas desconhecidas e pelas técnicas de dia zero à espreita.

Vamos apresentar-lhe uma imagem clara do aspeto dos ataques de injeção de SQL, do risco que representam e dos erros de desenvolvimento que os tornam possíveis. Depois, faremos melhor, guiando-o na instalação de um hotfix global para que saiba, com certeza, que as suas aplicações estão seguras.

Ataques de injeção de SQL: exemplos e implicações

A definição mais básica de um ataque de injeção de SQL é quando uma aplicação permite que a entrada do utilizador não validada e não higienizada execute consultas à base de dados, permitindo que um atacante leia a base de dados SQL, modifique registos ou elimine o que lhe apetecer.

Como é habitual, o XKCD ilustra o perigo da SQL melhor do que a maioria dos cenários sombrios que poderíamos imaginar:

Qual é o aspeto de uma aplicação JavaScript vulnerável?

Vamos começar com um exemplo simples de pseudocódigo: uma aplicação JavaScript com um elemento de entrada que permite aos utilizadores pesquisar uma base de dados de gatos. No exemplo de código JavaScript abaixo, a aplicação responde a pedidos POST no caminho /cats para extrair a entrada do utilizador do corpo do pedido e liga-se à base de dados com uma consulta para devolver todos os gatos com um ID correspondente. Em seguida, a aplicação apresenta o gato utilizando a resposta JSON.

app.post("/cats", (request, response) => {
	const query = `SELECT * FROM cats WHERE id = ${request.body.id}`;
	connection.query(query, (err, rows) => {
    	if(err) throw err;
        response.json({
        	data: rows
		});  
	});
});

Embora este exemplo possa parecer inócuo para quem não tem formação em ataques de injeção SQL, é extremamente vulnerável. Nomeadamente, a aplicação não tenta validar ou higienizar a entrada do utilizador para sequências ou métodos de codificação potencialmente perigosos econcatenaa entrada do utilizador diretamente na consulta SQL, o que permite aos atacantes múltiplas oportunidades de atacar utilizando métodos de ataque de injeção SQL comuns que existem há décadas.

Exemplo de cargas úteis de ataque JavaScript SQL

A injeção de SQL baseia-se em enganar a sua base de dados MySQL ou PostgreSQL para que tome medidas ou responda com dados fora do âmbito esperado devido à forma como a sua aplicação gera consultas SQL.

O 1=1 é sempre verdadeiro ataque pode devolver toda a tabela de gatos com truques como apóstrofos ou aspas, porque 1=1 é de facto sempre VERDADEIRO:

• O utilizador introduz os dados: BOBBY TABLES" OU 1='1
• A base de dados executa a consulta SQL: SELECT * FROM Users WHERE Cat = BOBBY TABLES OR 1=1;

Da mesma forma, os atacantes podem explorar um = é sempre verdade ataque para devolver todos os gatos, porque ""="" é sempre VERDADEIRO:

• O utilizador introduz os dados: " OU ""="
• A base de dados executa a consulta SQL: SELECT * FROM Cats WHERE CatId ="" or ""="";

Os atacantes exploram frequentemente a forma como as bases de dados tratam os comentários em linha e, ao inserirem comentários (/* ... */) numa consulta, podem ofuscar a sua intenção ou contornar filtros.

• O utilizador introduz os dados: DR/*hello world*/OP/*sneak attack*/ TABLE Cats;
• A base de dados executa a consulta SQL: DROP TABLE Cats;

Outra estratégia comum de injeção SQL em JavaScript é o empilhamento de consultas, que permite que os atacantes comecem com uma cadeia inócua e, em seguida, utilizem um ponto e vírgula (;) para terminar essa declaração e iniciar outra que contenha a sua injeção. Os atacantes utilizam frequentemente o empilhamento de consultas para eliminar bases de dados inteiras de uma só vez com um comando DROP TABLE:

• O utilizador introduz os dados: Bobby; DROP TABLE Cats --
• A aplicação constrói a sua consulta SQL: const query = "SELECT * FROM Cats WHERE CatId = " + input;
• A base de dados executa a consulta SQL: SELECT * FROM Cats WHERE CatId = BOBBY; DROP TABLE Cats;

E quanto aos ataques de injeção NoSQL?

Os ataques de injeção NoSQL são igualmente perigosos para a segurança da sua aplicação e dos dados do utilizador, mas apenas afectam as pilhas de tecnologia que utilizam bases de dados como o MongoDB. A principal diferença são os ataques de estilo, uma vez que as consultas SQL e NoSQL utilizam uma sintaxe totalmente única que não se traduz de uma categoria para a outra.

Se estiver a utilizar uma base de dados SQL, não corre o risco de sofrer ataques de injeção NoSQL e vice-versa.

O caminho básico: corrigir manualmente todas as suas vulnerabilidades de injeção de SQL

Nesta altura, poderá estar menos interessado em saber quais são os possíveis truques de injeção e mais interessado em saber como proteger os dados que tem no MySQL ou PostgreSQL.

• Utilizar consultas parametrizadas: O SQL tem a funcionalidade de desligar a execução de consultas e valores, protegendo a base de dados de ataques de injeção. Com o exemplo JavaScript/Node.js acima, pode utilizar um marcador de posição na sua consulta SQL com um ponto de interrogação (?). O conexão.consulta() recebe então o parâmetro no seu segundo argumento, fornecendo os mesmos resultados num método à prova de injeção.

app.post("/cats", (request, response) => {  
	const query = `SELECT * FROM Cats WHERE id = ?`;  
    const value = request.body.id;  
    connection.query(query, value, (err, rows) => {    
    	if(err) throw err;    
        response.json({      
        	data: rows    
		});  
	});
});

‍

• Validar e higienizar a entrada do utilizador: Embora as consultas parametrizadas possam ajudar a proteger a sua base de dados SQL contra intrusões e ataques, também pode impedir que os utilizadores introduzam cadeias de caracteres potencialmente perigosas na sua aplicação.
  
  Uma opção é adicionar bibliotecas de código aberto para sanitização e validação à sua aplicação. Por exemplo, você pode usar validador.js no ecossistema JavaScript/Node.js para verificar se um utilizador está a tentar introduzir um endereço de e-mail real - e não um ataque de injeção de SQL - no seu formulário de inscrição.
  
  Também pode desenvolver validadores personalizados baseados em regex para efetuar um trabalho semelhante, mas terá pela frente um caminho extremamente moroso e complexo, com pesquisas e toneladas de testes manuais. Além disso, consegue mesmo interpretar este exemplo de regex para validação de correio eletrónico?
  
  const re = /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;
  
  A mesma ideia aplica-se à prevenção de cadeias de caracteres como ..." OU 1-'1. Pode tentar investigar e eliminar todas estas oportunidades, mas provavelmente preferiria passar o seu tempo a criar novas funcionalidades.

‍

• Implantar WAFs ou plataformas de segurança baseadas em agentes: Embora essas soluções possam bloquear ataques de SQL antes mesmo que eles toquem seu aplicativo ou, pelo menos, notificá-lo em tempo real à medida que os ataques acontecem, elas vêm com algumas ressalvas.
  
  Primeiro, elas geralmente são caras e exigem que você inicie uma nova infraestrutura no local ou na nuvem, que geralmente é muito mais complexa do que a que você assinou como um desenvolvedor que só quer enviar para a produção. Em segundo lugar, exigem mais manutenção manual para atualizar o conjunto de regras, distraindo-o de outras intervenções manuais para a injeção de SQL. Por último, adicionam frequentemente mais carga computacional ou redireccionam todos os pedidos através da sua plataforma para análise, aumentando a latência e prejudicando a experiência do utilizador final.

O grande problema é que as oportunidades de ataques de injeção de SQL são como ervas daninhas - pode cortá-las todas uma vez utilizando estas ferramentas, mas tem de estar constantemente atento a toda a sua base de código para garantir que nunca mais brotam.

Um caminho alternativo para resolver ataques de injeção de SQL em JavaScript: Firewall Aikido

A Aikido Security lançou recentemente o Firewall, um motor de segurança gratuito e de código aberto que o projecta de forma autónoma contra ataques de injeção de SQL - e muito mais.

Se você não estiver usando Node.js, saiba que começaremos a oferecer suporte a outras linguagens e estruturas no futuro. Pode sempre subscrever a nossa newsletter de produtos para saber exatamente quando a Firewall se expandir para além do mundo do JavaScript ou enviar-nos um e-mail para hello@aikido.dev se quiser lançar uma linguagem específica.

Testar uma aplicação que é vulnerável à injeção de SQL do JavaScipt

Vamos usar um aplicativo de amostra que vem com o repositório de código aberto para mostrar como o Aikido Firewall funciona. Também vai precisar do Docker/DockerCompose para implementar uma base de dados MySQL local.

Comece por bifurcar o repositório firewall-node e clonar essa bifurcação para a sua estação de trabalho local.

git clone https://github.com/<YOUR-GITHUB-USERNAME>/firewall-node.gitcd firewall-node

Use o Docker para implantar um banco de dados MySQL local na porta 27015. Este ficheiro docker-compose.yml também cria contentores s3mock, MongoDB e PostgreSQL, uma vez que foi criado para ajudar a equipa Aikido a testar como a Firewall bloqueia vários ataques.

docker-compose -f sample-apps/docker-compose.yml up -d

Em seguida, inicie a aplicação de amostra:

node sample-apps/express-mysql2/app.js

Aberto http://localhost:4000 no seu browser para ver a aplicação muito simples para gatos. Na área de texto, escreva alguns nomes de gatos e clique no botão Adicionar botão. Para testar a injeção de SQL, pode clicar no botão Injeção de teste ligação ou escreva o seguinte na área de texto: Kitty'); DELETE FROM cats;-- H e clique em Adicionar novamente. De qualquer forma, a aplicação permite empilhar várias consultas em conjunto utilizando alguns comentários de consulta furtivos, eliminando toda a base de dados de gatos.

Como é que isto acontece? Tal como avisámos anteriormente, esta aplicação simplesmente acrescenta qualquer a entrada do utilizador no final da consulta SQL, que é inerentemente insegura.

const query = `INSERT INTO cats(petname) VALUES ('${name}');`

As consequências podem ser pequenas, mas não é difícil imaginar como este erro, muitas vezes honesto, pode ter consequências desastrosas para a sua aplicação de produção.

Bloqueio da injeção de SQL em JavaScript com a Aikido Firewall

Vejamos agora a rapidez com que o nosso motor de segurança de código aberto bloqueia ataques de injeção de SQL em JavaScript sem ter de corrigir manualmente cada interação com a base de dados no seu código.

Se ainda não tem uma conta Aikido, vá em frente e fazer um gratuitamente. Se já tiver um, inicie sessão e ligar a sua conta GitHub. Durante esse processo, conceda à Aikido acesso para ler a sua bifurcação do nó de firewall projeto.

Ir para o Painel de controlo da firewall e clique em Adicionar serviço. Dê um nome ao seu serviço e, mais uma vez, escolha o seu fork para o nó de firewall projeto.

O Aikido então instrui-o sobre como instalar e implementar o Aikido Firewall. Como estamos a usar a aplicação de exemplo, esse trabalho já está feito para si, mas é uma referência útil para saber como levar o nosso motor de segurança de código aberto a todas as suas aplicações Node.js que possam estar vulneráveis a ataques de injeção de SQL em JavaScript.

Clique no botão Gerar Token para criar um token para permitir que a Aikido Firewall transmita de forma segura informações sobre ataques de injeção de SQL bloqueados para a plataforma de segurança Aikido. Copie o token gerado, que começa com AIK_RUNTIME...e volte ao terminal para executar novamente a aplicação de amostra, mas agora com o Firewall totalmente ativado no modo de bloqueio:

AIKIDO_TOKEN=<YOUR-AIKIDO-TOKEN> AIKIDO_DEBUG=true AIKIDO_BLOCKING=true node sample-apps/express-mysql2/app.js

Aberto localhost:4000 e, mais uma vez, invocar o ataque de injeção de SQL incluído. Desta vez, o Aikido bloqueia-o no browser, envia para os registos do seu servidor Web local e gera um novo evento. Clique nele para ver detalhes abrangentes sobre a tentativa de injeção de SQL, incluindo o payload e onde a sua aplicação gerou a perigosa consulta SQL.

Em vez de se preocupar em proteger para sempre as suas aplicações contra ataques de injeção de SQL JavaScript, tanto críticos como ainda não vistos, a Aikido Firewall oferece um bloqueio abrangente e uma observabilidade sofisticada que o mantém informado sobre fontes de ataque, cargas úteis comuns e potenciais pontos fracos.

O que é que se segue?

Pode instalar e implementar a Aikido Firewall em todas as suas aplicações baseadas em Node.js gratuitamente. O nosso motor de segurança incorporado de código aberto protege a sua infraestrutura e os dados dos utilizadores contra ataques de injeção de SQL em JavaScript, injeção de comandos, poluição de protótipos, passagem de caminhos e muito mais, que será apresentado em breve.

Não estamos dizendo que o Firewall deve substituir as práticas recomendadas de desenvolvimento para proteção contra injeção de SQL, como o uso de consultas parametrizadas ou nunca confiar na entrada do usuário, mas também sabemos por experiência própria que nenhum desenvolvedor é perfeito. Nenhuma base de código é sem falhas, e erros honestos acontecem o tempo todo.

Pense no Firewall como um hotfix global para injeção de SQL. Ao contrário do regex desenvolvido sob medida, WAFs que induzem latência ou agentes de segurança complexos que custam um belo centavo, ele faz esse trabalho extraordinariamente bem e com impacto insignificante - inteiramente de graça.

Se gostou do que viu, consulte o nosso roteiro e dê uma estrela ao nosso repositório GitHub(https://github.com/AikidoSec/firewall-node). ⭐

Introdução

Imagine que está a criar uma aplicação Web para blogues utilizando o Prisma. Escreve uma consulta simples para autenticar utilizadores com base no seu e-mail e palavra-passe fornecidos:

1const user = await prisma.user.findFirst({
2  where: { email, password },
3});

Parece inofensivo, certo? Mas e se um atacante enviar password = { "not": "" }? Em vez de devolver o objeto Utilizador apenas quando o e-mail e a palavra-passe coincidem, a consulta devolve sempre o Utilizador quando apenas o e-mail fornecido coincide.

Esta vulnerabilidade é conhecida como injeção de operador, mas é mais comummente referida como injeção NoSQL. O que muitos programadores não sabem é que, apesar dos esquemas de modelos rigorosos , alguns ORM são vulneráveis à injeção de operadores, mesmo quando são utilizados com uma base de dados relacional como o PostgreSQL, o que torna este risco mais generalizado do que o esperado.

Neste post, exploraremos como funciona a injeção de operador, demonstraremos explorações no Prisma ORM e discutiremos como evitá-las.

Compreender a Injeção de Operador

Para compreender a injeção de operadores em ORM, é interessante olhar primeiro para a injeção NoSQL. O MongoDB apresentou aos desenvolvedores uma API para consulta de dados usando operadores como $eq, $lt e $ne. Quando a entrada do utilizador é passada cegamente para as funções de consulta do MongoDB, existe o risco de injeção NoSQL.

Bibliotecas ORM populares para JavaScript começaram a oferecer uma API semelhante para consulta de dados e agora quase todos os principais ORMs suportam alguma variação de operadores de consulta, mesmo quando não suportam o MongoDB. Prisma, Sequelize e TypeORM implementaram suporte para operadores de consulta para bancos de dados relacionais, como o PostgreSQL.

Explorando a injeção de operador no Prisma

As funções de consulta Prisma que operam em mais de um registo suportam normalmente operadores de consulta e são vulneráveis à injeção. Exemplos de funções incluem findFirst, findMany, updateMany e deleteMany. Embora o Prisma valide os campos do modelo referenciados na consulta em tempo de execução, os operadores são uma entrada válida para essas funções e, portanto, não são rejeitados pela validação.

Uma razão pela qual a injeção de operador é fácil de explorar no Prisma são os operadores baseados em string oferecidos pela API do Prisma. Algumas bibliotecas ORM removeram o suporte para operadores de consulta baseados em string porque eles são facilmente ignorados pelos desenvolvedores e fáceis de explorar. Em vez disso, obrigam os programadores a referenciar objectos personalizados para os operadores. Como esses objetos não podem ser prontamente desserializados da entrada do usuário, o risco de injeção de operação é bastante reduzido nessas bibliotecas.

Nem todas as funções de consulta no Prisma são vulneráveis à injeção de operador. As funções que selecionam ou alteram um único registo da base de dados normalmente não suportam operadores e lançam um erro em tempo de execução quando é fornecido um objeto. Além de findUnique, as funções Prisma update, delete e upsert também não aceitam operadores em seu filtro where.

1  // This query throws a runtime error:
2  // Argument `email`: Invalid value provided. Expected String, provided Object.
3  const user = await prisma.user.findUnique({
4    where: { email: { not: "" } },
5  });

‍

Melhores práticas para evitar a injeção de operador

1. Converter a entrada do utilizador em tipos de dados primitivos

Normalmente, a conversão da entrada para tipos de dados primitivos, como cadeias de caracteres ou números, é suficiente para evitar que os atacantes injectem objectos. No exemplo original, a conversão seria a seguinte:

1  const user = await prisma.user.findFirst({
2    where: { email: email.toString(), password: password.toString() },
3  });

2. Validar a entrada do utilizador

Embora o casting seja eficaz, poderá querer validar a entrada do utilizador, para garantir que a entrada cumpre os requisitos da lógica empresarial.

Existem muitas bibliotecas para validação do lado do servidor da entrada do utilizador, como class-validator, zod e joi. Se estiver a desenvolver para uma estrutura de aplicações Web, como a NestJS ou a NextJS, é provável que estas recomendem métodos específicos para a validação do input do utilizador no controlador.

No exemplo original, a validação zod pode ter o seguinte aspeto:

1import { z } from "zod";
2
3const authInputSchema = z.object({
4  email: z.string().email(),
5  password: z.string().min(8)
6});
7
8const { email, password } = authInputSchema.parse({email: req.params.email, password: req.params.password});
9
10const user = await prisma.user.findFirst({
11  where: { email, password },
12});

3. Mantenha o seu ORM atualizado

Mantenha-se atualizado para se beneficiar das melhorias e correções de segurança. Por exemplo, o Sequelize desativou os aliases de cadeia de caracteres para operadores de consulta a partir da versão 4.12, o que reduz significativamente a suscetibilidade à injeção de operador.

Conclusão

A injeção de operador é uma ameaça real para as aplicações que utilizam ORMs modernos. A vulnerabilidade decorre da conceção da API ORM e não está relacionada com o tipo de base de dados utilizado. Na verdade, mesmo o Prisma combinado com o PostgreSQL pode ser vulnerável à injeção de operador. Embora o Prisma ofereça alguma proteção integrada contra a injeção de operador, os desenvolvedores ainda devem praticar a validação e a sanitização de entrada para garantir a segurança do aplicativo.

Apêndice: Esquema Prisma para o modelo do utilizador

1// This is your Prisma schema file,
2// learn more about it in the docs: https://pris.ly/d/prisma-schema
3
4generator client {
5  provider = "prisma-client-js"
6}
7
8datasource db {
9  provider = "postgresql"
10  url      = env("DATABASE_URL")
11}
12
13// ...
14
15model User {
16  id       Int      @id @default(autoincrement())
17  email    String   @unique
18  password String
19  name     String?
20  posts    Post[]
21  profile  Profile?
22}

Os aplicativos modernos são enviados rapidamente - e isso geralmente significa que os bugs de segurança entram sorrateiramente na produção. Neste guia, explicamos o que é o teste dinâmico de segurança de aplicativos (DAST), por que ele é importante em 2025 e como escolher a ferramenta DAST certa para sua equipe, seja você um desenvolvedor solo ou um líder de segurança corporativa.

Nem todo leitor precisa se aprofundar em todas as mais de 15 ferramentas. Se você está aqui com um caso de uso específico em mente - digamos que esteja procurando a melhor DAST para desenvolvedores, startups ou segurança de API - sinta-se à vontade para pular diretamente para as sublistas adaptadas ao seu cenário.

Dito isso, recomendamos verificar a análise completa das ferramentas mais abaixo. Mesmo uma rápida olhada na lista principal pode trazer à tona uma ferramenta que você não havia considerado - ou ajudá-lo a entender por que algumas opções são consistentemente classificadas em todas as categorias.

O que é a DAST?

Os testes dinâmicos de segurança de aplicações (DAST) são um método de teste de segurança que avalia uma aplicação em execução de fora para dentro, à semelhança do que faria um atacante. Uma ferramenta DAST interage com uma aplicação Web através do seu front end (pedidos HTTP, interfaces Web, APIs) sem necessitar de aceder ao código-fonte. Esta abordagem de "caixa negra" envolve a simulação de entradas maliciosas e a análise das respostas da aplicação para identificar vulnerabilidades como injeção de SQL, Cross-Site Scripting (XSS), falhas de autenticação, configurações incorrectas e outros problemas de tempo de execução. Essencialmente, a DAST comporta-se como um hacker automatizado a sondar as defesas da sua aplicação.

As soluções DAST são diferentes das ferramentas de análise estática (SAST) porque testam a aplicação em execução num ambiente realista. Enquanto as SAST analisam o código-fonte em busca de erros, as DAST lançam ataques a uma aplicação implementada para verificar se essas vulnerabilidades podem ser exploradas em tempo real. Isto significa que a DAST pode encontrar problemas que só se manifestam quando todo o sistema está a funcionar - por exemplo, erros de configuração, controlos de acesso quebrados ou predefinições inseguras que não seriam aparentes apenas pela leitura do código. A DAST é frequentemente utilizada em testes de fase tardia (QA, staging ou mesmo produção com precaução) como uma verificação final para apanhar qualquer coisa que não tenha sido detectada anteriormente.

Em 2025, a DAST continua a ser crucial porque as aplicações Web modernas são cada vez mais complexas (aplicações de página única, microsserviços, APIs, etc.). As ferramentas DAST evoluíram para lidar com esses desafios - rastreando interfaces ricas, seguindo redirecionamentos, lidando com fluxos de autenticação e testando APIs REST/GraphQL, tudo isso sem precisar ver o interior do aplicativo. Muitas organizações adotam uma estratégia combinada de SAST e DAST para uma cobertura abrangente em todo o ciclo de vida de desenvolvimento de software. (Para uma comparação mais profunda, consulte nosso guia sobre o uso conjunto de SAST e DAST).

Porque é que precisa de ferramentas DAST

A segurança das aplicações Web é um alvo em movimento - atualmente, as aplicações estão expostas à Internet 24 horas por dia, 7 dias por semana, e os atacantes descobrem constantemente novas explorações. Eis porque é que a utilização de ferramentas DAST é uma necessidade em 2025:

• Cobertura do mundo real: As ferramentas DAST encontram vulnerabilidades a partir de uma perspetiva externa, mostrando-lhe exatamente o que um atacante poderia explorar numa aplicação em execução. Elas podem descobrir problemas no ambiente (configurações de servidor, componentes de terceiros, APIs) que as verificações de código estático podem deixar passar.
• Agnóstico em termos de linguagem e plataforma: Como o DAST interage com o aplicativo via HTTP e a interface do usuário, não importa em que linguagem ou estrutura o aplicativo foi escrito. Um scanner DAST pode testar Java, Python, Node ou qualquer plataforma web - ideal para ambientes poliglotas.
• Encontra erros críticos de tempo de execução: O DAST é excelente na deteção de problemas como servidores mal configurados, fluxos de autenticação quebrados, cookies inseguros e outros problemas de implantação que só aparecem quando o aplicativo está ativo. Muitas vezes, essas são vulnerabilidades de alto impacto (por exemplo, um portal de administração aberto ou uma senha padrão) que passam despercebidas nas revisões de código.
• Baixos falsos positivos (em muitos casos): As soluções DAST modernas utilizam técnicas como a verificação de ataques (por exemplo, prova de exploração) para confirmar vulnerabilidades e reduzir o ruído. Ao contrário do SAST, que pode assinalar problemas teóricos, o DAST mostra normalmente provas concretas (como "Consegui descarregar a sua base de dados através de injeção de SQL") - tornando mais fácil para os programadores confiarem nos resultados.
• Conformidade e paz de espírito: Muitas normas e regulamentos de segurança (PCI DSS, OWASP Top 10, etc.) recomendam ou exigem testes dinâmicos de aplicações Web. A utilização de uma ferramenta DAST ajuda a verificar essas caixas, produzindo relatórios que os auditores compreendem (por exemplo, cobertura dos 10 principais problemas do OWASP) e garante que não deixou buracos na sua aplicação antes do arranque.

Em suma, a DAST acrescenta uma camada essencial de segurança, atacando a sua aplicação da mesma forma que as ameaças reais o fariam - para que possa corrigir os pontos fracos antes que os maus actores os explorem.

Como escolher uma ferramenta DAST

Nem todos os scanners DAST são criados da mesma forma. Ao avaliar as ferramentas de teste de segurança de aplicativos dinâmicos, considere os seguintes critérios para encontrar a melhor opção:

• Cobertura de tecnologias: Certifique-se de que a ferramenta pode lidar com a pilha de tecnologia de seus aplicativos - ela oferece suporte a front-ends modernos com JavaScript pesado (aplicativos de página única), back-ends móveis e APIs (REST, SOAP, GraphQL)? Ferramentas como HCL AppScan e Invicti suportam uma ampla gama de tipos de aplicativos.
• Precisão e profundidade: Procure taxas elevadas de deteção de vulnerabilidades com um mínimo de falsos positivos. Recursos como varreduras de confirmação ou geração de prova de conceito (por exemplo, a varredura baseada em prova da Invicti) são valiosos para validar automaticamente as descobertas. Pretende uma ferramenta que revele problemas críticos, mas que não o sobrecarregue com ruído.
• Facilidade de utilização e integração: Uma boa DAST se encaixa no seu fluxo de trabalho. Considere ferramentas que oferecem configuração fácil (opções baseadas na nuvem ou gerenciadas), integração CI/CD para DevSecOps (Aikido, StackHawk, etc.) e integrações com rastreadores de problemas (Jira, GitHub) ou fluxos de trabalho. Se os seus programadores puderem desencadear análises a partir de pipelines e obter resultados nas suas ferramentas, a adoção será mais fácil.
• Autenticação e tratamento de complexidade: Muitas aplicações não são totalmente públicas - verifique se a DAST suporta a verificação autenticada (início de sessão com uma conta/sessão de utilizador) e se consegue lidar com coisas como formulários de vários passos ou fluxos complexos. Os scanners de nível empresarial, como o Burp Suite, o AppScan e outros, permitem gravar sequências de início de sessão ou scripts de autenticação.
• Relatórios e feedback dos programadores: O resultado deve ser fácil para o desenvolvedor. Procure descrições claras de vulnerabilidades, orientações de correção e relatórios de conformidade, se necessário (por exemplo, relatórios mapeados para OWASP Top 10, PCI, etc.). Algumas plataformas (como o DAST da Aikido) até fornecem sugestões automáticas de correção ou patches de código para acelerar a correção.
• Escalabilidade e desempenho: Se precisar de analisar dezenas ou centenas de aplicações, considere a forma como a ferramenta é dimensionada. Os serviços DAST baseados em nuvem (Qualys WAS, Rapid7 InsightAppSec, Tenable.io, etc.) podem executar varreduras em paralelo e gerenciar o agendamento. As ferramentas no local devem permitir vários mecanismos ou agentes de varredura para escalonamento. Avalie também a velocidade dos exames - algumas ferramentas oferecem exames incrementais ou otimização para re-testes mais rápidos.
• Suporte e manutenção: Finalmente, uma ferramenta é tão boa quanto a sua última atualização. Avalie a frequência com que o fornecedor actualiza as verificações de vulnerabilidade do scanner. O suporte ativo da comunidade ou do fornecedor é crucial, especialmente para opções de código aberto. Uma DAST desactualizada (ou sem suporte) pode não detetar novas ameaças ou avariar em aplicações modernas.

Tenha estes critérios em mente ao analisar o panorama das soluções DAST. Agora, vamos mergulhar nas principais ferramentas disponíveis em 2025 e ver como elas se comparam.

Principais ferramentas DAST para 2025

Nesta seção, listamos as melhores ferramentas de teste de segurança de aplicativo dinâmico de 2025. Elas incluem uma mistura de opções comerciais e de código aberto, cada uma com pontos fortes exclusivos. Fornecemos uma lista em ordem alfabética das principais ferramentas, juntamente com seus principais recursos, casos de uso ideais, informações sobre preços e até mesmo alguns trechos de análises de usuários. Quer seja um programador numa empresa em fase de arranque ou um líder de segurança numa empresa, encontrará uma solução DAST que se adequa às suas necessidades.

Em primeiro lugar, aqui está uma comparação das 5 principais ferramentas DAST gerais com base em recursos como verificação de API, integração CI/CD e precisão. Essas ferramentas são as melhores da categoria em uma variedade de necessidades, de desenvolvedores a equipes corporativas.

Acunetix da Invicti

O Acunetix by Invicti é um poderoso scanner de vulnerabilidades Web centrado na DAST, concebido para pequenas e médias empresas. Oferece uma análise rápida e automatizada de sites e APIs, com ênfase na facilidade de utilização e na rápida implementação. O Acunetix foi criado como um produto autónomo e faz agora parte da família de produtos da Invicti Security (complementando o scanner Invicti de nível empresarial). Constitui um excelente ponto de entrada para as equipas que iniciam o seu programa de segurança das aplicações.

Caraterísticas principais:

• Cobertura robusta de vulnerabilidades: Verifica mais de 7.000 vulnerabilidades conhecidas da Web, incluindo todos os problemas do OWASP Top 10, com verificações de SQLi, XSS, configurações incorretas, senhas fracas e muito mais.
• Varredura baseada em provas: Utiliza a tecnologia de prova de exploração proprietária de Invicti para verificar automaticamente muitas descobertas, reduzindo os falsos positivos. Por exemplo, pode confirmar com segurança injeções de SQL demonstrando uma amostra de extração de dados.
• Verificação de API e SPA: O Acunetix pode lidar com aplicações modernas - ele rastreia aplicações HTML5 de página única e pode testar APIs REST e GraphQL. Também suporta a importação de definições Swagger/OpenAPI para garantir uma cobertura completa da API.
• Integrações e CI/CD: Oferece integrações incorporadas com rastreadores de problemas (como Jira) e pipelines de CI/CD (Jenkins, GitLab CI, etc.) para permitir a automação em DevSecOps. As verificações podem ser acionadas em novas compilações e os resultados exportados como tickets de programador para loops de correção rápida.
• Conformidade e relatórios: Fornece relatórios de conformidade prontos para normas como OWASP Top 10, PCI DSS, HIPAA, ISO 27001 e muito mais - úteis para auditorias e demonstração de testes de segurança às partes interessadas.

Ideal para: Pequenas e médias empresas que procuram uma ferramenta DAST rápida e fácil de usar com mecanismo de varredura de nível empresarial. O preço da Acunetix é mais acessível do que algumas ferramentas de grandes empresas (licenças anuais, com opções para local ou nuvem).

‍Modelo de preços: Comercial, com edições baseadas no número de alvos; está disponível um teste gratuito de 14 dias.

Destaque da avaliação: "O Acunetix tem uma interface de utilizador intuitiva, é fácil de configurar e executar e produz resultados fiáveis. O modelo de licenciamento não é tão granular como poderia ser, o que significa que é necessário um planeamento para aumentar ou diminuir a escala." (Fonte: G2)

Segurança do Aikido

Aikido Security é uma plataforma de segurança de aplicações tudo-em-um, centrada no programador, que inclui um scanner DAST juntamente com outras ferramentas. O DAST do Aikido (denominado Monitorização de Superfície) simula ataques de caixa negra à sua aplicação Web para encontrar vulnerabilidades em tempo real. O que distingue o Aikido é a sua abordagem unificada - reúne DAST, SAST, análise de segurança de API, verificações de configuração na nuvem e muito mais numa única interface, proporcionando uma experiência perfeita tanto para os programadores como para as equipas de segurança. A plataforma é baseada na nuvem, com um generoso nível gratuito, tornando a segurança de nível empresarial acessível tanto a startups como a grandes empresas.

Caraterísticas principais:

• SAST unificado + DAST: O Aikido combina testes estáticos e dinâmicos - pode detetar problemas precocemente com o SAST e verificá-los em aplicações em execução com o DAST. Todos os resultados são canalizados para um painel de controlo para uma visibilidade holística da AppSec (caso de utilização conjunta de SAST e DAST).
• Fluxo de trabalho amigável ao desenvolvedor: Projetado para ser "segurança sem sentido para desenvolvedores". O Aikido integra-se com ferramentas de desenvolvimento (IDEs, pipelines CI/CD, GitHub/GitLab, alertas do Slack). Os desenvolvedores recebem feedback imediato - por exemplo, as descobertas do DAST podem aparecer como comentários de pull request ou resultados de pipeline, com links para sugestões de correção. Um usuário disse: "Com o Aikido, a segurança é apenas parte da forma como trabalhamos agora. É rápido, integrado e realmente útil para os desenvolvedores."
• Descoberta e análise automatizada de API: O mecanismo DAST inclui a descoberta automatizada de pontos de extremidade de API (REST e GraphQL) e examina-os em busca de vulnerabilidades. Isto é crucial, uma vez que as APIs acompanham frequentemente as aplicações Web modernas. O Aikido também pode iniciar sessão e testar áreas autenticadas, aumentando a cobertura da superfície de ataque da sua aplicação.
• Correção automática com recurso a IA: Uma caraterística de destaque - a plataforma Aikido pode gerar correcções com um clique para determinadas descobertas utilizando IA. Por exemplo, se o DAST encontrar um XSS refletido, a plataforma pode sugerir um patch de código ou uma alteração de configuração. Isto transforma as descobertas de segurança em tarefas acionáveis que os programadores podem resolver em segundos.
• Escalabilidade e integração na nuvem: Sendo um serviço na nuvem, o Aikido é escalável para analisar muitas aplicações continuamente. É adequado para a escala empresarial (acesso baseado em funções, painéis de equipa para utilização empresarial, etc.), mas também é muito acessível para equipas simples. A plataforma pode ser executada no seu CI, ou pode ativar análises a pedido através de uma simples interface Web ou API.

‍Melhorpara: Equipas de desenvolvimento que pretendem uma solução de segurança integrada e centrada no programador. O Aikido é ideal se você deseja incorporar o DAST ao ciclo de vida do desenvolvimento sem muita sobrecarga. É usado por startups (oferece planos especiais para startups) e empresas (consulte Recursos da empresa).

‍Modelo de preços: Nível gratuito para sempre (que inclui DAST, SAST e outros scanners principais para pequenos projetos) e planos pagos de taxa fixa para usuários adicionais ou recursos avançados. Você pode começar de graça sem um cartão de crédito, facilitando a avaliação.

Destaque da revisão: "Com o Aikido, podemos corrigir um problema em apenas 30 segundos - clicar num botão, fundir o PR e está feito." (Comentários de utilizadores sobre a correção automática)

Arachni

Arachni é uma estrutura de scanner de segurança de aplicações web de código aberto escrita em Ruby. É uma ferramenta DAST rica em funcionalidades que ganhou popularidade pela sua arquitetura modular e pelas suas capacidades de análise exaustiva. O Arachni pode ser utilizado como um scanner autónomo através da sua CLI ou interface Web, e é também uma estrutura que permite aos testadores de penetração criar scripts de módulos de scan personalizados. Embora o Arachni não esteja em desenvolvimento ativo (a última grande atualização foi em 2017), ele continua sendo uma opção poderosa para aqueles que desejam trabalhar com um projeto de código aberto e potencialmente estendê-lo.

Caraterísticas principais:

• Teste de Vulnerabilidade Extensivo: O Arachni cobre todas as vulnerabilidades críticas da Web - Injeção de SQL (incluindo técnicas cegas), XSS (refletido e armazenado), inclusão de ficheiros, injeção de comandos do SO, XXE, CSRF e muito mais. Realiza verificações activas (atacando entradas) e passivas (procurando fugas de informação, problemas de configuração, etc.).
• Modular e extensível: O scanner é altamente modular. Dezenas de módulos pré-construídos lidam com diferentes tipos de testes, e pode escrever os seus próprios em Ruby. Essa modularidade se estende às configurações de perfil e até mesmo à capacidade de distribuir varreduras. Para utilizadores avançados, o Arachni pode ser um conjunto de ferramentas para testes de penetração, e não apenas um scanner de botão de pressão.
• Opções GUI e CLI: O Arachni oferece uma interface de linha de comando para automação e uma GUI baseada em navegador para facilitar o uso. Os utilizadores menos experientes podem utilizar a IU da Web para configurar análises e visualizar relatórios, enquanto os utilizadores avançados podem integrar a CLI em scripts ou pipelines de CI.
• Relatórios detalhados: A ferramenta gera relatórios HTML detalhados com gráficos interactivos e análises detalhadas de vulnerabilidades. Os relatórios explicam cada problema, muitas vezes referenciando as descrições OWASP, e incluem passos para reproduzir e sugestões de correção. Este relatório foi considerado um dos pontos fortes do Arachni.
• Desempenho e automatização: Suporta a verificação multi-threaded e até pode ser configurado de forma distribuída para acelerar as verificações de grandes aplicações. Pode fazer uma pausa e retomar as verificações e adaptar o âmbito da verificação para visar domínios ou páginas específicos - útil em cenários de automatização.

Ideal para: Pesquisadores de segurança e pen-testers que querem um framework DAST gratuito e de código aberto para mexer. O Arachni também é educativo para aqueles que estão aprendendo como os scanners funcionam sob o capô. No entanto, observe: o desenvolvedor do Arachni interrompeu o desenvolvimento ativo, e o projeto não tem visto grandes atualizações desde 2017. Ele ainda funciona para muitos casos de uso (graças aos ajustes da comunidade) e pode encontrar muitas vulnerabilidades, mas pode não lidar com algumas tecnologias modernas (como os mais novos frameworks JavaScript) tão facilmente.

‍Modelo de preços: Gratuito e de código aberto (GPLv2). Os utilizadores devem planear uma curva de aprendizagem devido ao suporte oficial mínimo e à necessidade de possivelmente atualizar módulos para tecnologia de ponta.

Destaque da revisão: "Progride através de todos os testes críticos para o OWASP Top 10... Saída de relatório impressionante com explicações perspicazes. Contras: Não é atualizado desde 2017, não há suporte, o projeto foi abandonado." (Avaliação da Comparitech)

Conjunto para arrotar

O Burp Suite da PortSwigger é uma ferramenta lendária no mundo da segurança Web. Trata-se de uma plataforma integrada que suporta testes de segurança de aplicações Web manuais e automatizados. O Burp Suite é amplamente utilizado por testadores de penetração, caçadores de recompensas de bugs e profissionais de segurança. Funciona como um proxy de interceção (permitindo-lhe modificar o tráfego) e inclui um scanner automatizado (Burp Scanner) para DAST. As ferramentas modulares da suíte (Proxy, Scanner, Intruder, Repeater, etc.) fornecem um conjunto abrangente de ferramentas de hacking. O Burp Suite está disponível numa versão gratuita Community Edition e numa versão paga Professional Edition (com muito mais funcionalidades e velocidade).

Caraterísticas principais:

• Proxy de interceção: O núcleo do Burp é um proxy que intercepta solicitações e respostas HTTP/S. Isso permite que os testadores inspecionem e modifiquem o tráfego em tempo real. É inestimável para testes manuais - você pode manipular parâmetros, cabeçalhos, etc., e depois enviar solicitações para outras ferramentas Burp para testes adicionais.
• Scanner automatizado: O scanner DAST da Burp pode rastrear automaticamente uma aplicação e procurar vulnerabilidades. Ele reconhece mais de 300 tipos de vulnerabilidade prontos para uso, incluindo SQLi, XSS, CSRF, injeção de comando e outros. Com mais de 2500 casos e padrões de teste, é bastante completo. Os resultados do scanner incluem provas e orientações de correção.
• Extensibilidade (BApp Store): O Burp tem um extenso ecossistema de plugins. A BApp Store oferece extensões desenvolvidas pela comunidade que adicionam recursos - desde verificações de vulnerabilidade até a integração com outras ferramentas. Isso significa que você pode estender o Burp para verificar ameaças emergentes ou integrar-se a pipelines de desenvolvimento (há até um plug-in Burp CI, e o Burp Enterprise é um produto separado para automação).
• Ferramentas de teste manual: Além da verificação, o Burp Suite brilha com ferramentas como Intruder (para fuzzing automatizado/força bruta), Repeater (para criar e reproduzir solicitações individuais), Sequencer (para análise de token) e Decoder/Comparer. Estas permitem que os testadores especializados se aprofundem em problemas específicos que a verificação automatizada assinala.
• Integração CI/CD: Para DevSecOps, o PortSwigger oferece o Burp Suite Enterprise (uma edição separada), que foi projetado para executar varreduras em CI e em escala. Mas mesmo o Burp Pro pode ser usado em scripts via linha de comando ou API. Isso permite que as equipes incluam varreduras Burp como parte de seu pipeline (geralmente para aplicativos críticos ou para verificar novamente outros scanners).

Ideal para: Testadores de penetração e organizações com especialistas dedicados em AppSec. O Burp Suite Professional costuma ser a opção ideal para testes de segurança práticos devido à sua flexibilidade e profundidade. Para uma equipa de programadores, o Burp pode ser utilizado para verificar problemas específicos ou durante a modelação de ameaças e a depuração de correcções de segurança. A Community Edition é gratuita, mas tem limitações (varredura mais lenta, sem estado salvo). A licença Pro custa ~$449 por usuário por ano - "vale a pena para o testador sério", como observou um usuário do Reddit: "É a melhor e mais barata ferramenta do seu género. Vale bem o dinheiro". O scanner do Burp é potente, mas note que, por vezes, não detecta questões específicas da lógica empresarial - a perícia humana é o seu complemento pretendido.

Destaque da crítica: "Uma das melhores ferramentas proxy para caçadores de bugs e testadores de penetração. Não há nada que não se goste; todos os profissionais adoram-no." (Avaliação G2)

HCL AppScan Standard

O HCL AppScan Standard (anteriormente IBM AppScan) é uma ferramenta DAST baseada em ambiente de trabalho para utilizadores empresariais. Fornece um conjunto rico de funcionalidades para analisar aplicações Web, serviços Web e até mesmo alguns backends de aplicações móveis para detetar vulnerabilidades de segurança. O AppScan Standard faz parte do portefólio mais vasto do HCL AppScan (que também inclui o AppScan Enterprise, o AppScan on Cloud, ferramentas SAST, etc.). É conhecido pelas suas capacidades de análise profunda e é frequentemente utilizado por auditores de segurança e equipas de QA em grandes organizações.

Caraterísticas principais:

• Mecanismo de análise abrangente: O AppScan Standard utiliza algoritmos avançados de rastreio e teste para maximizar a cobertura de aplicações complexas. O seu rastreio "baseado em acções" pode lidar com aplicações de página única e código rico do lado do cliente. Também possui dezenas de milhares de casos de teste integrados que abrangem tudo, desde SQLi, XSS a falhas lógicas. Foi concebido para lidar com as aplicações Web mais complexas com sequências de início de sessão, fluxos de trabalho de vários passos e muito mais.
• Teste de API e back-end móvel: Para além das aplicações Web tradicionais, pode testar APIs Web (SOAP, REST) e backends móveis. Pode alimentá-lo com definições de API ou registar o tráfego móvel para auditar os pontos finais. Isto torna o AppScan útil para empresas com aplicações móveis que comunicam com serviços JSON/REST.
• Varreduras incrementais e otimizadas: Para maior eficiência, o AppScan permite a verificação incremental - testando novamente apenas as partes novas ou alteradas de um aplicativo, o que economiza tempo em testes de regressão. Também pode ajustar as definições de velocidade de análise vs. cobertura para se adequar a análises de desenvolvimento rápidas ou auditorias aprofundadas.
• Relatórios e conformidade: O AppScan Standard possui recursos robustos de geração de relatórios. Ele pode gerar uma variedade de relatórios, incluindo relatórios voltados para o desenvolvedor com recomendações de correção e resumos executivos. Em particular, oferece relatórios de conformidade e padrão do sector (PCI, HIPAA, OWASP Top 10, DISA STIGs, etc.), facilitando a demonstração da adesão aos requisitos de segurança.
• Integração empresarial: Embora o AppScan Standard seja um cliente autónomo, pode integrar-se com o AppScan Enterprise (para dimensionar análises numa equipa) e com pipelines de CI/CD através da execução da linha de comandos ou de APIs. A HCL também fornece plug-ins para ferramentas como Jenkins. Além disso, suporta a verificação autenticada com vários mecanismos (Basic, NTLM, form auth, etc.) e pode funcionar facilmente por detrás da firewall empresarial, uma vez que é executado no local.

Ideal para: Empresas e equipas de segurança que necessitam de uma poderosa solução DAST no local com amplas opções de configuração. Se você precisar de controle refinado sobre as varreduras, precisar testar aplicativos em um ambiente seguro offline ou tiver mandatos de conformidade, o AppScan é um forte candidato.

‍Modelo de preços: Comercial (preços empresariais). Normalmente, é licenciado por utilizador ou por instalação. A HCL também o oferece como parte das subscrições do AppScan on Cloud. Espere um preço mais elevado que se adeqúe ao seu conjunto de funcionalidades empresariais; recomenda-se formação para tirar o máximo partido do mesmo.

Contexto da análise: A longevidade do AppScan no mercado (desde os tempos da IBM) significa que foi experimentado e testado. Os utilizadores elogiam frequentemente a sua profundidade, mas notam que a IU e a configuração podem ser complexas. Se investir tempo, encontrará vulnerabilidades de forma fiável e produzirá os relatórios necessários para satisfazer os auditores.

Micro Focus Fortify WebInspect

O Micro Focus Fortify WebInspect (atualmente sob a alçada da OpenText, que adquiriu a Micro Focus) é uma ferramenta DAST de nível empresarial conhecida pela sua utilização em avaliações de segurança profundas e integração com o conjunto Fortify. O WebInspect fornece verificação dinâmica automatizada para aplicações e serviços da Web e é frequentemente utilizado juntamente com as ferramentas de análise estática (SAST) do Fortify para cobrir ambos os ângulos. Esta ferramenta tem um longo historial em AppSec e é preferida por organizações que requerem um scan on-premises e integração com programas de gestão de vulnerabilidades mais amplos.

Caraterísticas principais:

• Varredura automatizada completa: O WebInspect realiza análises rigorosas que podem identificar uma ampla gama de vulnerabilidades em aplicações web e APIs. Inclui verificações para OWASP Top 10, falhas de lógica de negócios e problemas de configuração do servidor. O scanner usa uma mistura de assinaturas e abordagens heurísticas para descobrir CVEs conhecidos, bem como problemas de dia zero (como casos extremos de tratamento de entrada incomum).
• Análise de JavaScript e do lado do cliente: Em versões recentes, o Fortify WebInspect melhorou a análise do código do lado do cliente. Ele pode executar JavaScript, lidar com aplicativos pesados AJAX e até mesmo capturar a comunicação de soquete da web durante as varreduras (a partir das atualizações 2024). Isto significa que os SPAs e as estruturas Web modernas podem ser auditados de forma mais eficaz.
• Integração do fluxo de trabalho empresarial: O WebInspect se integra ao ecossistema Fortify - por exemplo, os resultados podem fluir para o Fortify Software Security Center (SSC) para gerenciamento central, correlação com os resultados do SAST e atribuição de desenvolvedor. Ele também tem APIs e suporte para automação, portanto, pode ser conectado a pipelines de CI ou sistemas de orquestração de segurança. Muitas organizações de grande porte o utilizam em fluxos de trabalho de verificação programada para monitoramento contínuo.
• Varreduras autenticadas e com estado: A ferramenta suporta uma variedade de métodos de autenticação (incluindo técnicas multifatoriais, macros de login e autenticação baseada em OAuth/token). Pode manter o estado durante a verificação, o que é crucial para aplicações que requerem login e têm fluxos de utilizador complexos. O WebInspect também permite a gravação de macros para percorrer sequências específicas (como adicionar itens a um carrinho e depois fazer o check-out), garantindo que essas áreas sejam testadas.
• Relatórios e conformidade: O Fortify WebInspect fornece resultados técnicos detalhados para os programadores e relatórios resumidos para a gestão. Ele alinha as descobertas com os padrões e inclui relatórios de conformidade. Como é frequentemente utilizado em sectores regulamentados, oferece relatórios para satisfazer o PCI DSS, DISA STIG, OWASP e outras diretrizes prontas a utilizar.

Ideal para: Grandes empresas e organizações governamentais com requisitos de segurança rigorosos e implantações existentes do Fortify. O WebInspect é poderoso, mas orientado para especialistas em segurança - pode ser um exagero para uma equipa pequena. Ele se destaca quando integrado a um programa AppSec maduro (especialmente se o Fortify SAST também estiver em uso, criando uma imagem abrangente).

‍Modelo de preços: Comercial. Normalmente vendido como parte do conjunto de produtos Fortify (licenças bloqueadas por nó ou simultâneas). Os contratos de suporte garantem-lhe actualizações regulares das assinaturas de vulnerabilidade e melhorias do produto.

Nota: Após a aquisição da OpenText, o Fortify WebInspect está agora sob o portfólio da OpenText Cybersecurity. Por vezes é apenas referido como "OpenText Dynamic Application Security Testing (DAST)". O produto principal é o mesmo, continuando a tradição do WebInspect. Os utilizadores notaram que o WebInspect pode consumir muitos recursos e pode necessitar de afinação para evitar sobrecarregar algumas aplicações, mas é muito eficaz na descoberta de problemas complexos.

Nessus

O Nessus da Tenable é um dos scanners de vulnerabilidades mais reconhecidos no sector. Embora o Nessus seja muitas vezes considerado um scanner de rede, também efectua scans de aplicações Web (principalmente verificando vulnerabilidades conhecidas de aplicações Web, configurações incorrectas e fraquezas comuns). Não é um rastreador web completo como as ferramentas DAST dedicadas, mas está incluído aqui porque muitas equipas utilizam o Nessus para cobrir a segurança básica de aplicações web, para além dos rastreios de rede e sistema. O Nessus oferece uma ampla cobertura com uma enorme base de dados de plugins de verificações de vulnerabilidades.

Caraterísticas principais:

• Biblioteca de vulnerabilidades maciça: O Nessus tem mais de 99.000 CVEs na sua cobertura e mais de 250.000 verificações de plugins. Para aplicações Web, pode detetar coisas como versões desactualizadas de CMS (WordPress, Joomla, etc.), vulnerabilidades conhecidas em estruturas Web, configurações inseguras e a presença de ficheiros ou cópias de segurança predefinidos. É excelente para detetar problemas conhecidos e de baixo risco.
• Testes de aplicações Web: O Nessus inclui testes específicos da Web, como injeção de SQL, XSS, inclusão de ficheiros locais e passagem de diretórios - mas estes são geralmente baseados em assinaturas ou fuzzes simples. Pode, por exemplo, tentar alguns payloads genéricos de injeção SQL ou testar URLs de administração comuns. Também verifica o OWASP Top 10 de uma forma genérica. No entanto, não é tão adaptada à lógica de cada aplicação como uma ferramenta DAST dedicada.
• Facilidade de utilização: O Nessus é conhecido por ser fácil de utilizar. Pode analisar um IP ou URL com alguns cliques ou através da linha de comandos. Os relatórios são simples e as vulnerabilidades são classificadas por gravidade. Para um generalista de TI ou engenheiro de DevOps, o Nessus fornece uma forma unificada de analisar tanto os servidores como as aplicações Web neles existentes.
• Integração com a plataforma Tenable: O Nessus pode ser utilizado de forma autónoma (Nessus Professional) ou como parte do Tenable.io ou Tenable.sc (Security Center) para gestão empresarial. Quando integrados, os resultados do scan de aplicações Web passam a fazer parte do seu painel de gestão de vulnerabilidades global, correlacionando-se com as vulnerabilidades da rede. O Tenable.io Web App Scanning (produto separado, ver abaixo) utiliza de facto um motor diferente, mas o próprio Nessus também tem plugins Web.
• Atualizações contínuas: O Nessus recebe actualizações de plugins semanalmente (ou mais rapidamente para problemas críticos) da equipa de investigação da Tenable. Isso significa que é rápido obter verificações para os CVEs mais recentes (por exemplo, se um novo Apache Struts RCE for lançado, o Nessus geralmente tem um plug-in para detectá-lo em poucos dias). Este ciclo de atualização rápido é uma grande vantagem para se manter a par das ameaças emergentes.

Ideal para: Aumentar outras ferramentas para garantir uma cobertura abrangente. O Nessus é uma ótima ferramenta de "primeira passagem" - ele encontrará pontos fracos comuns e problemas conhecidos rapidamente. As organizações mais pequenas por vezes confiam apenas no Nessus para a análise de aplicações Web, mas a sua profundidade é limitada em comparação com as DAST especializadas. É ideal executar o Nessus ao lado de um scanner focado na web (como os acima) para capturar tudo.

‍Modelo de preços: O Nessus Essentials é uma versão gratuita (limita a 16 IPs, bom para pequenos projectos ou aprendizagem). O Nessus Professional é uma assinatura anual paga (cerca de US $ 2.790 / ano para varredura de IP ilimitada). Tenable.io (nuvem) e Security Center (no local) incluem scanners Nessus como parte dessas plataformas, licenciados por ativo. O Nessus é económico, uma vez que abrange mais do que apenas aplicações Web.

Destaque da crítica: "O Nessus tem uma das maiores bibliotecas de verificações de vulnerabilidades e configurações, cobrindo uma ampla gama de sistemas, dispositivos e aplicações. Embora o Nessus seja conhecido pelas suas capacidades abrangentes de verificação de vulnerabilidades, pode por vezes produzir falsos positivos...". (Na prática, os falsos positivos são normalmente baixos se o Nessus estiver corretamente configurado, mas, tal como a citação indica, pode ser necessário verificar manualmente alguns resultados).

Netsparker (Invicti)

A Netsparker (atualmente conhecida como Invicti) é um scanner de segurança automatizado de aplicações Web líder para ambientes empresariais. A Netsparker foi rebatizada para Invicti nos últimos anos, depois de a Invicti Security ter unificado os produtos Netsparker e Acunetix sob o mesmo teto. A Invicti (Netsparker) é conhecida pela sua exatidão - em particular, pela utilização da verificação baseada em provas para eliminar virtualmente os falsos positivos, confirmando efetivamente as vulnerabilidades. É um DAST completo que também inclui alguns elementos de teste interactivos para uma análise mais profunda.

Caraterísticas principais:

• Verificação baseada em provas: Invicti tenta automaticamente confirmar as vulnerabilidades explorando-as de uma forma segura. Por exemplo, se encontrar uma injeção de SQL, executará uma carga útil benigna que extrai uma amostra de dados para provar o problema. Isto produz uma precisão de análise de 99,98%, pelo que pode confiar nos resultados e gastar menos tempo a verificar manualmente os resultados.
• Amplo suporte tecnológico: Invicti pode analisar aplicações web tradicionais, SPAs com JavaScript pesado, e todos os tipos de APIs (REST, SOAP, GraphQL, gRPC). Ele lida efetivamente com estruturas modernas e inclui suporte para digitalizar tecnologias corporativas (ele pode navegar através de autenticação personalizada, lidar com tokens OAuth, etc.). Também tem a capacidade de testar corpos de pedidos JSON e envelopes SOAP para detetar falhas de injeção.
• Capacidades híbridas IAST: Invicti combina DAST com algum IAST (Interactive Application Security Testing) através da sua tecnologia Agent. Se você pode implantar um agente leve ao lado de seu aplicativo, o scanner pode instrumentar o aplicativo durante o tempo de execução para obter uma visão extra (como confirmar a linha exata de código para uma vulnerabilidade). Esta abordagem híbrida pode aumentar a cobertura e o detalhe sem exigir o acesso total ao código-fonte.
• CI/CD e Integração: Construído com a automação em mente, Invicti fornece opções de integração robustas - plugins para pipelines de CI (Jenkins, Azure DevOps, GitLab CI, etc.), integração com gestão de projectos e emissão de bilhetes (Jira, Azure Boards), e até mesmo ligação com WAFs para patching virtual instantâneo. Isto torna-o adequado para fluxos de trabalho DevSecOps onde é necessária uma verificação contínua.
• Escalabilidade e gestão: A plataforma pode ser dimensionada para analisar milhares de aplicações com agendamento, priorização e controlo de acesso baseado em funções para colaboração em equipa. Invicti também oferece um painel de controle multilocatário e recursos de descoberta de ativos (pode descobrir novos aplicativos da Web em seu ambiente para garantir que eles sejam verificados). É frequentemente utilizado como a espinha dorsal da gestão empresarial de vulnerabilidades das aplicações Web.

Ideal para: Empresas de médio a grande porte que precisam de uma solução DAST altamente precisa e escalável. As equipas de segurança que se sentem frustradas com falsos positivos ou que precisam de convencer os programadores a corrigir problemas consideram os resultados validados muito úteis ("o scanner provou que isto é real"). Invicti (Netsparker) é também uma escolha de topo para organizações com centenas de activos web para analisar rotineiramente.

‍Modelo de preços: Comercial - normalmente assinatura anual por site ou aplicativo verificado (uso ilimitado de verificação). Está na extremidade superior do espetro de preços, reflectindo o seu foco empresarial. Pode ser solicitada uma demonstração ou teste para o avaliar nas suas aplicações.

Destaque da análise: "O Invicti, que é o Netsparker, forneceu-me uma grande base de dados de vulnerabilidades para encontrar vulnerabilidades de execução remota, invalidação de domínios e muitos patches de vulnerabilidades... A verificação recorrente permite-me obter ficheiros a um nível de integridade." (G2 review). Em termos simples: os utilizadores apreciam a profundidade da cobertura de vulnerabilidades e a capacidade de agendar análises repetidas para detetar regressões. Alguns notam que a amplitude dos testes de Invicti (1400+ testes únicos) é enorme, embora certas caraterísticas avançadas possam exigir um ajuste fino.

Nikto

Nikto é um scanner clássico de servidor web de código aberto. É uma ferramenta simples mas eficaz que efectua verificações abrangentes de milhares de potenciais problemas em servidores Web. Nikto é uma ferramenta de linha de comando baseada em Perl, mantida pelo CIRT.net, e tem sido um elemento básico na caixa de ferramentas de segurança durante anos. Embora o Nikto não tenha a interface polida ou a lógica complexa dos scanners modernos, ele é muito útil para identificar rapidamente vulnerabilidades conhecidas e configurações inseguras.

Caraterísticas principais:

• Grande base de dados de cheques: A Nikto pode testar mais de 7.000 ficheiros/CGIs potencialmente perigosos e configurações num servidor Web. Isto inclui verificações de ficheiros predefinidos (como páginas de administração, scripts de instalação), aplicações de amostra, cópias de segurança de configurações (*.antigo, *.bak ficheiros), e outros artefactos que os atacantes normalmente procuram. Ele também detecta versões desatualizadas de mais de 1.250 servidores e componentes de software, além de problemas específicos de versão para mais de 270 produtos de servidor.
• Verificações de configuração do servidor: O Nikto não procura apenas por vulnerabilidades de aplicações web; ele examina as informações do servidor. Por exemplo, ele informará se a indexação de diretórios está ativada, se métodos HTTP como PUT ou DELETE são permitidos (o que pode permitir a invasão de upload de arquivos), ou se certos cabeçalhos HTTP inseguros estão presentes/ausentes. É uma ótima auditoria rápida do fortalecimento do servidor web.
• Rápido e sem frescuras: O Nikto não é furtivo - foi concebido para funcionar o mais rapidamente possível e será ruidoso nos registos. Isso é bom para varreduras autorizadas. Ele é acionado por linha de comando, então você pode alimentá-lo com uma lista de hosts ou usá-lo em scripts facilmente. Executar nikto -h <hostname> produzirá uma lista de problemas identificados em texto simples.
• Opções de saída: Pode guardar os resultados em vários formatos (texto simples, XML, HTML, NBE, CSV, JSON), o que é útil se pretender alimentar outras ferramentas ou sistemas de relatórios com os resultados. Muitas pessoas usam o Nikto como parte de um conjunto de ferramentas maior, analisando seus resultados para sinalizar certas descobertas.
• Extensibilidade: Embora não seja tão modular como outros, é possível personalizar o comportamento do Nikto. Ele suporta plugins (seu banco de dados de verificações é essencialmente um conjunto de plugins). Você pode atualizar suas assinaturas, e ele é frequentemente atualizado pela comunidade com novas verificações. Além disso, ele suporta as técnicas anti-IDS da LibWhisker se você tentar se esconder (embora, por padrão, ele seja barulhento).

Ideal para: Varreduras rápidas para encontrar problemas conhecidos e como um complemento para varreduras mais profundas. O Nikto é adorado por muitos testadores de penetração para um reconhecimento inicial de um servidor Web alvo. Se for um programador ou administrador de sistemas, pode executar o Nikto no seu site para detetar problemas óbvios (e muitas vezes é revelador). No entanto, não encontrará falhas lógicas complexas nem nada que exija o rastreio do JavaScript - não é esse tipo de ferramenta. Pense no Nikto como uma lista de verificação automatizada para configurações erradas e vulnerabilidades comuns da Web.

‍Modelo de preços: Gratuito, de código aberto (GPL). Está incluído em distribuições de segurança como o Kali Linux e pode ser usado sem qualquer restrição de plataforma (script Perl). O suporte é baseado na comunidade (fóruns, GitHub).

Dica profissional: Como o Nikto é passivo em termos de lógica (sem login, sem rastreamento pesado), ele é muito rápido. Você pode integrar o Nikto em um pipeline de CI para uma varredura rápida de cada compilação (para garantir, digamos, que nenhum ponto de extremidade de depuração tenha sido implantado acidentalmente). Embora ele possa relatar algumas descobertas de nível "informativo" que não são verdadeiras vulnerabilidades, ele proporciona a tranquilidade de saber que você não deixou algo óbvio por aí.

OWASP ZAP

O OWASP ZAP (Zed Attack Proxy) é uma ferramenta DAST gratuita e de código aberto mantida no âmbito do projeto OWASP. É uma das ferramentas DAST mais populares devido ao seu custo (gratuito), comunidade aberta e funcionalidade rica. O ZAP é tanto um proxy para testes manuais como um scanner automatizado. É frequentemente considerado a alternativa de código aberto ao Burp Suite para quem tem um orçamento limitado, e é uma opção fantástica para os programadores e as pequenas empresas começarem a efetuar testes de segurança sem obstáculos de aquisição.

Caraterísticas principais:

• Verificação ativa e passiva: O ZAP efectua uma verificação passiva, observando o tráfego que passa por ele (através do seu proxy ou spider) e assinalando problemas, e uma verificação ativa, em que injecta ativamente ataques assim que descobre páginas. O modo passivo é ótimo para um início suave (não modifica nada, apenas observa coisas como fugas de informação ou cabeçalhos de segurança), enquanto a verificação ativa encontra os verdadeiros erros (SQLi, XSS, etc.) atacando a aplicação.
• Proxy e ferramentas de teste manual: Como o Burp, o ZAP pode funcionar como um proxy de intercetação. Também tem uma série de ferramentas: um proxy de interceção HTTP, um spider para rastrear conteúdos, um fuzzer para atacar entradas e uma consola de scripts (com suporte para escrever scripts em Python, Ruby, etc. para estender o ZAP). O modo Heads-Up Display (HUD) permite-lhe até sobrepor informações de rastreio no topo do seu browser enquanto navega - muito útil para programadores que estão a aprender segurança.
• Automação e API: O ZAP foi criado com a automação em mente para a integração de QA. Tem uma API poderosa (REST e uma API Java) que lhe permite controlar todos os aspectos do ZAP. Muitas equipas utilizam a API do ZAP em pipelines de CI - por exemplo, iniciar o ZAP em modo daemon, fazer spidering a um alvo, executar um scan ativo e depois obter os resultados - tudo automatizado. Existem até mesmo ações prontas do GitHub e plug-ins do Jenkins para o ZAP. Isso o torna uma boa opção para DevSecOps com um orçamento apertado.
• Extensibilidade através de add-ons: O ZAP tem um mercado de add-ons (o ZAP Marketplace) onde pode instalar add-ons oficiais e da comunidade. Eles incluem regras de verificação especializadas (para JSON, XML, SOAP, WebSockets, etc.), integrações ou recursos convenientes. A comunidade actualiza constantemente as regras de rastreio, incluindo regras alfa/beta para tipos de vulnerabilidades emergentes. Isso mantém os recursos de verificação do ZAP em evolução.
• Comunidade e suporte: Sendo OWASP, tem uma forte comunidade de utilizadores. Existe uma grande quantidade de documentação, vídeos de formação gratuitos e fóruns activos. Embora não se obtenha suporte comercial (a menos que se use consultores de terceiros), o conhecimento existente muitas vezes rivaliza com o suporte do fornecedor. O ZAP também é atualizado regularmente pelos seus líderes de projeto e colaboradores.

Ideal para: Equipas de desenvolvimento, organizações preocupadas com o orçamento e como ferramenta de aprendizagem. O OWASP ZAP é ideal para os programadores entrarem nos testes de segurança ("shift-left"). Também é utilizado por profissionais em conjunto com o Burp para uma perspetiva adicional. Se for uma startup, o ZAP dá-lhe uma capacidade DAST com custo zero de licenciamento, o que é uma enorme vantagem.

Destaque da crítica: "A ferramenta OWASP é gratuita, o que lhe confere uma grande vantagem, especialmente para as empresas mais pequenas utilizarem a ferramenta." peerspot.com. Este sentimento é comum - o ZAP reduz a barreira de entrada para a segurança na Web. Pode não ter caraterísticas de topo de gama como alguns scanners comerciais, mas para muitos casos de utilização, faz o trabalho de forma eficaz.

Qualys Web Application Scanner (WAS)

Qualys Web Application Scanning (WAS) é uma oferta DAST baseada na nuvem da Qualys, integrada ao seu QualysGuard Security and Compliance Suite. Qualys WAS aproveita a plataforma Qualys na nuvem para fornecer um serviço de scan on-demand para aplicações web e APIs. É particularmente atrativo para as empresas que já utilizam Qualys para a verificação de vulnerabilidades de rede ou de conformidade, uma vez que estende esse painel único de controlo às aplicações web. Qualys WAS é conhecido pela sua escalabilidade (scanning de milhares de sites) e pela sua facilidade de utilização através de um modelo SaaS.

Caraterísticas principais:

• Baseado na nuvem e escalável: Qualys WAS é entregue como um serviço - executa scans a partir de Qualys Cloud contra os seus alvos (com a opção de usar aparelhos de scan distribuídos para aplicações internas). Isto significa que não há despesas de manutenção para a ferramenta em si e a capacidade de executar muitos scans em paralelo. A plataforma já descobriu e analisou mais de 370 mil aplicações web e APIs, o que demonstra a sua ampla utilização.
• Ampla cobertura de vulnerabilidades: Detecta vulnerabilidades, incluindo as OWASP Top 10 (SQLi, XSS, CSRF, etc.), configurações incorrectas, exposição de dados sensíveis (por exemplo, números de cartões de crédito em páginas) e até infeção por malware em sítios Web. Também verifica coisas como a exposição inadvertida de PII ou segredos em páginas Web. A Qualys utiliza alguma IA/ML (aprendizagem automática) na sua análise para melhorar a deteção de problemas complexos e reduzir os falsos positivos (de acordo com o seu marketing).
• Teste de segurança de API: Qualys WAS cobre também o OWASP API Top 10. Pode importar ficheiros OpenAPI/Swagger ou colecções Postman e testar minuciosamente as API REST. Ele monitora o "desvio" das especificações da API - ou seja, se a sua implementação não corresponder ao arquivo Swagger (o que poderia indicar endpoints não documentados), o Qualys pode sinalizá-lo. Isso é ótimo para gerenciar a segurança da API.
• Integração e DevOps: Qualys fornece uma extensa API para todos os seus produtos, incluindo WAS. É possível automatizar análises, extrair relatórios e até mesmo integrar resultados em rastreadores de defeitos. Eles também têm um plug-in para o Chrome (Qualys Browser Recorder) para gravar sequências de autenticação ou fluxos de trabalho do utilizador que podem ser carregados para o Qualys WAS para verificar as partes de uma aplicação que requerem login. Além disso, os resultados do Qualys WAS podem alimentar o seu WAF (se utilizar o Qualys WAF) para uma rápida correção virtual.
• Conformidade e Relatórios: Uma vez que Qualys é grande em conformidade, WAS é capaz de gerar relatórios necessários para atender a PCI DSS 6.6 (requisito de varredura de vulnerabilidades de aplicações web) e outras políticas. Todas as descobertas são consolidadas na interface Qualys, que pode ser partilhada com outros módulos, como as suas ferramentas de gestão de vulnerabilidades ou de gestão de riscos. Este relatório unificado é uma vantagem para a gestão.

Ideal para: Empresas que utilizam uma plataforma de segurança baseada na nuvem e desejam consolidar a verificação. Se já utiliza o Qualys para outras verificações de segurança, adicionar o WAS é fácil para cobrir as aplicações Web. Também é uma boa opção se quiser uma solução totalmente gerida (SaaS) e não quiser executar scanners no local. Como o Qualys lida com atualizações, você sempre terá as últimas melhorias de digitalização sem levantar um dedo.

‍Modelo de preços: O Qualys WAS é baseado em subscrição, normalmente licenciado por aplicação web (com níveis baseados no número de aplicações ou IPs verificados). A Qualys é frequentemente vendida em pacotes (por exemplo, um pacote que inclui gestão de vulnerabilidades + WAS). Existe uma versão de avaliação gratuita disponível e a Qualys tende a ser orientada para as empresas em termos de preços (não é a mais barata, mas obtém uma plataforma robusta).

Nota do sector: O Qualys WAS foi líder no GigaOm Radar 2023 para testes de segurança de aplicativos. Os usuários citam sua conveniência na nuvem e o benefício do monitoramento contínuo. Por outro lado, alguns acham a interface do usuário um pouco ultrapassada e a configuração inicial (como scripts de autenticação) tem uma curva de aprendizado. Ainda assim, é uma escolha muito sólida com o apoio da Qualys.

Rapid7 InsightAppSec

O Rapid7 InsightAppSec é uma solução DAST baseada na nuvem que faz parte da plataforma Insight da Rapid7. O InsightAppSec centra-se na facilidade de utilização e integração, tornando os testes dinâmicos acessíveis tanto às equipas de segurança como aos programadores. Aproveita a experiência que a Rapid7 tem (de produtos como o Metasploit e as suas ferramentas de gestão de vulnerabilidades) para fornecer um scanner que pode lidar com aplicações Web modernas, incluindo aplicações de página única e APIs. Como um serviço em nuvem, elimina a necessidade de gerenciar a infraestrutura do scanner.

Caraterísticas principais:

• Cobertura de aplicativos da Web modernos: O InsightAppSec pode testar aplicativos Web tradicionais, bem como SPAs criados em estruturas como React ou Angular. Ele tem a capacidade de executar JavaScript e rastrear conteúdo gerado dinamicamente. Ele também lida com HTML5 e padrões da web mais recentes. A Rapid7 salienta que pode proteger tudo, desde formulários HTML antigos a aplicações modernas do lado do cliente.
• Mais de 95 tipos de ataque: O scanner inclui mais de 95 tipos de ataque no seu repertório, abrangendo vectores comuns e complexos. Isto inclui os suspeitos do costume (SQLi, XSS) e também coisas como injeção de CRLF, SSRF e outras falhas menos comuns na Web. Dá prioridade às descobertas com base no risco para o ajudar a concentrar-se no que é importante.
• UX simplificada: O InsightAppSec foi projetado com uma interface de usuário amigável. A configuração de uma verificação é simples - forneça um URL, informações de login opcionais e pronto. A interface guia os utilizadores menos experientes através da configuração. Uma vez concluídas as análises, os resultados são explicados com conselhos de correção e informações úteis para os programadores. Também possui recursos como reprodução de ataques (para verificar uma descoberta reproduzindo a solicitação específica que a expôs).
• Verificação paralela e sem tempo de inatividade: Como é baseado na nuvem, pode executar vários exames em simultâneo sem se preocupar com os recursos locais. Isto é ótimo para analisar várias aplicações ou multitarefas (o Rapid7 refere que pode analisar muitos alvos sem tempo de inatividade da parte deles). Esta escalabilidade é útil para agências ou grandes organizações que analisam muitas aplicações Web.
• Integração e Ecossistema: O InsightAppSec integra-se com a plataforma Rapid7 Insight mais alargada. Por exemplo, pode enviar vulnerabilidades para o InsightVM (a sua gestão de vulnerabilidades) ou gerar bilhetes no Jira. Ele também pode se integrar aos pipelines de CI e tem uma API para automação. Além disso, se utilizar o Rapid7 InsightConnect (SOAR), pode automatizar acções DAST (como ativar um exame quando uma nova aplicação é implementada, etc.).

Ideal para: Organizações que desejam um DAST baseado em nuvem com uma interface intuitiva e fortes recursos de integração. Se já é cliente da Rapid7 (utilizando o InsightIDR, InsightVM, etc.), a adição do InsightAppSec será natural e os dados podem fluir entre os produtos. Também é uma boa escolha para equipes que podem não ter um especialista dedicado em AppSec - a abordagem amigável reduz a barreira de habilidade para executar varreduras.

‍Modelo de preços: SaaS comercial. O Rapid7 geralmente licencia o InsightAppSec por aplicativo ou alvos, geralmente em pacotes. Eles geralmente o agrupam com seus outros produtos para uma solução de segurança mais holística. Está disponível uma avaliação gratuita e são oferecidas demonstrações guiadas. Nas análises, algumas PMEs mencionam que o preço é razoável para o valor, enquanto que uma utilização muito grande pode tornar-se mais cara (típico para SaaS quando se aumenta para centenas de aplicações).

Destaque da avaliação: "Utilizámos a Rapid7 para os nossos testes de vulnerabilidade e... Eles provaram ser inestimáveis no fornecimento de uma solução completa e eficaz". Os utilizadores elogiam frequentemente o apoio da Rapid7 e a polidez geral da plataforma. Uma potencial desvantagem mencionada é que, por vezes, a correção de erros no produto pode ser lenta, mas as novas funcionalidades e melhorias são lançadas regularmente.

Tenable.io Análise de aplicações Web

Tenable.io Web App Scanning é a oferta DAST dedicada da Tenable dentro de sua plataforma de nuvem Tenable.io. Enquanto o Nessus (abordado anteriormente) pode fazer algumas verificações na Web, o Tenable.io WAS é uma solução criada especificamente para testar dinamicamente as aplicações Web e beneficia de um motor e de uma interface mais modernos. A Tenable posiciona-o como um scanner fácil de usar, mas abrangente, muitas vezes atraente para os clientes que já usam o Tenable.io para gerenciamento de vulnerabilidades.

Caraterísticas principais:

• Plataforma unificada: Tenable.io WAS vive ao lado de outros serviços da Tenable (como Tenable.io Vulnerability Management, Container Security, etc.) para que todos os resultados sejam acessíveis num único painel. Para as equipas de segurança, este "painel de controlo único" para vulnerabilidades de infra-estruturas e da Web é conveniente. Pode ver as vulnerabilidades das aplicações Web em contexto com as vulnerabilidades da rede, acompanhar as pontuações de risco dos activos e gerir tudo em conjunto.
• Facilidade de implementação: Sendo um produto SaaS, pode iniciar uma análise com apenas alguns cliques. Tenable.io WAS pode digitalizar aplicações web externas out-of-the-box. Para aplicações internas, pode implementar um dispositivo de scanner Tenable que irá efetuar a verificação e enviar um relatório para a nuvem. A configuração é simples e a Tenable fornece modelos para verificações rápidas em vez de verificações profundas.
• Rastreio e auditoria automatizados: O scanner rastreia automaticamente a aplicação para criar um mapa do sítio e, em seguida, audita cada página/formulário que encontra. Testa pontos de injeção e vulnerabilidades comuns. A Tenable tem vindo a melhorar o motor de análise para lidar com aplicações Web modernas (como o processamento de JS). Embora não seja tão badalado no marketing como alguns concorrentes, na prática cobre a maioria das vulnerabilidades padrão e tem verificações específicas para coisas como DOM XSS e ataques baseados em JSON.
• Resultados rápidos e varreduras incrementais: Tenable.io WAS enfatiza o valor rápido - pode fornecer resultados acionáveis em minutos para problemas comuns. Também foi concebido para a verificação contínua - pode agendar verificações semanais ou mensais, e suporta a verificação incremental (apenas testando conteúdo novo ou alterado) para reduzir o tempo de verificação em execuções subsequentes. Isto é útil para ambientes de desenvolvimento ágil com lançamentos frequentes.
• Integração e DevOps: Tenable.io tem uma API, para que possa ativar scans de aplicações web de forma programática ou integrar com CI/CD. Também existem integrações para enviar as descobertas para sistemas de emissão de bilhetes. Se utilizar a Infraestrutura como Código, pode até criar um ambiente de teste, analisá-lo com o Tenable.io WAS através da API e depois destruí-lo - porta de segurança totalmente automatizada em pipelines de CI (alguns utilizadores avançados fazem isto).
• Complementar ao Nessus: A Tenable sugere frequentemente a utilização conjunta do Nessus e do WAS - o Nessus para verificações de rede e básicas da Web, e o WAS para testes mais profundos de aplicações Web. Se já gere as verificações do Nessus em Tenable.io, adicionar WAS é perfeito. Os painéis de controlo podem mostrar pontuações de risco combinadas, etc. A análise da Tenable (com o Tenable Lumin) pode então dar prioridade aos problemas em todos os tipos de activos de forma consistente.

Ideal para: Para quem pretende a DAST num contexto mais alargado de gestão de vulnerabilidades. Se a sua gestão de vulnerabilidades AppSec e NetSec são geridas por uma equipa, o Tenable.io WAS permite-lhes utilizar um conjunto de ferramentas. Também é adequado para equipas que pretendem uma solução DAST relativamente simples - não é necessário ser um guru da segurança Web para a executar, pois é bastante automatizada. No entanto, aplicações extremamente complexas podem necessitar de ajustes e, nesses casos, algumas outras ferramentas podem oferecer um controlo mais manual.

‍Modelo de preços: O Tenable.io WAS é baseado em assinatura, geralmente por aplicativo ou URL. A Tenable pode agrupá-lo com a licença da plataforma Tenable.io. Por exemplo, você pode obter um determinado número de alvos WAS incluídos se já for um cliente Tenable.io. Geralmente, o preço é competitivo em relação a outras soluções SaaS DAST empresariais.

Nota: A Tenable tem investido no WAS para se manter a par da concorrência; em 2024, adicionou suporte para coisas como gravar sequências de início de sessão mais facilmente e melhorar a verificação de aplicações de página única. Os utilizadores comentam que é "simples, escalável e automatizado " - alinhando-se com a mensagem da Tenable de fornecer DAST abrangente sem muito incómodo. É uma boa ferramenta "polivalente".

Wapiti

Wapiti é um scanner de vulnerabilidades web gratuito e de código aberto escrito em Python. O nome Wapiti vem de uma palavra nativa americana para alce - apropriado, uma vez que é ágil e poderoso no seu domínio. O Wapiti funciona como um scanner "black-box": não precisa de código-fonte; limita-se a fazer fuzzing na sua aplicação Web através de pedidos HTTP, tal como um DAST típico. É uma ferramenta de linha de comando que é especialmente popular entre os entusiastas do código aberto e é conhecida por ser mantida ativamente (com actualizações recentes que adicionam novos módulos de vulnerabilidade).

Caraterísticas principais:

• Abordagem Black-Box Fuzzing: O Wapiti rastreia a aplicação web alvo para encontrar URLs, formulários e entradas e, em seguida, lança ataques injectando cargas úteis para testar vulnerabilidades. Abrange uma vasta gama de falhas de injeção: Injeção de SQL (erro, booleano, baseado no tempo), injeção XPath, scripting entre sítios (refletido e armazenado), inclusão de ficheiros (local e remoto), injeção de comandos OS, ataques XML External Entity (XXE) e muito mais. Essencialmente, se houver um campo de entrada, o Wapiti tentará quebrá-lo.
• Módulos para várias vulnerabilidades: Conforme listado no seu site, os módulos do Wapiti tratam de tudo, desde as vulnerabilidades clássicas da Web a verificações como injeção de CRLF, redireccionamentos abertos, SSRF através de um serviço externo (pode testar se o SSRF é possível utilizando um sítio Web externo do Wapiti como captador), deteção de HTTP PUT (para ver se o WebDAV está ativado) e até verificações de vulnerabilidades como Shellshock em scripts CGI. Esta amplitude é impressionante para uma ferramenta gratuita.
• Autenticação e delimitação do âmbito: O Wapiti suporta a exploração autenticada através de vários métodos: Básico, Digest, NTLM e autenticação baseada em formulário (pode fornecer-lhe credenciais ou um cookie). Ele também permite restringir o escopo - por exemplo, você pode dizer a ele para ficar dentro de um determinado domínio ou pasta, o que é útil para evitar atacar links de terceiros ou subdomínios que você não possui. Também pode excluir URLs específicos, se necessário.
• Geração de relatórios: Emite resultados em vários formatos (HTML, XML, JSON, TXT, etc.). O relatório HTML é útil para uma consulta rápida, enquanto o JSON é útil se pretender analisar ou fundir resultados de forma programática. Os relatórios listam cada vulnerabilidade encontrada com detalhes como o pedido HTTP que foi utilizado para a explorar, o que é ótimo para os programadores reproduzirem e corrigirem.
• Facilidade de utilização e manutenção: O Wapiti é fácil de instalar (disponível via pip) e executar (wapiti -u <url> inicia uma pesquisa). É bastante rápido e pode ajustar o número de pedidos simultâneos. É importante notar que o Wapiti é mantido ativamente - a última versão (em meados de 2024) adicionou novas funcionalidades e vulnerabilidades. Os responsáveis pelo projeto mantêm-no atualizado à medida que surgem novas explorações (como CVEs recentes), o que resolve um problema comum em que os scanners de código aberto ficam para trás. O facto de ser Python significa que também é fácil de ajustar, se assim o desejar.

Ideal para: Desenvolvedores e pentesters que preferem ferramentas de código aberto e controle de linha de comando. O Wapiti é uma escolha sólida para integrar em scripts ou pipelines de CI para uma pilha de segurança de código aberto. Pode exigir um pouco mais de esforço prático (sem GUI, instalação manual), mas a recompensa é nenhum custo de licenciamento e total transparência no que está a fazer. Também é leve, então você pode executá-lo em um contêiner Docker ou trabalho de CI sem grandes necessidades de recursos.

‍Modelo de preços: Gratuito (GPL v2). O único custo é o seu tempo para aprender e possivelmente contribuir com atualizações.

O amor da comunidade: O Wapiti pode não ser tão famoso como o ZAP, mas os utilizadores que o descobrem elogiam frequentemente a sua eficácia. É como uma joia escondida para fuzzing automatizado de aplicações web. Como ele não vem com uma GUI, é menos intimidante integrá-lo para aqueles que se sentem confortáveis com a CLI. Além disso, suas atualizações (como a adição da deteção Log4Shell no final de 2021) mostram que ele se adapta a eventos de segurança significativos. Se você estiver montando um kit de ferramentas AppSec de código aberto, Wapiti + ZAP juntos cobrem muito terreno.

w3af

O w3af (Web Application Attack and Audit Framework) é uma estrutura abrangente de código aberto para encontrar e explorar vulnerabilidades de aplicações Web. Muitas vezes apelidado de "Metasploit para aplicações Web", o w3af fornece capacidades de análise e exploração de vulnerabilidades num único pacote. Está escrito em Python e tem interfaces gráficas e de consola. Embora seja um projeto mais antigo, continua a ser uma das ferramentas de segurança Web de código aberto mais completas disponíveis.

Caraterísticas principais:

• Sistema extensivo de plugins: o w3af funciona com uma arquitetura baseada em plugins. Tem dezenas de plug-ins de auditoria que testam vulnerabilidades específicas (SQLi, XSS, CSRF, estouro de buffer, etc.), plug-ins de rastreamento para descobrir páginas (incluindo um que analisa JavaScript para encontrar URLs) e plug-ins de ataque para tentar explorar os problemas encontrados. Pode ajustar exatamente quais os plugins a executar ou apenas utilizar um perfil que ativa um conjunto deles. Esta modularidade significa que o w3af pode ser configurado para verificações rápidas, auditorias completas ou compromissos orientados para a exploração.
• Verificação e exploração: O w3af não só encontra vulnerabilidades, como também tem uma componente de exploração. Por exemplo, se encontrar injeção de SQL, tem ferramentas para tirar partido disso (como extrair dados, tal como o sqlmap faria). Se encontrar inclusão de ficheiros, pode tentar obter uma shell remota. Isto torna-o útil para os investigadores de segurança que querem ir além da simples deteção e demonstrar efetivamente o impacto.
• GUI e interface de consola: Há uma GUI baseada em GTK (embora seu visual seja um pouco ultrapassado) que fornece uma maneira mais amigável de configurar verificações e visualizar resultados. A consola é bastante poderosa e permite acções de scripting num ambiente pseudo-shell (pode utilizar comandos para definir alvos, plugins, etc., semelhante à consola do Metasploit). Isto serve tanto para os recém-chegados como para os utilizadores avançados.
• Combinação de análise estática e dinâmica: O w3af pode realmente realizar alguma análise estática do código se lhe for dado acesso direto (através dos seus plugins de auditoria de código), mas é principalmente dinâmica. Também tem plugins de grepping que inspeccionam as respostas HTTP em bruto para coisas como números de cartões de crédito, números da segurança social, mensagens de erro - produzindo informações que podem não ser uma vulnerabilidade por si só, mas que são relevantes para a segurança. Esta abordagem holística distingue-o dos scanners que apenas se concentram em vulnerabilidades diretas.
• Código aberto e extensível: O projeto é de código aberto ao abrigo da GPL. Embora o ritmo das actualizações tenha abrandado, o conhecimento existente nos seus plugins é considerável. Como é Python, os utilizadores podem modificar os plugins ou escrever novos para alargar as suas capacidades. Existe também uma documentação rica (o sítio w3af docs) e até uma API para o controlar, embora a maioria utilize o CLI ou a GUI.

Ideal para: Profissionais de segurança e amadores que desejam um kit de ferramentas gratuito que faça a ponte entre a varredura e a exploração. É particularmente útil em cenários de testes de penetração - pode analisar com o w3af para encontrar problemas e depois explorá-los sem problemas para confirmar o impacto. Para uma equipa de desenvolvimento que procura uma análise rápida, o w3af pode parecer um pouco pesado ou complexo em comparação com o ZAP ou o Wapiti. Mas para quem está disposto a investir tempo, pode ser muito gratificante. Modelo de preços: Gratuito, de código aberto. Não há versão comercial.

Nota de precaução: o w3af, sendo poderoso, pode ser potencialmente perigoso - por exemplo, os seus plugins de exploração podem alterar dados. É melhor utilizá-lo em ambientes de teste/estágio ou com permissão explícita em produção (e com uma seleção cuidadosa de plugins). O principal programador do projeto, Andres Riancho, mudou-se para outros empreendimentos há alguns anos (é conhecido por contribuir para muitas ferramentas de segurança), mas o w3af continua a ser uma ferramenta indispensável em muitos kits de ferramentas de hackers. Pode exigir alguma resolução de problemas para funcionar em sistemas operativos modernos (por vezes, o inferno das dependências), mas uma vez instalado, tem um canivete suíço para a segurança das aplicações web.

Tendo abordado as principais ferramentas individualmente, vamos agora dividir as recomendações por casos de utilização específicos. Equipas diferentes têm necessidades diferentes - um programador pode dar prioridade à facilidade de integração, enquanto um CISO de uma empresa pode valorizar a escalabilidade e o suporte. As secções abaixo fornecem escolhas personalizadas para vários cenários.

Melhores ferramentas DAST para programadores

Público-alvo: Desenvolvedores e engenheiros de DevOps que desejam detetar bugs de segurança antecipadamente e integrar testes em seu fluxo de trabalho. Estes utilizadores valorizam as ferramentas que são fáceis de utilizar, não sobrecarregam com falsos positivos e integram-se em ambientes de desenvolvimento (IDEs, CI/CD, etc.). Muitas vezes, podem não ter conhecimentos profundos de AppSec, pelo que a ferramenta deve fornecer orientação e automatização.

Ao escolher uma ferramenta DAST como programador, considere:

• Integração com CI/CD e IDEs: A ferramenta liga-se ao seu pipeline de construção ou fornece um plug-in IDE? Os testes de segurança automatizados no CI ajudam a detetar problemas antes da fusão. Algumas plataformas (como a segurança CI/CD do Aikido) fazem isso sem problemas.
• Baixo nível de falsos positivos e ruído: Os programadores não têm tempo para andar atrás de fantasmas. As ferramentas que validam os resultados (por exemplo, Invicti) ou que têm uma elevada precisão são preferidas para que, quando um erro é assinalado, valha a pena corrigi-lo.
• Resultado acionável: Procure scanners que ofereçam conselhos claros de correção ou até mesmo exemplos de código para corrigir o problema. Melhor ainda, algumas ferramentas focadas em desenvolvimento fornecem correções automatizadas ou pull requests (o AI Autofix do Aikido, por exemplo, pode gerar patches para determinados problemas).
• Velocidade e digitalizações sob demanda: Num ambiente de desenvolvimento, as verificações mais rápidas permitem um feedback rápido. As ferramentas que podem analisar alterações incrementais ou URLs específicos (em vez de toda a aplicação de cada vez) ajudam a integrar o ciclo de desenvolvimento iterativo.
• Custo (para indivíduos ou pequenas equipas): As opções gratuitas ou económicas são atractivas, especialmente em organizações sem um orçamento dedicado à segurança. As ferramentas ou serviços de código aberto com níveis gratuitos enquadram-se bem neste caso.

Principais ferramentas para programadores:

• Segurança do Aikido - Tudo-em-um amigável para os programadores: O Aikido foi criado a pensar nos programadores. Integra-se em fluxos de trabalho de código (verificações de PR, falhas de pipeline em vulnerabilidades elevadas) para que os programadores obtenham feedback imediato. O modelo "Start for Free" da plataforma e a facilidade de configuração (execução na nuvem, sem infraestrutura para gerenciar) significam que um desenvolvedor pode adicionar DAST ao seu projeto em minutos. Também consolida os resultados com o SAST, para que possa ver tudo num só local, reduzindo a mudança de contexto. Para um programador, ter um único painel de controlo para ver e corrigir problemas de segurança é uma enorme poupança de tempo. Além disso, as sugestões de correção automática significam que mesmo os menos familiarizados com a segurança podem resolver os problemas com confiança.
• OWASP ZAP - Código aberto e programável: O ZAP é uma ótima opção para desenvolvedores porque é gratuito e altamente flexível. Você pode executá-lo em um modo daemon no CI, usar a API do ZAP para automatizar varreduras ou até mesmo usar o ZAP HUD para testar interativamente seu aplicativo durante o desenvolvimento. Muitas equipes de desenvolvimento configuram varreduras noturnas do ZAP em seu ambiente de desenvolvimento e enviam os resultados para o Slack ou o Jira para que os desenvolvedores possam lidar com eles na manhã seguinte. A curva de aprendizado é moderada, mas o OWASP fornece muitos tutoriais. E como é gratuito, é fácil de experimentar. A comunidade do ZAP também significa que, se tiver dificuldades, a ajuda está provavelmente à distância de uma pesquisa no Google.
• Suíte Burp (Community/Pro) - Adjunto de testes manuais: Para automação pura, o Burp não é a primeira escolha para desenvolvedores, mas a Community Edition gratuita é uma ferramenta útil para ser executada durante o desenvolvimento. Os programadores podem fazer proxy do tráfego local das suas aplicações através do Burp para ver o que se passa debaixo do capô. O scanner do Burp na versão Pro pode ser usado sob demanda para verificar áreas específicas de um aplicativo (como "Eu criei um novo login OAuth, deixe-me verificar apenas essa parte"). Também é educativo - usar o Burp ensina muito ao desenvolvedor sobre segurança na Web. Se o orçamento permitir, a verificação automatizada do Burp Pro pode ser integrada ao CI usando sua CLI, dando aos desenvolvedores um poderoso portão de segurança.
• StackHawk - CI/CD Integrated DAST: (Menção honrosa) StackHawk é uma ferramenta DAST mais recente, voltada especificamente para desenvolvedores e DevOps. Ela é construída sobre o mecanismo ZAP, mas empacotada de uma forma que está pronta para o pipeline. Você define as configurações de teste em um arquivo YAML, e ele é executado sem cabeça no CI. Embora o StackHawk não esteja na nossa lista principal acima, vale a pena mencioná-lo para casos de uso de desenvolvimento devido ao seu foco em ser "amigável ao CI". Ele também tem um nível gratuito para um único aplicativo, o que é ótimo para projetos individuais ou aplicativos de código aberto.
• Wapiti - Verificações rápidas da CLI: Para os programadores que gostam de ferramentas de linha de comandos e que talvez queiram incluir uma verificação de segurança rápida na sua compilação, o Wapiti é uma boa opção. Pode executar wapiti como parte do seu conjunto de testes (talvez contra uma instância de teste local da aplicação). Ele não vai pegar tudo, mas é rápido e vai sinalizar problemas óbvios. Pense nisso como uma ferramenta de linting para segurança em seu CI: leve e sem necessidade de GUI.

Porquê estas: Estas ferramentas realçam a fácil integração, a rapidez dos resultados e a acessibilidade. Permitem aos programadores "deslocarem-se para a esquerda" em matéria de segurança - identificando e corrigindo vulnerabilidades durante o desenvolvimento, muito antes de o código chegar à produção. Utilizando-os, os programadores podem melhorar a segurança de forma iterativa, tal como fazem com a qualidade do código através de testes unitários. A aprendizagem obtida com a interação com estas ferramentas (especialmente as interactivas como o ZAP ou o Burp) também melhora as competências dos programadores em matéria de segurança, o que é um benefício oculto mas valioso.

A tabela abaixo compara as ferramentas DAST mais adequadas para desenvolvedores que precisam de feedback rápido, fácil integração CI/CD e relatórios de baixo ruído.

Melhores ferramentas DAST para empresas

Público-alvo: Empresas com grandes carteiras de aplicações Web e equipas de segurança dedicadas. Muitas vezes, necessitam de ferramentas que possam ser dimensionadas para centenas de aplicações, fornecer acesso baseado em funções, relatórios de conformidade e integração em fluxos de trabalho empresariais (sistemas de bilhética, governação, etc.). O suporte e a fiabilidade são fundamentais, e existe orçamento disponível para soluções robustas.

Considerações sobre as ferramentas DAST empresariais:

• Escalabilidade e gestão: A ferramenta deve permitir a análise de muitas aplicações (possivelmente em simultâneo), com gestão centralizada de horários de análise, resultados e permissões de utilizador. As consolas empresariais ou os ambientes multiutilizadores são importantes (por exemplo, HCL AppScan Enterprise ou a plataforma Invicti).
• Integrações empresariais: A integração com sistemas como SIEMs, plataformas GRC, rastreadores de defeitos (Jira, ServiceNow) e gerenciamento de identidade (suporte SSO) é frequentemente necessária. Além disso, acesso à API para integração personalizada na cadeia de ferramentas DevSecOps da empresa.
• Conformidade e relatórios: As empresas precisam frequentemente de gerar documentação de conformidade. As ferramentas que podem produzir relatórios detalhados para PCI, SOC2, ISO27001, etc., e acompanhar a conformidade das políticas ao longo do tempo acrescentam muito valor. A capacidade de marcar activos (por unidade de negócio, nível de risco, etc.) e obter análises (tendências, SLAs sobre a correção de vulnerabilidades) é útil para a gestão.
• Suporte e formação: Ter um fornecedor que ofereça um forte apoio (engenheiros de apoio dedicados, serviços profissionais) e formação é um fator importante. As ferramentas empresariais vêm com SLAs para questões de suporte. Para as ferramentas de código aberto, isto é uma lacuna - razão pela qual as grandes empresas se inclinam para as opções comerciais, apesar do custo.
• Cobertura abrangente: As empresas não se podem dar ao luxo de perder coisas. Idealmente, a ferramenta deve abranger não só as vulnerabilidades normais da Web, mas também aspectos como os testes de lógica empresarial, ou fornecer formas de alargar os testes. Algumas empresas utilizam várias ferramentas DAST para colmatar as lacunas, mas é preferível utilizar uma única ferramenta robusta para maior eficiência.

Principais ferramentas para empresas:

• Invicti (Netsparker) - Precisão e escala: A plataforma da Invicti é feita sob medida para uso empresarial. Oferece suporte a vários utilizadores, etiquetagem de activos e pontuação de risco em milhares de análises. As empresas adoram a verificação baseada em provas que reduz drasticamente os falsos positivos - o que melhora o sinal-ruído quando se tem um grande número de descobertas. Invicti pode também integrar-se com a bilhética da empresa (atribuindo automaticamente os problemas encontrados à equipa de desenvolvimento correta através da integração Jira, por exemplo). O seu painel de controlo fornece uma visão geral da postura de segurança de todas as aplicações, que a gestão pode utilizar para obter métricas. Para uma empresa, o custo inicial compensa o facto de ter uma solução madura e silenciosa que pode ser a espinha dorsal do seu programa AppSec.
• HCL AppScan (Standard/Enterprise) - Poder legado da empresa: Muitas organizações de grande dimensão (bancos, seguros, governo) utilizam o AppScan há anos (da IBM à HCL). O AppScan Enterprise permite um servidor de gestão centralizado onde podem ser orquestradas várias análises AppScan Standard e os resultados podem ser agregados. Suporta acesso baseado em funções, pelo que as equipas de desenvolvimento podem iniciar sessão e ver os resultados apenas para as suas aplicações, enquanto as equipas de segurança obtêm uma visão geral. O relatório de conformidade é uma grande vantagem. Além disso, para empresas preocupadas com a segurança dos dados, o AppScan pode ser executado inteiramente no local (sem dependência da nuvem), o que às vezes não é negociável em setores como defesa ou saúde.
• Micro Focus Fortify WebInspect - Integração profunda com SDLC: As empresas que já investiram no ecossistema da Fortify (para SAST, etc.) encontrarão o WebInspect se encaixando naturalmente. As varreduras do WebInspect podem ser publicadas no Fortify SSC, que atua como um repositório centralizado de descobertas estáticas e dinâmicas. Isto permite a correlação cruzada e o acompanhamento unificado dos esforços de correção. A Fortify também oferece produtos adicionais, como o Fortify Application Defender (RASP), que pode usar os resultados do WebInspect para instrumentar e proteger aplicativos em tempo de execução - uma sinergia valorizada pelas empresas que colocam suas defesas em camadas. Além disso, o fornecedor (agora OpenText) oferece serviços profissionais e formação certificada para o WebInspect, o que é importante para o reforço de grandes equipas.
• Qualys WAS - Escala na nuvem e descoberta de activos: As grandes empresas com infra-estruturas distribuídas apreciam o Qualys pela sua facilidade de utilização na nuvem e pelas suas capacidades de descoberta de activos. Qualys WAS pode descobrir continuamente novas aplicações web num ambiente (usando coisas como scans de rede, enumeração de nomes de domínio, etc.), o que é ótimo para empresas que podem nem sequer ter um inventário completo dos seus activos web (um problema comum). Depois, permite-lhe integrar rapidamente as aplicações descobertas no scanning. A escalabilidade da Qualys está comprovada - algumas empresas executam dezenas de milhares de análises por ano na sua plataforma. O aspeto multi-tenant também funciona para configurações empresariais (por exemplo, unidades de negócio separadas podem ter vistas separadas).
• Tenable.io WAS - Gestão de risco unificada: Para as empresas que querem unificar o risco de aplicações e redes, a integração do WAS da Tenable.io com a gestão de vulnerabilidades é apelativa. Os CISOs podem obter uma única pontuação de risco para uma aplicação que considera tanto os seus vulns da Web (do WAS) como os vulns da infraestrutura do servidor (do Nessus). A abordagem da plataforma também simplifica a gestão de utilizadores e a elaboração de relatórios. O suporte empresarial da Tenable é sólido e ajuda frequentemente os grandes clientes a integrar e a ajustar as análises para minimizar os problemas de desempenho (importante quando se analisam aplicações de produção críticas na empresa).
• Segurança Aikido - Plataforma DevSecOps empresarial: Embora o Aikido seja relativamente novo em comparação com alguns players antigos, ele oferece uma proposta de valor interessante para empresas que buscam modernizar o AppSec. Como ele combina várias ferramentas (SAST, DAST, configuração de nuvem, etc.), ele pode reduzir a expansão de ferramentas em uma empresa. A plataforma é baseada na nuvem, mas oferece opções no local (para conformidade). As empresas obtêm funcionalidades como a integração SSO, a gestão de equipas e a capacidade de gerir milhares de projectos. Uma vantagem é que os programadores gostam realmente de a utilizar (de acordo com o design centrado nos programadores), o que pode aumentar a adoção em ambientes empresariais onde conseguir a adesão dos programadores é meio caminho andado. O Aikido pode ser uma boa opção para as empresas que adoptam o DevSecOps em grandes equipas, garantindo que a segurança é integrada em todas as fases (código, construção, implementação, monitorização) de uma forma unificada.

Porquê estes: Elas atendem aos requisitos empresariais de escala, suporte e integração. Em grandes organizações, uma ferramenta DAST que possa analisar 500 aplicações e gerar um relatório executivo que mostre "reduzimos a contagem de vulnerabilidades OWASP Top 10 em 20% neste trimestre" é ouro. Ferramentas como Invicti, Qualys, etc., fornecem esses tipos de métricas e roll-ups. Além disso, as empresas precisam frequentemente de analisar aplicações internas atrás de firewalls - são necessárias ferramentas com motores de análise no local (como os scanners Qualys ou instalações WebInspect no local), o que todas as opções acima fornecem.

‍

‍

Melhores ferramentas DAST para empresas em fase de arranque

Público: As empresas em fase de arranque e as pequenas empresas têm frequentemente um orçamento e pessoal de segurança limitados. Precisam de ferramentas económicas e fáceis de utilizar que forneçam valor rapidamente. Muitas vezes, o foco é conseguir uma linha de base de segurança para satisfazer as preocupações dos clientes ou investidores (e talvez cumprir a conformidade se lidarem com dados sensíveis), sem descarrilar o ritmo de desenvolvimento rápido.

Principais necessidades das empresas em fase de arranque numa ferramenta DAST:

• Acessibilidade: Soluções gratuitas ou de baixo custo, ou ferramentas com níveis gratuitos que abrangem pequenas aplicações, são ideais. As empresas em fase de arranque também podem considerar o código aberto para evitar custos recorrentes.
• Simplicidade: Pode não haver um engenheiro de segurança dedicado, pelo que os programadores ou DevOps executarão os exames. A ferramenta deve ser fácil de configurar (de preferência SaaS para evitar infra-estruturas) e fácil de interpretar.
• Ganhos rápidos: As startups beneficiam de ferramentas que encontram rapidamente os problemas mais críticos (por exemplo, configurações incorrectas comuns, vulnerabilidades evidentes) - essencialmente uma verificação de sanidade. Podem não precisar do scanner mais exaustivo; algo que apanhe os itens de alto risco é muitas vezes suficiente numa fase inicial.
• Integração com o fluxo de trabalho de desenvolvimento: As startups têm frequentemente um desenvolvimento moderno e ágil. As ferramentas que se integram com GitHub Actions ou similares podem ajudar a automatizar a segurança sem um processo pesado.
• Escalabilidade (à prova de futuro): Embora não seja um requisito fundamental, uma ferramenta que possa crescer com eles (mais aplicações, mais análises) é um bónus, para que não tenham de mudar de ferramenta à medida que crescem. Mas, numa fase inicial, o custo pode sobrepor-se a isto.

Principais ferramentas para empresas em fase de arranque:

• OWASP ZAP - Gratuito e fiável: Para uma startup com pouco dinheiro, é difícil superar a gratuidade. O ZAP pode ser o scanner inicial a ser executado em seu aplicativo da Web. Muitas startups usam o ZAP de forma semi-automatizada: por exemplo, como parte de suas compilações noturnas ou apenas como uma verificação mensal por um desenvolvedor. O facto de ser de código aberto também significa que, se crescerem, a sua equipa de segurança pode personalizá-lo profundamente. O investimento em aprendizagem no ZAP continua a compensar. Prós: sem custo direto, grande comunidade, boa eficácia para vulnerabilidades comuns. Contras: requer algum esforço prático e aprendizagem.
• Segurança do Aikido - Nível gratuito & All-in-One: Aikido oferece um plano gratuito para sempre que é extremamente atrativo para as startups. Com ele, uma empresa em fase de arranque pode obter não só o DAST, mas também o SAST e outros scanners numa única plataforma - é muito valor sem custos, até uma determinada utilização. Para uma empresa jovem, utilizar o Aikido significa que não tem de fazer malabarismos com várias ferramentas; obtém um aumento imediato da segurança em toda a sua pilha. Além disso, a ênfase do Aikido na automatização e na facilidade significa que, mesmo sem um especialista em segurança, os programadores da empresa em fase de arranque podem geri-la. À medida que a startup cresce, podem atualizar sem problemas dentro dos planos do Aikido, o que é uma boa proteção para o futuro.
• Acunetix (da Invicti) - Opção para PMEs: O Acunetix é comercial, mas é especificamente comercializado para organizações mais pequenas e tem um preço inferior ao das ferramentas empresariais. Uma startup com um pouco de orçamento e talvez um requisito de conformidade pode optar pelo Acunetix porque é simples e tem suporte. Pode ser instalado localmente ou executado a partir da sua nuvem, e analisará rapidamente a aplicação e produzirá um relatório polido (útil se a startup precisar de mostrar um relatório a um cliente empresarial como parte da devida diligência). É basicamente um "aparelho DAST" que simplesmente funciona. Algumas empresas em fase de arranque utilizam uma única licença Acunetix na sua equipa de desenvolvimento e efectuam análises ocasionalmente para garantir que não existem falhas óbvias.
• Fundamentos do Nessus - Scanner de vulnerabilidades gratuito: Uma startup pode utilizar o Nessus Essentials (gratuito para 16 alvos) para analisar o seu anfitrião de aplicações Web. Embora o Nessus não seja um testador de aplicações Web específico, detecta problemas de configuração do servidor Web (problemas de SSL, software desatualizado) e algumas vulnerabilidades Web comuns. Não é abrangente para a aplicação em si, mas como uma verificação rápida, é valioso. E se o produto da startup também incluir serviços de rede, o Nessus cobre-os. Essencialmente, é uma boa ferramenta de "varredura ampla" para a higiene geral da segurança. Muitas empresas em fase de arranque utilizam o Nessus porque a versão gratuita é suficiente para uma aplicação Web e alguns servidores.
• Suíte Burp Comunidade - Aprendizagem e pesquisa manual: Se a equipa fundadora tiver uma inclinação técnica, ter a Burp Community à disposição para analisar manualmente a sua aplicação pode ser muito educativo. É gratuito e, embora o scanner esteja desativado na edição comunitária, ainda é possível intercetar tráfego e utilizar o intruder para testar alguns formulários. Alguns desenvolvedores de startups usam o Burp para testar funcionalidades críticas (como login, formulários de pagamento) manualmente. Isso não é automatizado ou escalável, mas para um aplicativo pequeno, algumas horas com o Burp podem revelar erros graves (como verificações de autenticação inadequadas). É rentável na medida em que é gratuito, exigindo apenas tempo.

Porquê estes: Não custam nada ou cabem facilmente no orçamento de uma empresa em fase de arranque e não requerem um especialista a tempo inteiro para funcionar. O objetivo de uma empresa em fase de arranque é evitar ser o fruto mais fácil - a utilização destas ferramentas pode detetar os problemas mais evidentes (credenciais predefinidas, pontos finais de administração abertos, injecções de SQL, etc.) e aumentar drasticamente a postura de segurança com um investimento mínimo. Além disso, mostrar que utiliza ferramentas reconhecidas como o OWASP ZAP ou o Nessus pode aumentar a confiança quando o inevitável questionário de segurança vier de um potencial cliente.

‍

‍

Melhores ferramentas DAST gratuitas

Público-alvo: Qualquer pessoa que pretenda melhorar a segurança das suas aplicações Web sem gastar dinheiro. Isto inclui programadores amadores, estudantes, pequenas organizações ou mesmo grandes empresas que estejam a experimentar antes de comprar uma solução. "Gratuito" neste contexto pode significar versões completamente de código aberto ou de nível gratuito de produtos comerciais.

As opções DAST gratuitas têm normalmente algumas limitações (quer em termos de funcionalidades, suporte ou profundidade de digitalização), mas oferecem um valor incrível para as necessidades básicas.

Critérios/caraterísticas das melhores ferramentas gratuitas:

• Sem custos, sem compromissos: Utilização verdadeiramente gratuita (e não apenas uma breve avaliação). Idealmente de código aberto ou apoiado pela comunidade.
• Eficácia: Mesmo que seja gratuita, a ferramenta deve encontrar um número significativo de vulnerabilidades. A base de referência abrange os 10 principais problemas do OWASP.
• Suporte da comunidade: As ferramentas gratuitas dependem frequentemente de fóruns da comunidade, documentação e actualizações. Uma comunidade vibrante garante que a ferramenta continue a ser útil.
• Facilidade de utilização vs. curva de aprendizagem: Algumas ferramentas gratuitas são prontas a utilizar, enquanto outras requerem conhecimentos. Apresentamos uma lista de várias: algumas que "funcionam" e outras que podem necessitar de mais conhecimentos (para quem estiver disposto a investir tempo em vez de dinheiro).

Principais ferramentas DAST gratuitas:

• OWASP ZAP: Destaca-se como provavelmente a ferramenta DAST gratuita com mais recursos. Como discutido, o ZAP pode fazer muito, e tudo de graça. É efetivamente a sugestão a seguir quando alguém pergunta, "Não tenho orçamento, como é que faço DAST?" O ZAP tem uma comunidade ativa e até mesmo suporte formal da OWASP. É continuamente atualizado e pode ser alargado. Para uma solução gratuita, não há nada melhor do que o ZAP em termos de capacidade e tamanho da comunidade.
• Nikto: Completamente livre e aberto, o Nikto concentra-se em problemas conhecidos. É muito fácil de executar - basicamente uma verificação com um comando - o que o torna acessível. O valor do Nikto está na sua simplicidade: não se configura muito, basta executá-lo e obter resultados. Ele é ótimo para auditorias rápidas por pessoas que podem não ser especialistas em segurança (por exemplo, um administrador de sistemas pode executar o Nikto em um servidor como parte de uma lista de verificação). Como se baseia em assinaturas, não detectará problemas personalizados, mas, como ferramenta gratuita, oferece uma boa rede de segurança.
• Wapiti: O Wapiti é gratuito e de código aberto, e é surpreendentemente poderoso, rivalizando com alguns scanners comerciais em testes de injeção. Talvez seja menos conhecido na maioria das pessoas, mas os membros da comunidade de segurança de código aberto respeitam-no. Para alguém disposto a usar um terminal e potencialmente criar scripts em torno dele, o Wapiti fornece uma tremenda capacidade de varredura sem nenhum custo. O seu desenvolvimento ativo significa que está a acompanhar os novos tipos de vulnerabilidades, o que nem sempre acontece com as ferramentas gratuitas.
• w3af: Também gratuito e de código aberto, o w3af é mais complexo, mas oferece tanto a análise como a exploração. É como uma alternativa gratuita ao Burp Suite Pro (mais ou menos). No entanto, os utilizadores devem ter em atenção que não tem estado muito ativo ultimamente. Ainda assim, para uma solução sem custos, o w3af pode aprofundar e até explorar problemas, o que outros não fazem. É melhor para utilizadores com algum conhecimento de segurança que pretendam um kit de ferramentas único.
• Arachni: O Arachni é gratuito (open-source) e foi um peso pesado no seu tempo. Ainda funciona bem em muitos cenários. Dado que não é mantido ativamente, deve ser utilizado com precaução em tecnologia de ponta, mas como scanner gratuito, é completo em tecnologias Web mais antigas. Se tiver uma aplicação que não envolva os SPAs mais recentes, o Arachni pode ser muito eficaz e tem uma boa interface de relatório. Pelo preço de zero, obtém-se um relatório de análise com aspeto profissional.
• Suíte Burp Community Edition: Embora o scanner completo não esteja ativado na edição gratuita, incluí-o porque permite o scanner passivo e o teste manual. É gratuito e é uma óptima ferramenta de formação. Muitos entusiastas da segurança começam com o Burp Community para aprender como funcionam as vulnerabilidades, intercetar tráfego, etc. Se fizer proxy da sua aplicação através da Burp Community durante a navegação, esta assinalará passivamente alguns problemas (como cabeçalhos de segurança em falta ou valores reflexivos que possam sugerir XSS). Portanto, tecnicamente, ele faz algum trabalho DAST de graça, embora limitado.

Nota: Muitos agentes comerciais oferecem testes gratuitos (como o teste de 14 dias do Acunetix ou uma análise gratuita limitada do Qualys, etc.), mas essas não são soluções sustentáveis. Por isso, prefiro ferramentas gratuitas a longo prazo, não limitadas no tempo.

Porquê estes: Cobrem o básico (e mais) sem qualquer barreira financeira. As ferramentas gratuitas são cruciais para democratizar a segurança - permitem que qualquer pessoa teste as suas aplicações. As empresas com orçamento zero ainda podem melhorar a sua postura de segurança utilizando-as. Recomenda-se frequentemente a utilização de várias ferramentas gratuitas em combinação, uma vez que cada uma pode detetar coisas que as outras não detectam. Por exemplo, execute Nikto + ZAP + Wapiti em conjunto - se as três concordarem que uma aplicação está "limpa", é provável que tenha resolvido os problemas óbvios. Tudo isto sem gastar um cêntimo.

Melhores ferramentas DAST de código aberto

Público-alvo: Entusiastas da segurança, organizações empenhadas em soluções de código aberto ou aqueles que pretendem total transparência e controlo sobre a ferramenta. As ferramentas de código aberto também são preferidas por instituições de ensino e por empresas com regras de aquisição rigorosas que preferem software auditado pela comunidade.

"Código aberto" sobrepõe-se a "gratuito", mas aqui referimo-nos especificamente a ferramentas cujo código-fonte está disponível e que são normalmente mantidas por uma comunidade (muitas vezes sob a OWASP ou organizações semelhantes). A vantagem é que pode auditar o código do scanner, personalizá-lo e confiar que não existe nenhum comportamento oculto na caixa negra.

Principais ferramentas DAST de código aberto (com um pouco de repetição das anteriores):

• OWASP ZAP: Campeão do código aberto. O código fonte do ZAP está no GitHub e tem inúmeros colaboradores. Muitas empresas até mesmo fazem um fork do ZAP para criar regras de verificação personalizadas para suas necessidades específicas. Estando sob a governação da OWASP, tem credibilidade e um processo de desenvolvimento aberto claro. Se precisar de um DAST OSS, o ZAP é normalmente a escolha nº 1.
• w3af: Totalmente de código aberto (GPL). Um utilizador pode ler como cada plugin funciona, modificá-los ou escrever novos. Isto é ótimo para investigadores que querem adicionar uma verificação para uma nova vulnerabilidade globalmente. É como ter os blocos de construção de um scanner que podem ser montados novamente. A natureza de código aberto do w3af também significa que você pode integrá-lo em estruturas de segurança de código aberto maiores.
• Wapiti: Alojado no GitHub e ativamente atualizado pelos seus mantenedores, o Wapiti convida a contribuições e relatórios de erros dos utilizadores. Se achar que a sua aplicação desencadeia falsos positivos ou se descobrir um novo tipo de vulnerabilidade, pode adicionar módulos ao Wapiti. O código aberto também significa que você pode integrar o Wapiti a outros sistemas abertos (como conectá-lo a um pipeline de CI/CD de código aberto).
• Nikto: Um dos mais antigos scanners web de código aberto. A sua base de dados de assinaturas é abertamente editável, e as pessoas contribuem frequentemente com novas verificações. Se, por exemplo, for descoberta uma nova vulnerabilidade de uma aplicação web numa estrutura popular, qualquer pessoa pode adicionar um teste Nikto para essa vulnerabilidade e partilhá-lo. A simplicidade do código do Nikto (principalmente scripts Perl) significa que mesmo aqueles com habilidades modestas de codificação podem personalizá-lo para seu ambiente. Nesse sentido, ele é realmente voltado para a comunidade.
• Arachni: Código aberto (embora atualmente sem manutenção). A sua base de código estava bem escrita e algumas pessoas bifurcaram-na ou reutilizaram partes dela noutros projectos. Como código aberto, serve também como referência de aprendizagem - os novos programadores de DAST podem estudar o design do Arachni.
• OWASP ZAP( menção honrosa): Destaco isso porque, além do núcleo do ZAP, o mercado de complementos está cheio de contribuições de código aberto. Ferramentas como o add-on GraphQL Scanner, add-on SOAP scanner, etc., são todas de código aberto. Este ecossistema significa que se o ZAP não fizer algo hoje, um plugin de código aberto pode aparecer amanhã para preencher a lacuna. Nenhuma ferramenta de código fechado tem essa agilidade impulsionada por uma comunidade global.

Porquê código aberto? A segurança é muitas vezes uma questão de confiança. Com a DAST de código aberto, pode inspecionar exatamente que testes estão a ser feitos e como os dados são tratados (importante se estiver a analisar aplicações sensíveis - sabe que a ferramenta não está a desviar dados, por exemplo, porque pode ver o código). Também significa que se a ferramenta não se adequar perfeitamente às suas necessidades, tem o poder de a alterar. As organizações que estão dispostas a investir esforços de engenharia em vez de dinheiro podem criar soluções DAST muito personalizadas a partir destes projectos.

Melhores ferramentas DAST para DevSecOps

Público-alvo: Equipas que praticam DevSecOps - ou seja, que integram verificações de segurança em pipelines de integração contínua e entrega contínua, com um elevado grau de automatização e colaboração entre desenvolvimento, segurança e operações. Estas equipas pretendem ferramentas que possam ser executadas sem cabeça, que produzam resultados legíveis por máquina e que possam, eventualmente, bloquear as compilações com base em critérios de segurança. Elas também costumam preferir ferramentas que possam ser "deslocadas para a esquerda" (usadas no início pelos desenvolvedores), bem como continuamente na pós-produção.

Factores importantes para o DevSecOps DAST:

• Integração CI/CD: A ferramenta deve ter uma API CLI ou REST e, idealmente, plug-ins para sistemas de CI populares (Jenkins, GitLab CI, GitHub Actions, Azure DevOps, etc.). Deve ser fácil de rodar como parte de um pipeline (versões em contêineres ajudam aqui).
• Saída amigável para automação: Resultados em formatos como JSON ou SARIF que podem ser consumidos por outros sistemas para tomada de decisão automatizada. Por exemplo, interromper a compilação se forem encontradas novas vulnerabilidades de alta gravidade - isso requer a análise automática da saída do scanner.
• Varreduras incrementais ou rápidas: As varreduras completas da DAST podem ser lentas, o que é um desafio para a CI. As ferramentas que oferecem modos mais rápidos ou permitem visar componentes específicos (talvez por meio da marcação de pontos de extremidade importantes) são úteis. Outra abordagem é a integração com conjuntos de testes - por exemplo, atacar o aplicativo enquanto os testes de integração são executados (algumas configurações avançadas fazem isso).
• Flexibilidade de ambiente: O DevSecOps pode criar ambientes de teste efémeros (por exemplo, implementar uma ramificação de uma aplicação num servidor de teste, analisá-la e, em seguida, eliminá-la). As ferramentas DAST que podem facilmente apontar para URLs dinâmicos e lidar com ambientes em constante mudança sem muita configuração manual brilham aqui.
• Loops de feedback: Um ideal DevSecOps é o feedback imediato para os programadores. Assim, uma ferramenta DAST que pode comentar um pedido pull, ou abrir tickets automaticamente, ou fazer ping no chat com resultados promove essa cultura de feedback rápido.

Principais ferramentas/abordagens para DevSecOps:

• Segurança Aikido - Automação de pipelines: O Aikido foi concebido para ser incorporado em pipelines de CI (com a sua funcionalidade de integração CI/CD). Pode configurar as análises do Aikido para serem executadas em cada fusão ou implementação. Os seus resultados podem ser definidos para falhar as compilações se os limites de gravidade forem ultrapassados. O fato de que ele também faz SAST significa que os desenvolvedores obtêm um golpe duplo de análise estática e dinâmica em CI, tudo gerenciado a partir de uma plataforma. Além disso, a natureza em nuvem do Aikido significa que você não precisa gerenciar a infraestrutura de varredura em seus executores de CI; basta chamar o serviço do Aikido. Isso reduz o atrito de adicionar DAST aos pipelines.
• OWASP ZAP (Dockerizado) - O cavalo de batalha do DevOps: O ZAP fornece uma imagem oficial do Docker e até mesmo um script de verificação de linha de base configurável. Isso é muito usado em DevSecOps. Por exemplo, você pode ter uma ação do GitHub que executa owasp/zap-baseline-scan contra um site de teste implantado por 5 minutos e relata os resultados. A API do ZAP também permite muita automação personalizada, e a comunidade escreveu wrappers (como scripts Python) que integram o ZAP ao CI. Como é gratuito, é possível executá-lo em quantos pipelines forem necessários. Existem muitos tutoriais sobre "ZAP em Jenkins" ou similares, indicando que é um padrão comum.
• StackHawk - Criado especificamente para CI: StackHawk (embora comercial) é basicamente DAST para DevOps. Integra-se com pipelines usando uma abordagem de configuração como código. Para as equipas DevSecOps que têm orçamento para isso, o StackHawk suaviza algumas arestas da utilização do ZAP na CI (o StackHawk é construído com base no ZAP, mas tem uma melhor experiência de utilizador e suporte para o programador). Vale a pena notar que o DevSecOps é exatamente o seu caso de utilização alvo. Ele produz em formatos amigáveis para CI e a empresa enfatiza que o DAST não diminui a CI (com orientação de ajuste).
• Invicti/Acunetix - Plugins de CI: As lojas DevSecOps empresariais que utilizam Invicti têm acesso às suas capacidades de integração. A Invicti pode ser executada num modo sem cabeça e tem plugins para Jenkins, etc. Pode marcar as análises como aprovadas/fracassadas com base numa política (como a ausência de vulnerabilidades críticas). A vantagem do Invicti é que você obtém uma varredura completa com a precisão baseada em provas, mas o desafio é o tempo de execução - varreduras completas do Invicti podem ser muito lentas para cada compilação. Muitos resolvem isso fazendo uma varredura completa durante a noite e uma rápida varredura direcionada em cada compilação (direcionada a componentes alterados ou usando testes de fumaça + DAST).
• Suíte Burp Enterprise - Integração de pipeline: O Burp Suite Enterprise Edition (diferente do Burp Pro) foi projetado para executar varreduras em uma programação ou disparar via CI. Ele tem uma API REST e plug-ins de CI. Uma equipe DevSecOps pode usá-lo para agendar varreduras após implantações e, em seguida, alimentar os resultados no JIRA. Embora não seja tão comumente conectado ao CI como o ZAP (devido ao custo), ele é usado em algumas configurações DevSecOps em empresas que padronizaram o Burp.
• Tenable.io WAS - Ganchos de nuvem: Se o seu pipeline pode implantar um ambiente de teste acessível aos scanners de nuvem da Tenable, você pode acionar uma varredura via API e pesquisar os resultados. Algumas equipas DevSecOps fazem isto para compilações nocturnas. Não é tão instantâneo quanto uma varredura ZAP local, mas descarrega a varredura para um serviço de nuvem.

Em suma, a automatização é rei aqui. As ferramentas que não foram criadas para automação ainda podem ser usadas em pipelines (por meio de scripts criativos), mas aquelas que reconhecem o DevSecOps com recursos e integrações economizarão tempo. As opções acima são inerentemente amigáveis à automação (ZAP, Aikido, StackHawk) ou evoluíram para suportá-la devido à demanda do mercado (Invicti, Burp Enterprise).

As equipas DevSecOps também utilizam frequentemente várias fases da DAST: uma análise rápida e ligeira na CI (para detetar coisas óbvias em minutos) e uma análise mais profunda após a implementação (que pode demorar mais tempo, mas não bloqueia os programadores). As ferramentas escolhidas precisam de apoiar essa estratégia.

Melhores ferramentas DAST para segurança de API

Público-alvo: Equipas que precisam especificamente de testar APIs da Web (REST, SOAP, GraphQL) quanto a vulnerabilidades. Isso inclui desenvolvedores de back-end, engenheiros de plataforma de API e testadores de segurança com foco em microsserviços. O teste de segurança de API é um pouco diferente do teste de interface do usuário da Web - não há interface de navegador, portanto, você precisa de ferramentas que possam analisar esquemas de API, manipular cargas JSON/XML e entender coisas como tokens de autenticação e chamadas de API em várias etapas.

Principais capacidades para DAST centradas em API:

• Importação de especificações da API: A ferramenta deve importar colecções Swagger/OpenAPI ou Postman para saber quais os pontos de extremidade existentes e os seus formatos. Isto poupa tempo e garante a cobertura de todos os pontos finais da API, mesmo aqueles que não são facilmente detectáveis.
• Suporte a GraphQL: As APIs GraphQL são agora comuns; testá-las requer um tratamento especial (consultas de introspeção, consultas aninhadas). Um bom DAST de API deve ter módulos para GraphQL (por exemplo, verificação de vulnerabilidades específicas de GraphQL, como negação de serviço de consulta profundamente aninhada).
• Suporte a SOAP e API herdada: Ainda relevante nas empresas - ferramentas que podem testar serviços SOAP importando WSDL ou gravando chamadas SOAP. Além disso, o tratamento de coisas como gRPC pode ser considerado (embora o suporte DAST para gRPC ainda seja incipiente; algumas ferramentas convertem gRPC em testes do tipo REST através de proxies).
• Autenticação e Tokens: O teste de API precisa lidar com chaves de API, tokens OAuth, JWTs, etc. A ferramenta deve facilitar o fornecimento destes (talvez através de um arquivo de configuração ou script de login) para que possa testar endpoints autorizados. Bônus se ela também puder testar a lógica de autorização, por exemplo, IDOR (Insecure Diret Object References) manipulando IDs.
• Tratamento de respostas não-HTML: As APIs retornam JSON ou XML. O verificador não deve esperar páginas HTML; deve analisar JSON e ainda encontrar problemas (como XSS em contexto JSON ou erros SQL em respostas de API). Alguns scanners mais antigos apenas olham para respostas HTML, o que não é suficiente para APIs.
• Consciência da limitação de taxa: O acesso demasiado intenso às APIs pode acionar limites de taxa ou mesmo bloquear o IP. Os scanners focados em APIs podem incluir configurações para respeitar os limites de taxa ou estrangular adequadamente, para evitar a interrupção do serviço (importante se estiver testando APIs de produção).

Principais ferramentas para segurança de API (DAST):

• Invicti (e Acunetix) - Descoberta e teste de API: Invicti é forte na verificação de API. Ele pode importar definições de API (REST, SOAP, GraphQL) e tem verificações especializadas para elas. Por exemplo, ele pode detetar vulnerabilidades GraphQL e testar muitas consultas geradas automaticamente. Ele também lida bem com a autenticação. Se uma organização tiver várias API (microsserviços), a Invicti pode analisá-las sistematicamente. O Acunetix, o seu irmão, partilha esta capacidade e é mais acessível a equipas mais pequenas.
• Qualys WAS - Suporte a API & OpenAPI v3: Qualys WAS anuncia especificamente a deteção de "desvio da especificação OpenAPI", o que implica que não só testa APIs, mas também encontra endpoints não documentados, comparando os endpoints observados com a especificação. Isso é valioso para a segurança da API porque os pontos de extremidade não listados podem ser um ponto cego de segurança. O Qualys também cobre APIs SOAP e pode ser alimentado com WSDLs. É uma escolha sólida para uma empresa com muitas APIs, especialmente porque se integra à sua plataforma geral.
• OWASP ZAP - Com complementos para APIs: O ZAP por si só pode fazer fuzz e testar endpoints JSON, mas ele realmente brilha para APIs quando usado com complementos. Há um complemento OpenAPI para importar arquivos Swagger e um complemento GraphQL também. Utilizando estes, o ZAP pode criar automaticamente pedidos para cada operação de API e depois analisá-los ativamente. Por ser de código aberto, é uma das poucas maneiras gratuitas de testar APIs completamente. Pode ser necessário ajustar algumas coisas (como fornecer tokens de autenticação por meio de scripts), mas existem muitos guias da comunidade.
• Suíte Burp - Ótimo para teste manual de API: O scanner do Burp pode ser usado em APIs, mas muitas vezes testar APIs com o Burp envolve esforço manual ou semi-automatizado. Você pode fazer proxy do tráfego de aplicativos móveis ou solicitações Postman por meio do Burp para capturar as chamadas de API e, em seguida, usar o Burp Scanner nelas. O Burp também tem uma extensão chamada "Upload Scanner" que pode fazer o fuzz de APIs de upload de arquivos, etc. Para GraphQL, existem extensões Burp para ajudar. Portanto, embora não seja um scanner de API automatizado pronto para uso, o Burp é uma plataforma poderosa para testes de API, se alguém estiver disposto a conduzi-lo. Os recursos de varredura da edição Professional realmente testarão as respostas JSON e outras em busca de vulnerabilidades, assim como faz com o HTML.
• Postman + Coleções de Segurança - (Aumentando o DAST): O Postman em si não é um DAST, mas existem coleções como as coleções "API Security Audit" que as pessoas criaram e que podem agir como verificações DAST rudimentares (por exemplo, enviar strings comuns de injeção de SQL em cada endpoint). Um programador preocupado com a segurança pode escrever testes Postman para fazer um fuzz básico dos seus endpoints API. Essa abordagem é gratuita (o Postman tem uma camada gratuita) e pode ser integrada ao CI via Newman (CLI do Postman). Não é tão abrangente quanto um scanner completo, mas é uma abordagem crescente no mundo DevSecOps para testes de segurança de API.
• Segurança do Aikido - Análise de API incorporada: a plataforma Aikido inclui análise de API, onde pode alimentar os seus pontos finais de API (ou deixar que os descubra juntamente com uma análise da Web). Suporta particularmente REST e GraphQL. Para uma equipa que já utiliza o Aikido para a Web, é conveniente ter a verificação da API no mesmo local. Ele tentará coisas como testes de acesso não autorizado (repetindo solicitações sem autenticação para ver se há vazamento de dados), que é um problema comum de API. Esta consolidação significa menos alternância de contexto - os programadores vêem os vulns da API e da Web num único painel de controlo.

Porquê estes: Os pontos de extremidade da API geralmente contêm dados confidenciais e são propensos a problemas como desvio de autenticação, exposição excessiva de dados, etc. As ferramentas DAST tradicionais historicamente se concentravam em páginas da Web, mas as listadas acompanharam a tendência de API-first. A sua utilização garante que as API de back-end são tão testadas como as de front-end. Dada a quantidade de violações que envolvem APIs (lembre-se da fuga de dados de utilizadores do Facebook através de uma API, ou dos problemas da API da T-Mobile), é fundamental concentrar-se na segurança das APIs. As ferramentas que podem simular o consumo malicioso de APIs são a forma de descobrir essas falhas.

Melhores ferramentas DAST para aplicações Web

Público: Isto pode parecer amplo (uma vez que a maioria das DAST é para aplicações Web), mas aqui interpretamos isto como organizações especificamente focadas em testar aplicações Web tradicionais (sítios Web, portais, sítios de comércio eletrónico) - possivelmente aquelas com interfaces de utilizador ricas. Pretendem as ferramentas com melhor desempenho na deteção de vulnerabilidades de aplicações Web nestes ambientes. Esta categoria está basicamente a perguntar: se a sua principal preocupação é proteger aplicações Web (com navegadores, formulários, contas de utilizador, etc.), quais são as ferramentas mais eficazes em geral?

Aspectos importantes para a verificação de aplicações Web puras (por oposição a APIs ou outros nichos):

• Rastreio e cobertura: Um scanner de aplicações Web deve rastrear eficazmente todas as ligações, incluindo as geradas por scripts ou eventos do utilizador. As ferramentas com melhores algoritmos de rastreio (navegador sem cabeça, tratamento de SPAs) cobrirão mais da aplicação.
• Gestão de sessões: As aplicações Web têm frequentemente início de sessão e estado complexos (carrinho de compras, fluxos de trabalho em várias etapas). As melhores ferramentas DAST para aplicações Web podem lidar com isso através de macros gravadas ou lógica de script.
• Profundidade da vulnerabilidade: Para aplicações Web, aspectos como XSS, SQLi, CSRF, inclusão de ficheiros, etc., são fundamentais. Algumas ferramentas têm verificações mais abrangentes para XSS (refletido, armazenado, baseado em DOM) do que outras, por exemplo. A capacidade de uma ferramenta encontrar XSS armazenado (que pode envolver uma página para submeter, outra para acionar) pode separar o ótimo do bom.
• Tratamento de falsos positivos: Numa grande aplicação Web, poderá obter centenas de resultados - as ferramentas que verificam ou priorizam claramente a possibilidade de exploração ajudam a concentrar-se nos problemas reais.
• Verificações de segurança do lado do cliente: As aplicações Web modernas podem ter problemas como a utilização insegura do armazenamento do lado do cliente ou vulnerabilidades em scripts de terceiros. Algumas ferramentas DAST agora sinalizam se o seu site está a carregar um script com um vuln conhecido ou se a Política de Segurança de Conteúdo está ausente. Estas são verificações mais "específicas da aplicação Web" para além das vulnerabilidades em bruto.

Principais ferramentas para aplicações Web:

• Invicti (Netsparker): Como um DAST de aplicações Web de topo, o rastreio e a deteção de vulnerabilidades da Invicti em aplicações Web típicas são excelentes. É conhecida por encontrar XSS e SQLi de forma muito fiável, mesmo em cenários complexos. A sua verificação de problemas como o XSS (por exemplo, pode inserir um payload seguro e depois detetar a sua execução) dá confiança. Devido à sua ampla cobertura e profundidade, o Invicti é frequentemente bem classificado em benchmarks de vulnerabilidades da Web.
• Suíte Burp Pro: Para testes práticos de aplicações Web, o Burp Pro não tem paralelo. O seu scanner, combinado com a capacidade de navegar manualmente nas partes mais difíceis e depois voltar a fazer o scan, significa que consegue lidar com a lógica estranha das aplicações Web. A vantagem do Burp é que, se o rastreamento automatizado falhar em algum ponto, um humano pode intervir, ultrapassar o obstáculo e deixar o Burp continuar. Esse modelo de teste interativo geralmente resulta em mais problemas encontrados em aplicativos complicados. O Burp também tem várias opções de ajuste de varredura para desempenho vs. minúcia, o que ajuda a otimizar para grandes aplicativos da Web.
• Acunetix: A Acunetix sempre se comercializou como focada em tecnologias web (incluindo muitas verificações específicas de CMS, WordPress, Drupal, etc.). Para sites típicos, especialmente aqueles que usam plataformas prontas para uso, o Acunetix se destaca por identificar vulnerabilidades conhecidas e configurações incorretas. É um scanner web sólido e versátil e tende a ter uma curva de aprendizagem mais baixa, o que significa que pode utilizá-lo numa aplicação web e obter bons resultados sem muitos ajustes.
• OWASP ZAP: É gratuito mas, em mãos experientes, pode ter um desempenho ao nível das ferramentas comerciais para muitas aplicações Web. A verificação ativa do ZAP tem uma vasta gama de ataques. Se bem configurado (com contexto como tokens de sessão iniciada, etc.), pode encontrar muita coisa. O ZAP também beneficia das regras da comunidade; por exemplo, alguém pode contribuir com um script que testa especificamente uma vulnerabilidade comum do comércio eletrónico e qualquer pessoa pode utilizá-lo. Para organizações que não podem pagar por ferramentas comerciais, o ZAP é a melhor aposta para segurança de aplicações web.
• HCL AppScan Standard: Tem um longo historial de análise de aplicações Web. Pode ser configurado em profundidade para aplicações complicadas (como a personalização de cadeias de injeção para evitar a quebra de determinadas páginas ou a pausa entre determinados passos). Por vezes, o motor heurístico do AppScan também encontra problemas lógicos menos óbvios. Para avaliações puramente Web, é uma ferramenta veterana utilizada por muitos testadores de segurança profissionais (especialmente os que vieram dos tempos do IBM AppScan). Têm uma grande base de conhecimentos sobre vulnerabilidades e as suas manifestações em aplicações Web, o que se traduz em casos de teste completos no scanner.

Porquê estes: Oferecem a melhor hipótese de encontrar uma grande variedade de vulnerabilidades em aplicações Web típicas. Uma aplicação Web pode ser uma coisa muito extensa com várias funcionalidades; estas ferramentas são comprovadas na análise de sítios Web inteiros de ponta a ponta. Ferramentas como a Invicti e a Burp são frequentemente utilizadas em conjunto: uma para a amplitude e outra para a profundidade. O Acunetix ou o AppScan, nas mãos de um analista, fornecem uma abordagem estruturada à análise em que muitas equipas de segurança confiam para as suas avaliações regulares de aplicações Web empresariais. E o ZAP, sendo de código aberto, democratiza essa capacidade.

Em suma, se o seu objetivo for "Tenho este portal Web e quero encontrar o maior número possível de problemas de segurança", as ferramentas acima referidas são das primeiras a considerar.

Melhores ferramentas DAST para APIs REST

Público: Este é um foco mais restrito em APIs RESTful (que poderia ser considerado um subconjunto de Segurança de API acima, mas aqui especificamente REST). Trata-se provavelmente de equipas que desenvolvem APIs REST (JSON sobre HTTP, conceção sem estado), incluindo backends de aplicações móveis ou backends de SPA, que pretendem garantir que essas APIs não são vulneráveis.

Áreas de incidência da API REST DAST:

• Integração Swagger/OpenAPI: Muito importante para REST. As ferramentas que podem ingerir uma especificação Swagger para uma API REST podem enumerar todos os pontos finais, métodos e parâmetros esperados, tornando a análise mais eficaz.
• Vulnerabilidades específicas do REST: Testes para coisas como manuseio inadequado de verbos HTTP (por exemplo, confusão entre GET e POST), falta de limitação de taxa e configurações incorretas típicas de REST (como HTTP PUT permitido onde não deveria ser, ou métodos que deveriam ser idempotentes, mas não são).
• Fuzzing de parâmetros: Os pontos de extremidade REST recebem frequentemente corpos JSON. O scanner deve tentar fazer fuzzing de parâmetros JSON com cargas úteis de injeção, objectos JSON aninhados, etc. Além disso, testar parâmetros de consulta em URLs para pontos de extremidade REST (como /users?filter=<script>).
• Autenticação/Autorização: Muitas APIs REST usam tokens (tokens de portador). As ferramentas precisam lidar com a anexação desses tokens a cada solicitação. Além disso, testar authZ em REST (como alterar um ID no URL para o ID de outro usuário) é algo que algumas ferramentas DAST tentam (embora o verdadeiro teste de lógica de autorização possa ir além do DAST).
• CSRF em APIs: Muitos pensam que as API não são afectadas por CSRF se não utilizarem cookies para autenticação, mas algumas utilizam (ou permitem cookies e tokens). Os scanners podem verificar se os pontos finais que mudam de estado têm protecções CSRF quando são utilizados cookies, por exemplo.

Principais ferramentas para a API REST DAST:

• OWASP ZAP com o complemento OpenAPI: Para uma API REST pura (digamos que você tenha um Swagger JSON), usar o complemento OpenAPI do ZAP importará todos os pontos de extremidade. O ZAP pode então atacar cada um deles com injecções relevantes. Poderá ser necessário escrever um script para lidar com cabeçalhos de autenticação, mas o scripting do ZAP torna isso possível. Por ser open source, é provavelmente a primeira coisa que muitos tentam numa API REST porque pode ser automatizada. A comunidade também partilhou exemplos de scripts especificamente para verificação de APIs.
• Sinergia Postman + OWASP ZAP: Uma abordagem livre interessante é usar o Postman para conduzir a autenticação e o uso normal da API (talvez por meio de uma coleção de pontos de extremidade), enquanto faz o proxy do Postman por meio do ZAP. Ao fazer isso, o ZAP observa a API e, em seguida, é possível iniciar uma verificação ativa do ZAP nesses pontos de extremidade observados. Esta combinação pode testar eficazmente os pontos finais REST que requerem sequências específicas ou passos de autenticação não triviais geridos pelo scripting do Postman. Muitos profissionais utilizam este método porque o Postman é ótimo para atingir todos os pontos finais corretamente (com dados corretos) e o ZAP pode então fazer a parte do teste de segurança.
• Invicti/Acunetix: Ambos têm um forte suporte para REST. Por exemplo, podem pegar num ficheiro Swagger e fazer testes abrangentes, incluindo a deteção de coisas como Problemas de acesso a nível de recursos RESTful (como testar se GET /usuários/123 pode ir buscar os dados de outro utilizador alterando o ID, ou seja, uma autorização de nível de objeto quebrada). Eles também testam problemas de negociação de conteúdo (por exemplo, se a API suporta entrada XML, eles podem tentar XXE através disso) - muitas vezes negligenciado em APIs REST. Esses produtos acompanham os problemas de segurança de API mais recentes (como o OWASP API Top 10) e incorporam verificações de acordo.
• Suíte Burp Pro: Com o Burp, testar APIs REST geralmente significa alimentá-lo com solicitações (via Repeater ou Spider) e depois deixar o Scanner fazer seu trabalho. Se tiver uma API REST grande, pode importar um Swagger para o Burp através de uma extensão (existe uma na BApp Store) que irá criar pedidos Burp para cada operação. Em seguida, pode lançar o scanner nesses pedidos. A vantagem do Burp é que, se algo precisar de um ajuste fino (como ajustar um formato de parâmetro específico), pode fazê-lo manualmente e reenviar. O controlo manual garante uma cobertura completa, embora seja mais trabalhoso do que uma ferramenta automatizada.
• Wapiti: O Wapiti tem um suporte decente para REST (como tem para qualquer interface HTTP). Ele fará o fuzz de payloads JSON e parâmetros de URL. Pode não analisar um ficheiro Swagger automaticamente, mas se lhe fornecermos alguns URLs de entrada ou se o deixarmos pesquisar uma página de documentação, ele consegue encontrar endpoints. Se alguém quisesse um pipeline de código aberto completo para verificação de API REST, o Wapiti combinado com um script para alimentar endpoints de um Swagger é uma solução viável.
• Tenable.io WAS: A solução da Tenable, mais uma vez, pode importar o Swagger. Em seguida, ele testará cada ponto de extremidade. Eles destacam em seus documentos como testar APIs, incluindo a adição de cabeçalhos personalizados ou tokens de autenticação nas configurações de verificação. É provável que a Tenable também use seu repositório de vulnerabilidades para verificar se há configurações incorretas conhecidas em servidores de API. Por exemplo, pode verificar se o seu servidor de API tem a listagem de diretórios activada em determinados caminhos ou se quaisquer estruturas de API vulneráveis conhecidas são detectadas pelas suas assinaturas.

Porquê estas: As API REST estão em todo o lado (qualquer aplicação web/móvel moderna tem uma). As injecções nas API REST podem ser igualmente devastadoras (por exemplo, uma injeção de SQL num ponto de extremidade REST é tão má como uma injeção num formulário Web). As ferramentas acima têm capacidades comprovadas para testar especificamente REST. Como prova, muitas ferramentas estão agora alinhadas com o OWASP API Security Top 10 - que é fortemente sobre REST. Ferramentas como a Invicti e a Qualys WAS mencionam explicitamente a cobertura destes (como BOLA - Broken Object Level Authorization - que é o número 1 no API Top 10, alguns scanners tentam detetar por ID fuzzing).

A utilização destas ferramentas nas API REST ajuda a detetar problemas que a análise de código estático pode não detetar (especialmente problemas de configuração ou erros no controlo de acesso). Simulam chamadas de cliente reais, que é a forma como os atacantes abordam as API.

Melhores ferramentas DAST para aplicações móveis

Público: Quando falamos de aplicações móveis no contexto da DAST, estamos sobretudo preocupados com os serviços de backend com os quais as aplicações móveis comunicam, bem como com quaisquer webviews ou navegadores incorporados na aplicação móvel. A segurança binária pura das aplicações móveis (como a verificação da existência de chaves codificadas no APK) é um domínio diferente (talvez SAST móvel), mas a DAST para aplicações móveis significa testar as interfaces do lado do servidor da aplicação móvel e, possivelmente, a comunicação de rede. O público pode ser constituído por programadores móveis ou testadores de segurança que garantem a segurança da interação móvel cliente-servidor.

Aspectos fundamentais:

• Testar pontos de extremidade de API utilizados por aplicações móveis: Muitas aplicações móveis utilizam APIs REST/GraphQL - o que nos leva de volta à verificação da API. No entanto, a diferença é que pode não ter documentação para estas se for uma API interna. Portanto, intercetar o tráfego móvel é o primeiro passo.
• Manuseamento de fluxos de autenticação: As aplicações móveis podem utilizar fluxos OAuth ou autenticação personalizada com tokens. Uma ferramenta DAST para dispositivos móveis precisa de capturar e reutilizar esses tokens. Muitas vezes, a maneira mais fácil é fazer o proxy da aplicação móvel e capturar uma sessão autenticada.
• Testar webviews: Algumas aplicações móveis são híbridas ou têm componentes de visualização Web. Estes podem ser testados como aplicações Web normais, se conseguir obter os URLs. Por exemplo, uma aplicação bancária pode ter uma secção de FAQ que é basicamente uma visualização Web de uma página Web - que deve ser analisada quanto a XSS, etc., porque se for vulnerável pode ser um vetor de ataque através da aplicação.
• Verificação de protocolos inseguros: Uma DAST que examine o tráfego móvel pode reparar se a aplicação chama um URL HTTP em vez de HTTPS, ou se aceita certificados SSL inválidos (algumas ferramentas podem testar por MITM com um certificado inválido para ver se a aplicação continua a ligar-se).
• Fluxos de trabalho e estado: Algumas interações móveis são sequências com estado (adicionar um artigo ao carrinho, depois comprar). Para as simular, pode ser necessário criar um script para a aplicação móvel ou replicar as chamadas através de um script automatizado. Isto é complexo, pelo que as ferramentas que podem gravar e reproduzir essas sequências são úteis.

Principais ferramentas/métodos para a aplicação móvel DAST:

• Suíte Burp - Padrão de teste móvel: O Burp é amplamente utilizado para testar aplicações móveis. O utilizador executa o proxy do Burp no seu PC, configura o dispositivo móvel para utilizar esse proxy (e instala o certificado CA do Burp no dispositivo para que o HTTPS possa ser intercetado). Depois, à medida que o utilizador utiliza a aplicação móvel, o Burp captura todas as chamadas API. A partir daí, é possível analisá-las e fazer uma varredura ativa. O Burp também pode destacar se a aplicação está a fazer algo como a fixação de certificados (nesse caso, verá falhas de ligação no Burp). Muitos problemas específicos de dispositivos móveis (como validação incorreta de certificados) podem ser avaliados com o Burp, vendo o que você pode intercetar ou manipular. A capacidade do Burp de repetir e modificar solicitações é crucial para testar a confiança do lado do servidor na entrada móvel.
• OWASP ZAP - Mobile Proxy e Scan: Da mesma forma, o ZAP pode fazer proxy do tráfego móvel. Pode exigir algum esforço manual para configurar no dispositivo, mas uma vez feito isso, você trata-o como uma verificação normal da Web dos pontos de extremidade capturados. O ZAP não tem funcionalidades específicas para dispositivos móveis, mas a sua análise geral da Web e da API funciona bem para backends móveis. É gratuito, o que é ótimo para investigadores individuais que testam aplicações Android.
• HCL AppScan com o Mobile Analyzer: O AppScan Standard tem funcionalidades para facilitar os testes móveis. Pode observar o tráfego de uma aplicação móvel (se a aplicação for executada através de um proxy ou emulador) e, em seguida, executar testes. Além disso, a IBM (e agora a HCL) ofereceu o AppScan Mobile Analyzer, que fazia alguma introspeção em binários de aplicações móveis e alguma análise dinâmica. Mas concentrando-se no DAST, o AppScan pode certamente testar os pontos finais da Web que uma aplicação móvel atinge e até oferece um cliente para automatizar um emulador móvel, embora isso seja uma utilização avançada.
• Segurança Aikido - Plataforma AppSec completa (móvel incluída): Embora o Aikido não seja uma ferramenta de teste móvel em si, abrange a segurança das aplicações móveis, na medida em que analisa as API (através da sua análise de API) e também pode efetuar uma análise estática do código móvel (se uma empresa tiver a fonte). Por exemplo, se tiver um backend móvel, pode alimentar o seu URL com o DAST do Aikido e obter resultados. Se tiver o código móvel, o SAST do Aikido pode detetar coisas como a geração insegura de números aleatórios ou segredos codificados. A combinação é útil para as equipas móveis que pretendem uma plataforma única para o código da aplicação e para os serviços Web da aplicação.
• Postman para API móvel + ZAP: À semelhança do que foi referido anteriormente, se conseguir capturar as chamadas da API móvel (através de proxy ou de engenharia inversa da aplicação para obter pontos finais), pode recriá-las no Postman e testá-las com o ZAP ou manualmente. Existe também um projeto OWASP chamado MobSF (Mobile Security Framework) que efectua algumas análises dinâmicas através da execução de um emulador. O MobSF faz principalmente análise estática, mas vale a pena mencioná-lo como uma ferramenta de segurança móvel de código aberto; para o DAST, ele pode fazer alguns fuzzing básicos de API se você fornecer endpoints.
• Nessus / Nexpose etc. - verificações do ambiente: Embora não esteja a testar diretamente a aplicação, a execução de uma verificação de vulnerabilidades nos servidores que alojam o backend móvel ou a verificação das configurações SSL (por exemplo, com Qualys SSL Labs ou Nessus) faz frequentemente parte dos testes de aplicações móveis. Isto garante que os servidores com os quais a aplicação fala estão configurados corretamente (sem versões antigas de TLS, etc.). Menciono isto porque, em compromissos móveis, ferramentas como o Nessus complementam frequentemente o DAST, abrangendo questões do lado do servidor para além da lógica da aplicação.

Porquê estas: As aplicações móveis apresentam desafios únicos, como a fixação de certificados, que pode dificultar a DAST. Mas as abordagens acima são o que os profissionais de segurança utilizam para entrar na conversa entre a aplicação móvel e o servidor. O Burp Suite é basicamente a ferramenta de facto para pentesting de aplicações móveis devido à sua flexibilidade. O ZAP pode conseguir muito do mesmo com um pouco mais de configuração, mas sem nenhum custo. Estas ferramentas permitem-lhe encontrar problemas como: a API confia nos IDs fornecidos pelo utilizador (levando à exposição de dados)? A aplicação móvel não consegue validar o SSL (permitindo o man-in-the-middle)? Existem pontos de extremidade ocultos que a aplicação chama e que não são óbvios?

Usando DAST em backends móveis, é possível simular o que um invasor faria se desmontasse o aplicativo móvel e começasse a enviar solicitações de API criadas. Isto é fundamental; muitas violações móveis (pense na fuga da API da Uber ou nos problemas anteriores da API do Snapchat) provêm de alguém que inverte a aplicação móvel e abusa da API. As ferramentas DAST aplicadas da forma acima descrita podem frequentemente detetar essas fraquezas antes de um atacante o fazer.

Conclusão

A segurança das aplicações Web em 2025 exige uma abordagem proactiva - os atacantes estão constantemente a sondar os nossos websites, APIs e aplicações móveis em busca de pontos fracos. As ferramentas de testes dinâmicos de segurança de aplicações (DAST) são uma pedra angular dessa defesa proactiva, oferecendo uma visão de hacker das vulnerabilidades da sua aplicação. Ao simular ataques de forma dinâmica, as ferramentas DAST ajudam-no a identificar e corrigir problemas que as revisões de código estático podem ignorar, desde injecções de SQL num formulário esquecido a servidores mal configurados que aceitam cifras fracas.

Pronto para levar a segurança das suas aplicações para o próximo nível? Comece a utilizar gratuitamente com a plataforma tudo-em-um do Aikido.

‍

TL;DR: Nós estamos lançando o Opengrep, um fork do SemgrepCE, em resposta ao seu fechamento de código aberto.

Nós somos os iniciadores do Opengrep. Vamos a isso: No mês passado, a Semgrep anunciou grandes mudanças no seu projeto OSS - estrategicamente programado para uma sexta-feira, claro ;)

Desde 2017, a Semgrep tem sido uma pedra angular da comunidade de segurança de código aberto, oferecendo um mecanismo de análise de código e um repositório de regras juntamente com seu produto SaaS. Mas seus movimentos recentes levantam a questão: o que "aberto" realmente significa?

As principais mudanças incluem o bloqueio de regras contribuídas pela comunidade sob uma licença restritiva e a migração de recursos críticos como rastreamento de ignorados, LOC, fingerprints e metavariáveis essenciais para longe do projeto aberto.

Isso não é surpreendente - o Semgrep tem abandonado silenciosamente o mecanismo de código aberto há algum tempo. O rebranding de "Semgrep OSS" para "Semgrep Community Edition" parece ser o prego final no caixão.

Porquê?

Talvez pressão dos VCs, que consideram que as contribuições de código aberto "canibalizam" as receitas do SaaS, ou proteção contra a concorrência? A Semgrep afirma que a mudança foi para impedir que os fornecedores usassem as regras e o mecanismo em ofertas SaaS concorrentes. No entanto, ainda ontem, com o anúncio da "IA", o fundador declarou que "o motor Semgrep original está a tornar-se obsoleto".

Seja qual for o caso, enquanto nós respeitamos um espírito competitivo, esta repressão ao código aberto faz pouco para parar organizações rivais. Mais do que tudo, este movimento mina a confiança da comunidade - não apenas no Semgrep, mas em todos os projectos de código aberto.

"Este tipo de mudança também prejudica todos os projectos de código aberto semelhantes. Todas as empresas e todos os programadores têm agora de pensar duas vezes antes de adotar e investir num projeto de código aberto, no caso de o criador decidir subitamente alterar a licença"... ou anular a funcionalidade (Opentofu).

Este padrão é familiar: A mudança de licença do Elasticsearch levou a AWS a criar o OpenSearch. O movimento Opentofu surgiu após o rugpull do Terraform da HashiCorp. O código aberto liderado por fornecedores geralmente prioriza os interesses comerciais sobre a comunidade para chegar às "grandes ligas". E isso é péssimo.

Por isso, estamos a agir.

Unimo-nos a 10 concorrentes diretos para lançar o Opengrep - uma posição coordenada de toda a indústria para manter vivo um grande projeto de código aberto e tornar o desenvolvimento seguro de software um padrão partilhado e neutro em relação aos fornecedores.

Nir Valtman (CEO, Arnica), Ali Mesdaq (CEO, Amplify Security), Varun Badhwar (CEO, Endor Labs), Aviram Shmueli (CIO, Jit), Pavel Furman (CTO, Kodem), Liav Caspi (CTO, Legit), Eitan Worcel (CEO, Mobb) e Yoav Alon (CTO, Orca Security).

O que pode esperar com o Opengrep?

Melhorias de desempenho, desbloqueio de funcionalidades exclusivas para profissionais, suporte alargado de idiomas, migração de funcionalidades críticas de volta para o motor e novos avanços: compatibilidade com o Windows, análise de ficheiros cruzados, o roteiro é longo.

Juntos, estamos a reunir capital comprometido e recursos de desenvolvimento OCAML para avançar e tornar os testes de segurança de aplicações estáticas mais acessíveis.

Porque, sejamos realistas, há coisas mais interessantes para construir. Encontrar é uma coisa... vamos concentrar-nos no futuro, em como podemos encontrar e corrigir vulnerabilidades de segurança de forma rápida e automática. Vamos concentrar-nos em fazer com que os programadores voltem a construir.

Quer saber mais sobre o Opengrep?

Leia o Manifesto do Opengrep. Aproveite e contribua para o Opengrep hoje mesmo.
Para contribuir ou participar como patrocinador, abra um problema no GitHub.

Para a comunidade e contribuidores, junte-se à sessão de roteiro aberto no dia 20 de fevereiro.
Siga-nos no X. Linkedin.

"Assegurar que o futuro do SAST está aberto" No Opengrep com Mackenzie Jackson