DEV Community: Ronaldo Modesto

Protocols Visualizer: An Interactive Way to Learn Network Protocols

Ronaldo Modesto — Sat, 07 Mar 2026 13:35:49 +0000

Understanding how network protocols work is often heavy going: RFCs and textbooks explain the concepts, but it's hard to "see" handshakes, packet structure, and attacks in action. Protocols Visualizer is a free, interactive web app that turns those ideas into visual, step-by-step flows and simulations.

Try it here: https://protocols-visualizer.vercel.app/en

The app is built around the OSI model. You can browse all seven layers — from Physical (Bluetooth, USB, Coaxial) up to Application (HTTP, DNS, FTP, SMTP) — and open each protocol to explore three main areas: Communication Flow (animated sequence diagrams), Packet Anatomy (interactive headers), and Attack Simulation (e.g. SYN Flood, ARP Spoofing, deauth, Bad USB). The goal is to make dense topics like TCP handshakes, IP routing, or common attacks easier to grasp by showing them in motion instead of only in text.

The project is implemented with Next.js, React, TypeScript, and Tailwind CSS, and is available in English and Portuguese. Whether you're studying for certs, teaching networking, or just curious how the stack works, Protocols Visualizer is a handy companion to see protocols in action.

Feedbacks are welcome

Safeinstall: Um aliado no combate a ataques de Supply chain

Ronaldo Modesto — Thu, 19 Feb 2026 22:10:25 +0000

Olá, pessoal!

Se você é desenvolvedor ou, pelo menos, envolvido com a área tech, tenho certeza de que já ouviu falar de ataques de supply chain, ou ataques de cadeia de suprimentos.

Esse tipo de ataque tem se tornado cada vez mais frequente, ainda mais com IAs gerando cada vez mais código sem supervisão. Com isso em mente, criei uma ferramenta que visa impedir que dependências comprometidas sejam instaladas em seu projeto, reduzindo o risco de um ataque bem-sucedido de cadeia de suprimentos.

Chega mais para conhecer! E, claro, todo feedback é super bem-vindo. 🙂

Ha e claro, se quiser saber mais sobre o que é supply chain atack, dá uma conferida aqui O que é Suply Chain Attack

A Crise de Segurança na Cadeia de Suprimentos Open Source

Os ataques de supply chain (cadeia de suprimentos) têm aumentado de forma alarmante nos últimos anos. Dados recentes revelam um cenário preocupante:

Malware em código aberto subiu 156% de um ano para outro em 2024, com mais de 704 mil pacotes maliciosos identificados desde 2019.
Em 2025, houve um aumento de 73% em pacotes open source maliciosos detectados em comparação com 2024.
Entre 2020 e 2023, as ameaças em repositórios open source cresceram 1.300%.
O custo global anual projetado de ataques de supply chain deve alcançar US$ 60 bilhões em 2025.
No ecossistema npm, a atividade maliciosa mais do que dobrou em 2025, representando quase 90% de todo o malware open source detectado.
Terceiros comprometidos passaram a representar 30% de todas as violações de dados em 2025.

Instalar dependências sem verificação tornou-se uma operação de risco. Mesmo pacotes populares podem conter vulnerabilidades conhecidas ou, em cenários mais graves, serem comprometidos por atacantes.

O que é o SafeInstall ✅?

O SafeInstall é um wrapper de segurança para comandos de instalação de pacotes que consulta a API do OSV (Open Source Vulnerabilities) para identificar vulnerabilidades conhecidas antes de permitir que a instalação seja concluída. Assim, ele ajuda a reduzir ataques de supply chain alertando o desenvolvedor sobre pacotes vulneráveis antes que eles entrem no projeto.

Repositório da ferramenta 🚀: Github

Benefícios Principais

Verificação antes da instalação — Nada é instalado sem checagem de vulnerabilidades.
Integração com OSV — Usa dados agregados do GitHub Advisory, PyPI Advisory, CVE/NVD, RustSec, Go Vulnerability Database e outros.
Suporte a múltiplos ecossistemas — npm, pip, Go, Cargo, RubyGems, Packagist, Pub.
Instalações em lote — Protege comandos como npm install e pip install -r requirements.txt.
Controle nas suas mãos — Permite confirmar ou cancelar instalações com risco identificado.

A seguir temos mostro exemplos de como a ferramenta funciona e como ela pode auxiliar na proteção desse tipo de ataque.

Bloqueando instalação de biblioteca especificando uma versão

Bloqueando instalação de biblioteca utilizando instalação em massa, por exemplo npm i

Permitindo instalação de bibliotecas mesmo com vulnerabilidades(ambientes de CI/CD por exemplo)

Quando uma versão não é especificada, a ferramenta tenta identificar automaticamente a última versão e então analisa para ver se alguma vulnerabilidade é encontrada

Exemplo golang para instalação vulnerável vs instalação de última versão

Exemplo de biblioteca python

Exemplo de biblioteca sem vulnerabilidades em lotes

Exemplo de biblioteca sem vulnerabilidade

Como Instalar 💥

Pré-requisitos

Go 1.25.7+ — Necessário para compilar o SafeInstall e para o osv-scanner.
osv-scanner — Necessário para varreduras em lote. É instalado automaticamente pelos scripts de instalação.

Para instalar o osv-scanner manualmente (se necessário):

go install github.com/google/osv-scanner/v2/cmd/osv-scanner@v2

Garanta que $(go env GOPATH)/bin esteja no seu PATH.

Instalação por plataforma

Windows (PowerShell):

.\scripts\install.ps1

Windows (Prompt de Comando):

scripts\install.bat

Linux / macOS:

chmod +x scripts/install.sh
./scripts/install.sh

Compilação manual:

go build -o safeinstall .

Comandos e Uso

Sintaxe básica

Sintaxe nova (recomendada):

safeinstall [-y|--yes] <ecosistema> "<pacote>"

Sintaxe legada (comando completo):

safeinstall [-y|--yes] "<comando de instalação>"

Instalação de pacote único

Ao especificar um pacote com versão, o SafeInstall:

Consulta a API do OSV em busca de vulnerabilidades conhecidas
Aplica o algoritmo IsVulnerable para saber se sua versão exata é afetada
Se houver vulnerabilidade: exibe CVE/GHSA em vermelho e pede confirmação
Se estiver seguro: exibe mensagem em verde e prossegue automaticamente

Exemplos (sintaxe nova):

safeinstall npm "express"
safeinstall npm "express@4.17.1"
safeinstall pip "requests==2.25.1"
safeinstall pip "jinja2"
safeinstall go "golang.org/x/crypto@v0.1.0"

Exemplos (sintaxe legada):

safeinstall "npm i express"
safeinstall "pip install -r requirements.txt"

Instalação em lote (npm i, pip install -r, etc.)

Para comandos que não especificam um único pacote (ex.: npm install, npm ci, pip install -r requirements.txt):

O osv-scanner roda antes da instalação, analisando manifests e lockfiles
Se forem encontradas vulnerabilidades e você não passou -y/--yes, o SafeInstall pede confirmação
Se você recusar, a instalação é cancelada — pacotes vulneráveis não são instalados
Se não houver vulnerabilidades (ou você aceitar o risco), o comando de instalação é executado
Após a instalação, o osv-scanner roda novamente para verificar as dependências instaladas

Exemplos:

safeinstall "npm install"
safeinstall "npm ci"
safeinstall "pip install -r requirements.txt"

Modo CI/CD

Use -y ou --yes para aceitar automaticamente os riscos em ambientes automatizados:

safeinstall -y "npm install express@4.17.1"

Desinstalação

Para remover o SafeInstall por completo:

safeinstall --uninstall
# ou
safeinstall -u
# ou
safeinstall uninstall

Ou use os scripts de desinstalação:

Windows (PowerShell): .\scripts\uninstall.ps1
Windows (CMD): scripts\uninstall.bat
Linux/macOS: ./scripts/uninstall.sh

Ecossistemas Suportados

Ecossistema	Gerenciador de Pacotes	Exemplo
npm	npm, yarn, pnpm	`safeinstall npm "express@4.17.1"`
PyPI	pip, pip3, poetry	`safeinstall pip "requests==2.25.1"`
Go	go get	`safeinstall go "golang.org/x/crypto@v0.1.0"`
crates.io	cargo	`safeinstall "cargo add serde@1.0"`
RubyGems	gem	`safeinstall "gem install rails:7.0"`
Packagist	composer	Pacotes PHP
Pub	pub	Pacotes Dart

Como o SafeInstall Reduz o Risco de Supply Chain

Bloqueio proativo — Evita instalações de pacotes conhecidamente vulneráveis ou maliciosos.
Uso de dados confiáveis — OSV agrega bases como GitHub Advisory, PYSEC, CVE e RustSec.
Avaliação precisa — Usa o algoritmo oficial do OSV (IncludedInVersions, IncludedInRanges, BeforeLimits).
Dupla verificação em lote — Analisa antes e depois da instalação em cenários como npm install e pip install -r.
Decisão consciente — O desenvolvedor escolhe se aceita o risco em casos específicos.
Integração simples — Substitui chamadas diretas aos gerenciadores de pacotes com um comando único.

Requisitos

Conexão com a internet para consultas à API

- Go e osv-scanner no PATH (para instalações em lote)

Fontes:

[1] Supply Chain Attack Statistics 2025: Costs & Defenses — DeepStrike. https://deepstrike.io/blog/supply-chain-attack-statistics-2025
[2] The State of the Software Supply Chain 2025 — JFrog. https://jfrog.com/blog/state-of-software-supply-chain-security-2025
[3] ReversingLabs 2026 Software Supply Chain Security Report — 73% aumento em pacotes open source maliciosos. https://www.reversinglabs.com/press-releases/reversinglabs-2026-software-supply-chain-security-report-identifies-73-increase-in-malicious-open-source-packages
[4] Sonatype's 10th Annual State of the Software Supply Chain Report — 156% de aumento em malware open source. https://www.globenewswire.com/news-release/2024/10/10/2961239/0/en/Sonatype-s-10th-Annual-State-of-the-Software-Supply-Chain-Report-Reveals-156-Surge-in-Open-Source-Malware.html

Como Funciona Supply Chain Attack -PTBR

Ronaldo Modesto — Thu, 19 Feb 2026 22:08:09 +0000

Access the english version here: Click Here

Olá pessoal.
Hoje quero trazer um pouquinho a mais de conhecimento a respeito de um tipo de ataque que tem se tornado cada vez mais frequente. O Supply Chain Attack, ou ataque de cadeia de suprimentos.
Bora lá ver como isso funciona no ecossistema npm e o que podemos fazer para mitigar esse risco.
Lembrando que aqui eu trouxe o npm apenas como exemplo, mas esse tipo de ataque pode ocorrer em outros gerenciadores de pacotes também!

Aqui você encontra uma ferramenta que eu desenvolvi para mitigar esse tipo de ataque: Safeinstall

Caso queira ver como a ferramenta funciona, dá uma olhada aqui SafeInstall

Introdução

Quantas vezes por dia você executa npm install? Para a maioria dos desenvolvedores JavaScript e Node.js, a resposta é: várias. Essa rotina aparentemente inocente — instalar uma dependência para resolver um problema — esconde um vetor de ataque cada vez mais explorado por cibercriminosos: o ataque de supply chain (ou ataque de cadeia de suprimentos).

Neste artigo, exploramos o que são esses ataques, como funcionam na prática usando um projeto de demonstração real, quais seriam as consequências em ambientes de produção e como você pode se proteger.

O projeto utilizado no artigo pode ser encontrado aqui: Projeto Exemplo

O que é um Supply Chain Attack?

Um ataque de supply chain ocorre quando um atacante compromete algum componente que faz parte da cadeia de suprimentos de software — ou seja, algo que os desenvolvedores ou sistemas confiam e utilizam sem questionar. No ecossistema npm, isso se materializa principalmente através de:

Pacotes maliciosos criados do zero para parecerem legítimos
Pacotes legítimos comprometidos (manutenção abandonada, conta hackeada, typosquatting)
Scripts de lifecycle que executam automaticamente durante npm install

O ponto crítico é que o desenvolvedor não precisa fazer nada além de instalar o pacote. Não é necessário abrir um arquivo suspeito, clicar em um link ou executar um binário desconhecido. O simples ato de adicionar uma dependência ao package.json e rodar npm install pode ser suficiente para comprometer a máquina, o repositório ou a infraestrutura.

Scripts de Lifecycle: A Porta de Entrada

O npm define diversos scripts que são executados em momentos específicos do ciclo de vida de um pacote:

Script	Momento de execução
`preinstall`	Antes do pacote ser instalado
`install`	Durante a instalação
`postinstall`	Imediatamente após a instalação — alvo preferido de ataques
`preuninstall`	Antes de desinstalar
`postuninstall`	Após desinstalar
`prepublish`	Antes de publicar no registro npm

Qualquer pessoa que execute npm install rodará esses scripts automaticamente, sem avisos claros. É aí que reside o perigo.

Projeto de Demonstração: Estrutura e Código

Para ilustrar o vetor de ataque, criamos um projeto educacional composto por:

Pacote “malicioso” — um pacote que parece útil, mas executa código nas fases de instalação
Projeto vítima — um projeto que simplesmente depende desse pacote

Estrutura do Pacote Malicioso

O package.json do pacote define os scripts que serão executados:

{
  "name": "utilidades-uteis",
  "version": "1.0.0",
  "description": "Pacote útil que parece legítimo mas executa código no post-install",
  "main": "index.js",
  "scripts": {
    "postinstall": "node postinstall.js",
    "preinstall": "node preinstall.js"
  },
  "keywords": ["utility", "helper"],
  "author": "Atacante Anônimo",
  "license": "MIT"
}

Note que postinstall e preinstall apontam para scripts Node.js. Esses scripts rodam automaticamente durante a instalação.

Script preinstall.js

Este script executa antes da instalação do pacote:

/**
 * PREINSTALL - Roda ANTES da instalação do pacote
 * Outra fase onde código malicioso pode executar
 */

console.log('\u001b[35m[preinstall]\u001b[0m Este script roda antes mesmo do pacote ser instalado!');

Em um ataque real, aqui poderia haver coleta inicial de dados ou preparação do ambiente.

Script postinstall.js — O Coração do Ataque

Aqui está o script que simula a exfiltração de dados sensíveis:

const fs = require('fs');
const path = require('path');
const os = require('os');

// Simula o que um atacante PODERIA coletar (apenas mostra, não envia)
const dadosSensiveis = {
  executadoEm: new Date().toISOString(),
  usuario: os.userInfo().username,
  diretorioAtual: process.cwd(),
  platform: process.platform,
  nodeVersion: process.version,
  // Um atacante real tentaria ler:
  // env: process.env,  // Tokens, senhas, API keys
  // arquivos: fs.readdirSync(process.env.HOME)
};

// Cria arquivo de "prova" - em ataque real seria enviado para servidor
const arquivoProva = path.join(process.cwd(), 'PROVA_ATAQUE_SUPPLY_CHAIN.json');
fs.writeFileSync(arquivoProva, JSON.stringify(dadosSensiveis, null, 2), 'utf8');

console.log(`\u001b[31m[ATAQUE SIMULADO]\u001b[0m Dados coletados salvos em: ${arquivoProva}`);
console.log('\nEm um ataque REAL, isso seria enviado para o servidor do atacante.\n');

Exemplo de arquivo criado após o script executar

E ao executar a aplicação o usuário nem percebe o que aconteceu

Em uma versão maliciosa real, o atacante trocaria fs.writeFileSync por uma chamada HTTP (por exemplo, com https.request) para enviar esses dados a um servidor sob seu controle. O pacote também expõe um módulo legítimo (index.js) que faz algo útil — tornando o pacote plausível e reduzindo a suspeita.

Fluxo do Ataque

1. Desenvolvedor: npm install utilidades-uteis
2. npm baixa o pacote
3. npm executa preinstall  → código malicioso #1
4. npm executa postinstall → código malicioso #2 (coleta dados)
5. Pacote instalado normalmente
6. Desenvolvedor não percebe que foi comprometido

Consequências em Ambientes Reais

O que poderia acontecer se esse fosse um ataque real? As consequências variam conforme o contexto da vítima.

1. Exfiltração de Credenciais e Segredos

Variáveis de ambiente (process.env): tokens de API (AWS, GitHub, Stripe), chaves de banco de dados, senhas
Arquivos .env: credenciais em texto plano em vários projetos
Arquivos de configuração: ~/.npmrc, ~/.aws/credentials, ~/.ssh/config

Impacto: Acesso a contas cloud, bancos de dados, repositórios privados e sistemas de terceiros.

2. Roubo de Chaves SSH e Certificados

Leitura de ~/.ssh/ (chaves privadas, known_hosts)
Uso das chaves para acessar servidores, GitHub, repositórios privados

Impacto: Invasão de servidores, clonagem de repositórios privados, commit de código malicioso em nome da vítima.

3. Cryptojacking

Execução de minerador de criptomoeda em segundo plano
Uso de CPU e energia da máquina ou servidor da vítima

Impacto: Custos elevados de infraestrutura, degradação de desempenho, possível violação de políticas de uso de cloud.

4. Backdoors e Persistência

Instalação de ferramentas de acesso remoto
Adição de tarefas agendadas ou scripts de inicialização

Impacto: Controle prolongado da máquina, espionagem, preparação para ataques futuros.

5. Modificação de Outros Pacotes

Alteração de código em node_modules de outras dependências
Injeção de backdoors em bibliotecas usadas em produção

Impacto: Comprometimento em escala, propagação do ataque para todos os usuários da aplicação.

6. Em Ambientes CI/CD

Acesso a secrets de pipelines (tokens, credenciais)
Possibilidade de modificar artefatos de build ou imagens Docker
Deploy de versões comprometidas em produção

Impacto: Comprometimento de toda a cadeia de entrega, desde o build até produção.

Casos Reais Documentados

Caso	Ano	Descrição
event-stream	2018	Pacote com ~2M downloads/semana. Código malicioso adicionado para roubar carteiras Bitcoin.
ua-parser-js	2021	Biblioteca popular comprometida; executava minerador de criptomoeda.
coa e rc	2021	Typosquatting; pacotes roubavam variáveis de ambiente e as enviavam para servidor remoto.
node-ipc	2022	Adicionou código que alterava arquivos em máquinas de desenvolvedores de certas regiões geográficas.

Medidas de Proteção

Use --ignore-scripts quando possível: npm install --ignore-scripts
Audite dependências: npm audit, npm audit fix
Verifique scripts: npm view nome-do-pacote antes de instalar
Ferramentas especializadas: Socket.dev, Snyk para detecção de comportamentos suspeitos
Mantenha package-lock.json versionado e revise mudanças
Verifique procedência: downloads, manutenção ativa, repositório aberto

Conclusão

O ecossistema npm é extremamente conveniente, mas essa conveniência traz riscos. O ato aparentemente trivial de npm install pode executar código arbitrário na sua máquina. A consciência sobre supply chain attacks e a adoção de boas práticas de segurança são fundamentais para reduzir a superfície de ataque e proteger projetos e infraestrutura.

O projeto de demonstração está disponível para que você possa testar o fluxo em um ambiente controlado e entender na prática como esses ataques funcionam.

How Supply Chain Attacks Work

Ronaldo Modesto — Thu, 19 Feb 2026 22:08:03 +0000

Acesse a versão em português aqui: Clique Aqui

Hi everyone.

Today I want to share a little more knowledge about a type of attack that has become increasingly frequent: the Supply Chain Attack.

Let's see how this works in the npm ecosystem and what we can do to mitigate this risk.
Remember that I've only used npm as an example here, but this type of attack can occur in other package managers as well!

Here you'll find a tool I developed to mitigate this type of attack. Safeinstall

If you want to see how the tool works, take a look here SafeInstall

Introduction

How many times a day do you run npm install? For most JavaScript and Node.js developers, the answer is: many. This seemingly innocent routine — installing a dependency to solve a problem — hides an attack vector increasingly exploited by cybercriminals: the supply chain attack.

In this article, we explore what these attacks are, how they work in practice using a real demonstration project, what the consequences would be in production environments, and how you can protect yourself.

The project used in the article can be found here: Example Project

What is a Supply Chain Attack?

A supply chain attack occurs when an attacker compromises a component that is part of the software supply chain — something that developers or systems trust and use without question. In the npm ecosystem, this materializes mainly through:

Malicious packages created from scratch to appear legitimate
Compromised legitimate packages (abandoned maintenance, hacked account, typosquatting)
Lifecycle scripts that execute automatically during npm install

The critical point is that the developer does not need to do anything beyond installing the package. No need to open a suspicious file, click a link, or run an unknown binary. The simple act of adding a dependency to package.json and running npm install can be enough to compromise the machine, repository, or infrastructure.

Lifecycle Scripts: The Entry Point

npm defines various scripts that run at specific moments in a package's lifecycle:

Script	When it runs
`preinstall`	Before the package is installed
`install`	During installation
`postinstall`	Immediately after installation — preferred target for attacks
`preuninstall`	Before uninstalling
`postuninstall`	After uninstalling
`prepublish`	Before publishing to the npm registry

Anyone who runs npm install will execute these scripts automatically, with no clear warning. That is where the danger lies.

Demonstration Project: Structure and Code

To illustrate the attack vector, we built an educational project consisting of:

"Malicious" package — a package that appears useful but runs code during installation
Victim project — a project that simply depends on that package

Malicious Package Structure

The package's package.json defines the scripts that will be executed:

{
  "name": "utilidades-uteis",
  "version": "1.0.0",
  "description": "Pacote útil que parece legítimo mas executa código no post-install",
  "main": "index.js",
  "scripts": {
    "postinstall": "node postinstall.js",
    "preinstall": "node preinstall.js"
  },
  "keywords": ["utility", "helper"],
  "author": "Atacante Anônimo",
  "license": "MIT"
}

Note that postinstall and preinstall point to Node.js scripts. These scripts run automatically during installation.

preinstall.js Script

This script runs before the package is installed:

/**
 * PREINSTALL - Runs BEFORE the package is installed
 * Another phase where malicious code can execute
 */

console.log('\u001b[35m[preinstall]\u001b[0m This script runs even before the package is installed!');

In a real attack, initial data collection or environment preparation could happen here.

postinstall.js Script — The Heart of the Attack

Here is the script that simulates exfiltration of sensitive data:

const fs = require('fs');
const path = require('path');
const os = require('os');

// Simulates what an attacker COULD collect (only shows, does not send)
const dadosSensiveis = {
  executadoEm: new Date().toISOString(),
  usuario: os.userInfo().username,
  diretorioAtual: process.cwd(),
  platform: process.platform,
  nodeVersion: process.version,
  // A real attacker would try to read:
  // env: process.env,  // Tokens, passwords, API keys
  // arquivos: fs.readdirSync(process.env.HOME)
};

// Creates "proof" file - in real attack would be sent to server
const arquivoProva = path.join(process.cwd(), 'PROVA_ATAQUE_SUPPLY_CHAIN.json');
fs.writeFileSync(arquivoProva, JSON.stringify(dadosSensiveis, null, 2), 'utf8');

console.log(`\u001b[31m[SIMULATED ATTACK]\u001b[0m Data collected saved to: ${arquivoProva}`);
console.log('\nIn a REAL attack, this would be sent to the attacker\'s server.\n');

Example of a file created after the script runs:

And when running the application, the user doesn't even notice what happened:

In a real malicious version, the attacker would replace fs.writeFileSync with an HTTP call (e.g., using https.request) to send this data to a server under their control. The package also exposes a legitimate module (index.js) that does something useful — making the package plausible and reducing suspicion.

Attack Flow

1. Developer: npm install utilidades-uteis
2. npm downloads the package
3. npm runs preinstall  → malicious code #1
4. npm runs postinstall → malicious code #2 (collects data)
5. Package installed normally
6. Developer does not realize they have been compromised

Consequences in Real Environments

What could happen if this were a real attack? The consequences vary depending on the victim's context.

1. Exfiltration of Credentials and Secrets

Environment variables (process.env): API tokens (AWS, GitHub, Stripe), database keys, passwords
.env files: credentials in plain text across multiple projects
Configuration files: ~/.npmrc, ~/.aws/credentials, ~/.ssh/config

Impact: Access to cloud accounts, databases, private repositories, and third-party systems.

2. Theft of SSH Keys and Certificates

Reading ~/.ssh/ (private keys, known_hosts)
Using the keys to access servers, GitHub, private repositories

Impact: Server intrusion, cloning of private repositories, malicious commits in the victim's name.

3. Cryptojacking

Running a cryptocurrency miner in the background
Consuming the victim's machine or server CPU and power

Impact: High infrastructure costs, performance degradation, possible violation of cloud usage policies.

4. Backdoors and Persistence

Installing remote access tools
Adding scheduled tasks or startup scripts

Impact: Prolonged control of the machine, espionage, preparation for future attacks.

5. Modification of Other Packages

Altering code in node_modules of other dependencies
Injecting backdoors into libraries used in production

Impact: Compromise at scale, propagation of the attack to all application users.

6. In CI/CD Environments

Access to pipeline secrets (tokens, credentials)
Ability to modify build artifacts or Docker images
Deployment of compromised versions to production

Impact: Compromise of the entire delivery chain, from build to production.

Documented Real-World Cases

Case	Year	Description
event-stream	2018	Package with ~2M weekly downloads. Malicious code added to steal Bitcoin wallets.
ua-parser-js	2021	Popular library compromised; ran cryptocurrency miner.
coa and rc	2021	Typosquatting; packages stole environment variables and sent them to a remote server.
node-ipc	2022	Added code that modified files on machines of developers from certain geographic regions.

Protection Measures

Use --ignore-scripts when possible: npm install --ignore-scripts
Audit dependencies: npm audit, npm audit fix
Verify scripts: npm view package-name before installing
Specialized tools: Socket.dev, Snyk for detecting suspicious behavior
Keep package-lock.json in version control and review changes
Verify package provenance: download counts, active maintenance, open repository

Conclusion

The npm ecosystem is extremely convenient, but that convenience carries risks. The seemingly trivial act of npm install can execute arbitrary code on your machine. Awareness of supply chain attacks and adopting security best practices are essential to reduce the attack surface and protect projects and infrastructure.

The demonstration project is available so you can test the flow in a controlled environment and understand how these attacks work in practice.

This article was written for educational purposes. The demonstration project contains only simulated code and does not perform any real malicious actions.

Hi, I created Cyber Alerts, a collaborative website for reporting scams. The goal is to prevent more people from falling into traps. Feedback and ideas for improvement are very welcome 🚀 https://cyber-alerts.com.br

Ronaldo Modesto — Mon, 22 Dec 2025 16:43:13 +0000

CyberAlert: Mapa Comunitário de Golpes | Segurança Digital Colaborativa

Plataforma colaborativa para reportar e mapear golpes digitais em tempo real. Proteja-se e ajude a proteger outros.

cyber-alerts.com.br

Plataforma Para Reportar Golpes: Cyber Alerts 🛡️

Ronaldo Modesto — Mon, 22 Dec 2025 13:38:27 +0000

Hi everyone, how are you?

With the end of the year approaching and some free time to spare, I finally managed to bring to life an idea that had been on hold: Cyber Alerts.

The Problem
We know that, with the use of AI, scams are becoming increasingly sophisticated (deepfakes, personalized phishing, etc.). I believe that the best defense, besides technology, is shared information.

The Solution
I created this platform so that anyone can quickly report scams they've suffered. The goal is to create a community database where people can consult recent tactics and avoid falling into traps.

What's coming next?

The platform is simple and intuitive.

I will soon add support for multiple languages (English is next on the list).

I am open to suggestions for new features (filters by category, integration with security APIs, etc.).

Project link: https://cyber-alerts.com.br

Suggestions for improvement, stack ideas, or constructive criticism are very welcome! As this community is tech-oriented, I'd love to know what you think of the usability and the project's concept 🙂.

Ebook: Desenvolvimento Seguro de Apis

Ronaldo Modesto — Wed, 19 Mar 2025 21:49:23 +0000

Olá, pessoal! Tudo bem? 😀

Hoje quero apresentar um projeto no qual venho trabalhando há algum tempo.

Desde que a onda da inteligência artificial começou, muitos desenvolvedores passaram a utilizar assistentes de código para criar suas aplicações. Isso é ótimo, pois aumenta consideravelmente a produtividade. No entanto, essa prática também esconde um grande perigo: falhas de segurança.

Infelizmente, a maioria dos desenvolvedores não se preocupa em validar o que a IA gera, e, com isso, muitas vulnerabilidades acabam indo para ambientes de produção, resultando em softwares com diversas brechas.

Outro ponto que me incomoda ao pesquisar sobre cibersegurança é que a maioria dos sites ensina apenas a detectar vulnerabilidades, mas não oferece soluções eficazes para corrigi-las.

Pensando nisso, criei este eBook, onde abordo várias falhas comuns em APIs. Diferente de outros materiais, não apenas mostro as vulnerabilidades, mas também explico em detalhes como elas surgem e apresento exemplos de código para mitigá-las. Dessa forma, qualquer desenvolvedor poderá identificar e corrigir essas falhas em qualquer tecnologia.

Se quiser adquirir o eBook, basta acessar minha página de vendas. Por um valor simbólico de R$ 49,90, você terá acesso a um conteúdo valioso.

Aqui está um exemplo do que você encontrará no eBook:

Na imagem a seguir, apresento uma explicação detalhada sobre a vulnerabilidade de Path Traversal, uma falha muito comum e extremamente perigosa em APIs.

Com este eBook, você aprenderá a identificar e corrigir essa e muitas outras vulnerabilidades 🚀🚀.

Caso queira adquirir o ebook pode fazê-lo aqui

https://rm-ebook-api-development.com.br

Espero que esse ebook possa te ajudar a escrever códigos melhores e mais seguros tanto para projetos pessoas quanto profissionais 🙂

Fiquem bem e até a próxima 🙂

Flappy Bird Multiplyer

Ronaldo Modesto — Thu, 21 Nov 2024 01:34:34 +0000

Hello everyone, how are you? I hope well 😃

Today I'm here to show you something different.
Nothing about cybersecurity or anything like that.
Today I'm here to show you my new project, I'm a flappy bird game with single and multiplayer

➡️ You can find the game here: https://www.multibirds.dev ⬅️

This game was made with the following technologies

io socket
Angular
NestJs
Screen
Nginx
Google AdSense

Basically there are 4 game modes

Single player

The mode where you play alone move to get the highest possible score. This is the classic mode.

Multiplayer Co-op

In this mode you play with a friend, it's a great way to kill time while waiting for something 😃

Multiplayer versus
In this mode you can challenge a friend to see who survived the most, it also looks really cool 🙂

Practice Mode

In this mode you can practice withowt dying and you can play as long as you want.

How to play

To play, just copy your ID and send it to a friend or ask him to send you his ID and you can call him to play.
No need to create an account or anything like that, just come and play :)

Well that's it for today guys, I just wanted to present this little project that I intend to improve in the future, I have some really cool ideas, I just need time.
Here are some screeshots, but this is a work in progress and will be updated soon :)

Stay safe and see you next time 😃

Removendo Dados Sensiveis de Images

Ronaldo Modesto — Fri, 17 May 2024 22:01:33 +0000

Hoje quero falar sobre um tema importante quando falamos em segurança de dados e o que podemos fazer para melhorar a nossa segurança de dados quando processamos imagens com dados sensíveis de nossos usuários. Vou apresentar uma solução que construí pensando nessa situação. Vamos nessa 😃

Imagens e Dados Sensíveis

A crescente capacidade de processamento e armazenamento de dados permitiu que empresas capturassem e analisassem um volume imenso de informações, muitas vezes sem o consentimento explícito dos indivíduos envolvidos.

Em termos de cibersegurança, a proteção de dados pessoais em imagens é de suma importância. O vazamento de informações sensíveis, como CPF e e-mail, pode ter consequências desastrosas. Criminosos cibernéticos podem utilizar essas informações para realizar fraudes, roubo de identidade e outras atividades ilícitas. Por exemplo, com um CPF e um endereço de e-mail, um criminoso pode tentar abrir contas bancárias em nome da vítima, solicitar empréstimos ou realizar compras online, tudo isso sem o conhecimento da pessoa afetada.

Além disso, a exposição de dados pessoais pode levar ao assédio e à violação de privacidade. Imagine uma situação onde fotos de uma reunião ou evento são compartilhadas publicamente e nelas estão visíveis documentos ou identificações pessoais. Essas informações podem ser exploradas maliciosamente, comprometendo a segurança e o bem-estar das pessoas envolvidas.

Então, o que fazer?

Sabemos que dados sensíveis em imagens podem ser um problema, então, o que fazer? Anonimizar!

A anonimização de dados em imagens tornou-se uma prática crucial nos dias atuais, especialmente com o crescimento exponencial da coleta de dados por grandes empresas para treinar inteligências artificiais (IA).

Portanto, a anonimização de dados em imagens é uma prática essencial não apenas para proteger a privacidade individual, mas também para garantir a segurança cibernética. Com a intensificação da coleta de dados por grandes corporações para o treinamento de IA, a adoção de medidas rigorosas de anonimização torna-se ainda mais crítica. É responsabilidade das empresas e desenvolvedores implementar técnicas eficazes para garantir que os dados pessoais sejam adequadamente protegidos, preservando a privacidade e a segurança dos indivíduos em um mundo cada vez mais digitalizado.

Anonimizar dados em imagens envolve a remoção ou ocultação de informações identificáveis, como rostos, placas de veículos, endereços de e-mail, números de CPF, entre outros. Essa prática é vital para proteger a privacidade dos indivíduos, impedindo que dados pessoais sejam facilmente associados a pessoas específicas. Com a anonimização, mesmo que as imagens sejam acessadas por terceiros, a possibilidade de identificar e prejudicar os indivíduos retratados é significativamente reduzida.

Com isso queria trazer uma API que construí pensando em viabilizar a anonimização de dados em imagens de forma sistemática.

Ela possui os seguintes endpoints em sua versão V1:

/v1/remove/all: Este endpoint remove todos os textos encontrados na imagem
/v1/remove/cep: Este endpoint remove todos os ceps encontrados na imagem
/v1/remove/cnpj: Aqui são removidos todos os cnpj's
/v1/remove/cpf: Este endpoint remove todos os cpf's
/v1/remove/custom-text: Aqui são removidos textos específicos que o usuário queira
/v1/remove/email: Remove todos os emails

-/v1/remove/face: Este endpoint remove todos os rostos detectados na imagem

/v1/remove/ipv4: Aqui são removidos os ipv4's que forem encontrados
/v1/remove/phone: Remove todos telefones
/v1/remove/rg: Remove todos os numeros de rg (por enquanto apenas Minas Gerais)

Caso queira acessar a API para checar todas as features e apoiar meu trabalho é só dar uma conferida aqui 😃

==>>>DOCK ANONYMIZE API<<<==

Anonimizando dados

Agora vamos explorar como utilizar a API para anonimizar dados em exemplos de imagens contendo informações sensíveis de usuários.

CPFs
Os CPFs são informações extremamente confidenciais e toda empresa deve garantir que essas informações não sejam vazadas na internet. A seguir, apresentamos um exemplo de anonimização de CPF em uma imagem de um contrato de trabalho. Este poderia ser um documento escaneado real.

Imagem original

Imagem anonimizada

Emails
Os emails também são informações que podem ser divulgadas inadvertidamente. Se for intencional, como na divulgação de um email de contato para um serviço, não há problema. Porém, quando se trata de emails pessoais, existe o risco de que pessoas maliciosas os utilizem para criar cadastros em diversos sites ou até mesmo realizar compras online.

Imagem original

Imagem anonimizada

Mais Exemplos
Agora, vamos ver um exemplo de uma tela de sistema que pode conter informações pessoais do usuário ou da empresa cujo cadastro está sendo acessado.

Perceba que na imagem original existem diversas informações de cunho pessoal, como CNPJ, email, CEP, entre outras.

Imagine que você possui um serviço que lida com muitas imagens semelhantes (por exemplo, um serviço que processa notas fiscais e depois as armazena). Para garantir a segurança das informações do cliente, você pode anonimizar alguns dados. Neste caso, vamos anonimizar campos como email, CNPJ e um valor arbitrário, como o limite de crédito.

Imagem anonimizada

Como pode ser visto é possível anonimizar de forma sistemática dados sensíveis em imagens, garantindo assim, a privacidade dos dados dos usuários.

Casos de uso

Trago aqui mais alguns casos de uso onde pode ser extremamente necessário a anonimização dos dados presentes.

Processamento de Documentos Fiscais
Empresas que lidam com um grande volume de documentos fiscais (notas fiscais, recibos, etc.) podem precisar anonimizar dados sensíveis antes de armazená-los ou compartilhá-los com terceiros.
Segurança em Sistemas de RH
Sistemas de Recursos Humanos que gerenciam documentos como contratos de trabalho, formulários de cadastro de funcionários, e declarações de imposto podem anonimizar informações sensíveis para proteger a privacidade dos funcionários.
Compliance com Regulamentações
Organizações que precisam cumprir regulamentações de proteção de dados (como a GDPR na Europa ou a LGPD no Brasil).
Serviços de Armazenamento em Nuvem
Provedores de serviços de armazenamento em nuvem podem querer oferecer um nível adicional de segurança, garantindo que dados sensíveis em documentos escaneados sejam automaticamente anonimizados antes de serem armazenados.
Aplicativos de Telemedicina
Plataformas de telemedicina que processam imagens de documentos médicos (receitas, laudos, etc.) podem anonimizar dados pessoais dos pacientes para proteger a privacidade e garantir a segurança das informações médicas.
Gestão de Imóveis
Empresas de gestão imobiliária podem querer anonimizar dados sensíveis em documentos como contratos de aluguel e comprovantes de residência antes de compartilhá-los com partes interessadas.
Bancos e Instituições Financeiras
Bancos podem anonimizar dados em imagens de documentos financeiros (extratos bancários, contratos de empréstimo) para proteger a privacidade dos clientes ao realizar auditorias ou ao compartilhar informações internamente.
Sistemas de Educação
Instituições de ensino podem anonimizar dados em documentos estudantis (boletins, registros acadêmicos) ao compartilhar informações com terceiros ou ao armazená-las de forma segura.
Agências Governamentais
Agências governamentais podem anonimizar dados em documentos oficiais (identidade, passaportes, declarações de imposto) antes de processá-los ou arquivá-los para garantir a privacidade dos cidadãos.
Aplicações Jurídicas
Escritórios de advocacia e tribunais podem precisar anonimizar informações sensíveis em documentos legais (petições, contratos, depoimentos) para proteger a privacidade das partes envolvidas.
Plataformas de Crowdsourcing
Plataformas que utilizam crowdsourcing para processamento de dados podem anonimizar informações sensíveis em documentos submetidos pelos usuários para garantir a segurança e privacidade durante o processo de revisão.
Serviços de Análise de Dados
Empresas que oferecem serviços de análise de dados podem anonimizar informações sensíveis em documentos antes de realizar análises, garantindo que nenhum dado pessoal seja comprometido.

Conclusões

Com isso podemos ver que em várias situações pode ser bom, e até necessário, a anonimização de dados em imagens, principalmente quando falamos de documentos.

Se você trabalha com iamgens que podem conter dados sensíveis sempre considere a anonimização dos dados pois assim você colabora para a privacidade dos dados de seus usuários, além de evitar possíveis multas ou outros problemas decorrentes de vazamentos de dados 💯

Bom por hora é isso, fiquem bem e até a próxima 🙂

Otimizando Wordlists para Pentests

Ronaldo Modesto — Sat, 02 Mar 2024 20:48:12 +0000

Olá, espero que este artigo encontre você e seus familiares todos bem e cheios de saúde 🙂.
Hoje vamos falar sobre ataques de força bruta e como otimizar as wordlists utilizadas para conseguir ser mais assertivo em seus testes.
Sem mais delongas, bora lá 💯.

Responsabilidade

Antes de mais nada quero deixar bem claro que fiz esta ferramenta pensando em auxiliar pentesters e pessoas que queiram realizar estes testes em seus próprios sistemas.
O que você fizer com ela é responsabilidade única e exclusivamente sua, ok?

O que é um ataque de força bruta (Brute Force Attack)

Primeiro vamos começar definindo o que é um ataque do tipo brute force e em quais casos ele geralmente é utilizado.

Um ataque de força bruta é um método de tentativa e erro usado para descobrir uma senha o chave criptográfica ao testar todas as combinações possíveis em rápida sucessão. Geralmente, esse tipo de ataque é automatizado através de programas ou scripts que tentam todas as combinações de caracteres, números e símbolos em uma sequência exaustiva até que a senha correta seja encontrada.

Os ataques de força bruta são comumente usados em situações em que um invasor deseja obter acesso não autorizado a sistemas protegidos por autenticação baseada em senha. Alguns casos típicos de uso incluem:

Quebra de senha: Tentar descobrir a senha de uma conta de usuário ou administrador em sistemas online, como redes sociais, e-mails, bancos de dados, entre outros.
Quebra de criptografia: Tentar quebrar chaves criptográficas ao decifrar mensagens ou arquivos criptografados.
Descoberta de chaves de segurança: Tentar encontrar a chave de segurança de uma rede sem fio protegida por criptografia WEP, WPA ou WPA2.
Acesso não autorizado a sistemas: Tentar ganhar acesso não autorizado a sistemas, servidores ou dispositivos protegidos por senha, como roteadores, firewalls, etc.

Em resumo, ataques de força bruta são uma técnica de invasão que explora a vulnerabilidade de senhas fracas ou algoritmos de criptografia ineficientes, visando obter acesso não autorizado a sistemas e informações sensíveis.

Wordlists e sua importância neste tipo de ataque

As wordlists desempenham um papel crucial nos ataques de força bruta, fornecendo uma lista predefinida de palavras ou combinações de caracteres que são usadas como tentativas durante o processo de tentativa e erro para descobrir uma senha ou chave.

Essas listas podem conter uma ampla variedade de informações, incluindo:

Palavras comuns: Palavras frequentemente usadas em senhas, como "password", "123456", "qwerty", entre outras.
Dicionários de idiomas: Palavras de dicionários de diferentes idiomas são frequentemente incluídas, pois muitas pessoas usam palavras do seu próprio idioma como senha.
Combinações de caracteres: Sequências de caracteres como números, letras maiúsculas e minúsculas, símbolos, e suas combinações.
Padrões: Sequências de caracteres que seguem padrões comuns, como datas de nascimento, nomes próprios, palavras seguidas de números, entre outros.
Ao usar uma wordlist durante um ataque de força bruta, o processo de tentativa e erro é agilizado, pois o atacante não precisa gerar as combinações de caracteres manualmente, aumentando as chances de sucesso.

O lado ruim...

Bom como sabemos bem, tudo na vida tem um preço 😅.
Neste caso o lado ruim desse tipo de ataque é o tempo!! Existem vários tipos de wordlists por ai e seus tamanhos variam de algumas linhas a milhões de registros. Dependendo do poder de processamento do seu alvo, no caso de um teste de brute force contra algum serviço, ou do poder de processamento de seu computador no caso de ser um brute force local, a conclusão desse teste pode durar horas ou até mesmo dias!! O que por mais que você tenha tempo disponível para isso é meio complicado esperar horas para descobrir que a senha que você procura não está naquela wordlist. Se por um lado wordlists maiores aumentam a chance de sucesso, por outro elas aumentam também o tempo de execução do teste, e isso algo que definitivamente não queremos.
Então o que podemos fazer ? Bom aí vem uma coisa chamada OsInt 🙂

Osint

OSINT (Open Source Intelligence),ou inteligência de fontes abertas, refere-se à prática de coletar e analisar informações de fontes disponíveis ao público para obter insights e conhecimentos úteis. Essas fontes podem incluir redes sociais, sites da internet, fóruns online, notícias, registros públicos, e qualquer outra informação acessível ao público em geral, sem a necessidade de técnicas de invasão ou acesso não autorizado.
Ou seja, significa tentar descobrir características que podem ser utilizadas para inferir informações acerca da senha ou dado que você busca. Trazendo isso para um contexto de pentest, imagine que você deseja testar a segurança de um site x, e você vai tentar fazer um brute force para ver como está a segurança das senhas dos usuários.

Se você pegar uma wordlist genérica de 5 milhões de senhas, você pode acabar demorando demais e consumindo muito recurso de processamento para, no fim, não achar nenhuma senha que batesse para determinado login. Porém, você, como um bom pentester, resolveu ir lá no site e dar uma olhadinha para ver se conseguia descobrir algo sobre a senha daquele site. Você tenta criar uma conta e quando é questionado sobre a senha, insere uma senha qualquer e boom! O site te retorna uma mensagem dizendo que as senhas que ele aceita possuem um formato específico, geralmente algo parecido com isso:

Ou seja, sobre esse site x, agora você sabe que não adianta testar senhas como 123, ou teste1234 pois as senhas precisam ter, pelo menos, letras minúsculas, maiúsculas entre outras combinações.
Com isso você sabe que de alguma maneira precisa limpar a wordlist que vai ser utilizada senão tudo que vai conseguir é perder tempo. E como podemos fazer isso ? 🤔
Aí vem a uma ferramenta bem bacana, e simples, que fiz pensando nessa situação 🙂.

Wordlist Optimizer

Pensando nessa situação resolvi aproveitar que estou iniciando meus estudos em Go, que é uma linguagem compilada e por isso gera programas que possuem excelente performance, e criei uma ferramenta bem simples para ajudar nessa tarefa.
Basicamente o wordlist optimizer é uma cli ( programa de linha de comando) que filtra dados de uma worldlist baseado em um filtro que você monta passando algumas flags como por exemplo, -l para letras minúsculas , -c para lestras maiúsculas, entre outras opções. A documentação completa você encontra no repositório da ferramenta no github WorlistOptimizer.
Com ela você pode criar filtros para selecionar apenas linhas que atendam, minimamente, ao que você quer.
No exemplo a seguir eu filtrei a wordlist teste.txt para recuperar apenas as linhas que tivessem letras maiúsculas, números e tamanho mínimo de 5 caracteres. Senhas como teste123, teste3444 ficariam de fora desse filtro e não seriam gravadas no arquivo de saída teste-optimized.txt.
Essa será nossa wordlist teste.txt

Ao terminar de executar a ferramenta exibe as estatísticas do processamento dos dados

Esse é o arquivo gerado com todas dos dados que deram match( minimamente) com o filtro passado.

E esse é o arquivo gerado como complemento do arquivo de match, ou seja, são todos os dados que não deram match.
É importante ter esse arquivo pois quando estamos fazendo pentest real, o as wordlists podem ser muito grandes, na casa de milhões e milhões e as vezes até mais, então é importante ir segmentando seu teste para caso você mude de estratégia já ter esses dados filtrados.

Como vocês podem ver, no arquivo removed-teste.txt estão as senhas que não deram match no filtro.
Com essa simples ação você pode tornar seu teste muito mais efetivo, reduzindo o tamanho da sua wordlist e economizando processamento de seu alvo de testes 😃.

E uma última dica é, sempre que for realizar um pentest e precisar utilizar utilizar um brute force, tome cuidado para não sobrecarregar o sistema de seu cliente, pois como ataques de forças bruta operam através de tentativa e erro, é normal que ele erre muito (mas muuuuuuito) antes de acertar, não é atoa que as wordlists possuem facilmente milhões e milhões de dados. Se conduzido de forma errada o seu teste pode ser mais prejudicial do que um ataque legítimo 😅.

Além disso, deixo aqui uma sugestão para os programadores e arquitetos de software: sempre considerem a implementação de um RATE LIMIT em suas aplicações. Em um cenário de ataque mal-intencionado, é esse rate limit que cuidará para que sua aplicação não seja comprometida. Embora não exista uma solução única em segurança e haja métodos para burlar o rate limit, ter um rate limit configurado em sua aplicação ou WAF (Web Application Firewal) é uma prática recomendada.

Bom por hoje é isso, espero que essa dica e essa ferramenta possam tornar seus testes mais efetivos 🚀. Segue aí para mais dicas 🙂.

Fiquem bem, estudem bastante e descansem a cuca também porque a vida é para ser aproveitada 💯.

Obrigado por chegar até aqui e até a próxima 🚀

Referências

OsInt (Owasp)

BruteForce (owasp)

Exemplos de wordlists (github)

Web Application Firewall (cloudflare)

Protegendo sua API NodeJs contra ReDos Attack[Parte 3]

Ronaldo Modesto — Thu, 26 Jan 2023 16:52:10 +0000

Ok! Vimos o que é uma expressão regular, como utilizá-la, o que é um ReDos e como podemos resolver esse problema!

Caso você tenha caído aqui de paraquedas, seguem os links para as duas primeiras partes desse artigo:
Parte 1 (Definição do problema)
Parte 2 (Construção de uma possível solução)

Agora chegou a hora de testar nossa solução e fazer algumas considerações acerca da mesma. Bora ver se o que construímos de fato funciona ? 🙂

Primeiramente vamos executar o mesmo teste que fizemos quando utilizamos a abordagem que acabava travando toda a nossa API.
Conforme podemos ver a seguir, ao utilizar o mesmo payload que causou problemas anteriormente, dessa vez nosso sistema não sofreu com nenhum impacto pois a thread que acabou travando foi a thread da micro vm que criamos, e dado que acabou gerando um timeout, nós apenas recebemos uma mensagem dizendo que um timeout ocorreu, mas nossa API segue firme e forte 💪.

Nosso endpoint de teste de responsividade também continua a todo vapor.

Ok vimos que de fato nossa API não está mais travando quando recebe um payload malicioso. Porém temos que nos fazer seguinte pergunta, Ok, funcionou, mas essa solução é escalável?, sempre que implementamos uma solução para um dado problema.

Então vamos testar a responsividade de nossa API sob alta carga e para isso vamos usar uma ferramenta de teste de carga chamada K6.

O K6 é uma ferramenta utilizada para testar aplicação com diferentes cenários de teste de carga(teste de absorção, teste de estresse dentre outros). É uma ótima ferramenta e sugiro, para aqueles que não a conhecem, ler mais a respeito desse carinha. Clique aqui e conheça o K6.

A seguir temos o nosso arquivo de teste de carga. É um teste simples, basicamente vamos testar nossa API contra uma quantidade considerável de requisições simultâneas e ver como ela se comporta no que diz respeito à memória e uso de CPU.

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "2m", target: 250 }, // Simula um aumento de 0 até 100 requisições, em um período de 2 minutos
    { duration: "2m", target: 300 }, // Permaneçe em 300 requisições por 2 min
    { duration: "1m", target: 0 }, // Desce para 0 requisições ao longo de 1 minuto
  ],
};

const BASE_URL = "http://192.168.2.176:3000"; // Aqui eu coloquei o ip do computador que estava rodando a api, utilizei um outro computador para rodar o teste para garantir que não haveriam interferências

export default () => {
  const headers = { "Content-Type": "application/json" };

  // Primeiro envio um payload malicioso, simulando um ataque
  const maliciusPatternResult = http.post(
    `${BASE_URL}/validate-form-safe`,
    JSON.stringify({
      email: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@gmail.com",
      password: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    }),
    { headers: headers }
  );

  // Verifico para ver se recebi um timeout como resposta
  check(maliciusPatternResult, {
    "Bad-request-blocked-successfully": (response) => {
      return (
        JSON.parse(response.body).message === "Email ou senha são inválidos"
      );
    },
  });

  // Depois envio um payload válido paar verificar se a api está funcionando como deveria e não foi prejudicada pelo payload malicioso enviado anteriorment

  const validPatternResult = http.post(
    `${BASE_URL}/validate-form-safe`,
    JSON.stringify({
      email: "email-valido@gmail.com",
      password: "ab.cd.Zz",
    }),
    { headers: headers }
  );

  // Aqui verifico a resposta para checar se a resposta foi correta
  check(validPatternResult, {
    "Valid-Pattern-Accepted-successfully": (response) =>
      JSON.parse(response.body).isValidForm === true,
  });

  // Por fim faço uma requisição para o endpoint de checagem da api, para ver e ele ainda está respondendo
  const serverCheckResponse = http.get(`${BASE_URL}/test-server`).json();

  // e verifico se ele de fato está ativo
  check(serverCheckResponse, {
    "servidor responsivo": (obj) =>
      obj.message === "Servidor está respondendo normalmente",
  });

  sleep(1); // apenas um pequeno timer entre uma iteração do teste e outra
};

Após rodar o teste de carga em outro computador para não afetar o desempenho de nossa API, utilizando um computador com processador de 4 núcles e 8GB de RAM, além de ter subido a nossa API utilizando o gerenciador de processos PM2 que consegue subir as aplicações NodeJs em forma de cluster, caso não conheça o PM2, clique aqui e confira, consegui uma taxa de 300 request/segundo o que é um resultado considerável considerando o que computador não era muito forte e considerando que internamente o nodeJs tem sim um overhead a mais para executar esse script em um contexto separado. Cumprimos nosso objetivo 🙂.

Considerações e dicas

Essa solução que foi apresentada aqui é extensível para outras tarefas que podem ser bloqueantes, (cálculo de hashes por exemplo). Se você não tem certeza de que aquela operação será rápida ou se pode ou não ser bloqueante, a solução apresentada neste artigo pode ser uma forma de garantir que seu sistema não irá travar.

Aqui vão algumas dicas que podem ajudar a manter essa falha longe de suas APIs NodeJs.

Não escreva sua própria regex: Evite criar suas próprias reges, principalmente se você não for expert em expressões regulares, pois a chance de você acabar criando um regex com essa falha é muito grande.
Use expressões regulares já prontas e validadas: Essa é um complemento à dica 1. Se precisar validar algo procure por expressões regulares que já foram validadas contra esse tipo de falha, e até mesmo outras falhas.
Use validadores: Existem validadores já pronto que podem validar uma grande variedade de padrões e é muito provável que já exista um validador para o que você quer. Por exemplo:
Validator.js
Safe Regex
Redos Detector
Valide sua regex caso precise fazer uma: Se você de fato precisar construir sua própria expressão regular então tente validá-la para saber se ela está vulnerável a essa falha. Alguns são:
Devina
RedosDetector
Recheck

E por fim, a mais importante dica de todas 🙂

Entenda o que ela está fazendo!!! Estude sobre a expressão que você quer usar, identifique o que ela está reconhecendo e como ela o está fazendo, estude expressões regulares para que você pelo menos consiga dizer o que aquela expressão está validando.

E esse conselho se estende a todas as coisas que você precisar utilizar, evite copiar e colar coisas sem saber o que aquilo está fazendo pois você pode acabar inserindo brechas de segurança em seu sistema 🙂.

Bom por hoje foi isso pessoal, espero que esse artigo lhe ajude de alguma forma, fiquem com Deus e ate a próxima 🙂.

Protegendo sua API NodeJs contra ReDos Attack[Parte 2]

Ronaldo Modesto — Thu, 26 Jan 2023 16:52:09 +0000

Ok!
Na primeira parte deste artigo vimos o que é uma expressão regular e o que é o ReDos. Caso você não tenha visitado ainda essa parte convido você a dar uma olhadinha lá para se contextualizar antes de avançar nesta segunda parte do artigo.
Para acessá-la clique AQUI.
Vem comigo que agora vamos resolver esse problema 🙂

Mitigando o risco
Beleza! Sabemos o que é ReDos e como ele é feito agora vamos ver o que podemos fazer para resolver essa situação.

Existem algumas soluções possíveis, como por exemplo validar a expressão regular para ver se ela é vulnerável ou não à esse tipo de ataque. Porém é muito difícil ter 100% de certeza de que uma dada expressão é 100% segura pois esse ataque se baseia na entrada enviada pelo usuário e existem infinitas possibilidades para isso.

Também podemos tentar limitar o tamanho do input mas isso também é ineficaz, existem padrões de regex que podem travar com strings de tamanho 3 ou até menor! Então o que fazer ? Simples!
Vamos utilizar uma micro vm para compilar o código da regex em outra thread fora da thread principal para que assim nossa aplicação não seja comprometida em caso de recebermos um payload que não podemos avaliar.

Mas chega de falar!! Vem comigo que vou te mostrar isso na prática.

Projeto de testes
Para testar essa situação vamos utilizar uma API simples construída em NodeJs utilizando o framework minimalista Express.
Mais informações sobre o Express AQUI.
Será uma API que terá como objetivo validar o formato de um e-mail e de uma senha utilizando para isso expressões regulares.
Ela possui 3 endpoints, sendo eles:

/validate-form-unsafe: Esse endpoint utiliza as formas *erradas de se utilizar regex para fazer validações. Será utilizado para mostrar como isso pode afetar negativamente o sistema.

/validate-form-safe: Esse endpoint será utilizado para testar se nossa proposta de solução de fato funciona.

/test-server: Esse endpoint será utilizado para testar a responsividade do nosso servidor.

Lembrando que é apenas uma API de exemplo então existem coisas que podem ser melhor trabalhas sim, mas não daremos foco nisso, ok ?
Caso queira baixar ou fazer clone do repositório é só clicar AQUI
No nosso exemplo vamos utilizar as seguintes regex's:

/^([a-zA-Z0-9])(([\-.]|[_]+)?([a-zA-Z0-9]+))*(@){1}[a-z0-9]+[.]{1}(([a-z]{2,3})|([a-z]{2,3}[.]{1}[a-z]{2,3}))$/"gm"

Cujo objetivo é validar se uma data string é um e-mail válido e essa outra regex:

/^(([a-z])+.)+[A-Z]([a-z])+$/

Que é utilizada para verificar se a senha informada está no formato de letra intercalada com ponto, por exemplo "a.b.c.zZ" ou "ab.cc.Zd"

Testes
Quando testamos o endpoint /validate-form-unsafe para uma entrada válida, por exemplo:

{
    "email":"emailvalido@gmail.com",
    "password":"a.b.Cz"
}
```


Tudo flui normalmente. 
Porém se enviamos um payload malicioso, por exemplo:


```
{
    "email":"email-valido@gmail.com",
  "password":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
}
```


Isso é o que ocorre:

![Server not responding](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/19y09duwg7iq99kjpv4h.PNG)
Consultando o endpoint **/test-server** verificamos que nossa API simplesmente não funciona mais 🙂.


![server offline](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/98f76jeoaol1zoesbnhq.PNG)

**Mas afinal, o que aconteceu ?**
Bem, vamos analisar o código atrás de respostas. A função que utiliza regex para validar, de forma errada, é essa:


```
function unsafeValidateForm(email, password) {
  const isEmailValid = validadeEmailRegex.exec(email) !== null;
  const isPasswordValid = validadePasswordRegex.exec(password) !== null;
  return isEmailValid && isPasswordValid;
}
```


O fato de essas expressões estarem sendo avaliadas na thread principal que é o problema. Pois dessa forma, devido ao comportamento de **catastrophic evaluation (Avaliação catastrófica)** ou **catastrophic backtracking( Retorno catastrófico)** o nodeJs fica stagnado alí sem conseguir avançar, com isso ele não consegue atingir as outras fases do EventLoop, não conseguindo processar as requisições que chegam, causando assim a interrupção dos serviços. Lembrando que explico mais detalhes sobre o que é o EventLoop, quais são suas fases e porque não podemos bloqueá-lo de forma alguma no meu outro artigo aqui da dev.to, [clique aqui para acessá-lo](https://dev.to/r9n/entendendo-e-solucionando-o-bloqueio-do-event-loop-no-nodejs-parte-1-3nec)

**Solução**
Bem, e o que podemos fazer para resolver isso ?
Vamos usar um recurso muito bacana para isso que são as node vm's
Caso você não saiba o que é isso, aqui vai uma explicação bem sucinta:

**vm** é um mecanismo através do qual o NodeJs consegue compilar e executar código javascript em um contexto totalmente separado do escopo atual de onde ele é chamado mantendo utilizando o motor da v8, que é sobre o qual ele própio é executado, ainda assim, a capacidade de acessar e modificar variáveis locais. Cada vm possui sua própria thread de execução, executando de forma independente da thread principal.

[Mais sobre vm's](https://nodejs.org/api/vm.html#vm-executing-javascript)

A seguir temos a versão repaginada da nossa função de validação de senha.


```
async function safeValidateForm(email, password) {
  try {
    validateData(email, password);

    const vmVariables = {
      regexResult: false,
    };

    const context = vm.createContext(vmVariables);

    const regexScript = new vm.Script(
      `regexResult = new RegExp(${validadePasswordRegex}, "gm").exec("${password}") !== null &&
     RegExp(${validadeEmailRegex},"gm").exec("${email}") !== null`
    );

    regexScript.runInContext(context, {
      timeout: maxRegexEvaluationTimeoutInMillissecons,
    });
    return vmVariables.regexResult !== null;
  } catch (error) {
    if (error.code == InternalErrorMessages.TIMEOUT) {
      throw new TimeoutError("ValidateForm");
    }
    throw error;
  }
}

```


Essa abordagem tem por princípio executar essa verificação em uma thread separa, por isso usamos aqui uma vm para tal, para assim não corrermos o risco de termos a nossa thread principal bloqueada, levando assim a um completo travamento da nossa API.

Vamos analisar a função nova e verificar o que ela faz. Logo no inicio temos o seguinte trecho de código:


```
  try {
    validateData(email, password);

    const vmVariables = {
      regexResult: false,
    };

   const context = vm.createContext(vmVariables);
```


Aqui nós estamos criando um novo contexto de execução para ser utilizado na vm que vamos utilizar. Caso quiséssemos passar algum valor do contexto atual para a vm seria nessa etapa que deveríamos inserir no contexto criado a informação que quiséssemos injetar.

**!!!ATENÇÃO!!!**

Inputs recebidos do usuário **NUNCA** devem ser passados diretamente para o sistema sem antes receber algum tratamento. A função **validateData** que fiz aqui está vazia pois ela é apenas para lhe lembrar que em produção você deve **sempre** tratar os inputs recebidos, ok ? 
Aqui não vou me ater a isso pois o foco é outro.

A seguir temos o seguinte código:



```
  const regexScript = new vm.Script(
    `regexResult = new RegExp(${validadePasswordRegex}, "gm").exec("${password}") !== null &&
     RegExp(${validadeEmailRegex},"gm").exec("${email}") !== null`
  );

```


Aqui passamos para a vm em forma de string o script que será executado. Repare que esse scrip é justamente a avaliação das expressões regulares que precisamos, justamente com os parâmetros de **email** e **password** que recebemos do usuário e precisamos avaliar.
Repare que no script temos o seguinte trecho "regexResult = new Re..." esse **regexResult** é o mesmo que declaramos no contexto e é ele quem vai receber o valor do resultado da nossa operação. Quando o processamento dessa micro vm terminar nós poderemos acessar esse resultado fazendo **vmVariables.regexResult**, legal né ? 🙂

Por fim temos o trecho de código:



```
 regexScript.runInContext(context, {
      timeout: maxRegexEvaluationTimeoutInMillissecons,
    });
    return vmVariables.regexResult !== null;
  } catch (error) {
    if (error.code == InternalErrorMessages.TIMEOUT) {
      throw new TimeoutError("ValidateForm");
    }
    throw error;
  }
```


Aqui nós executamos o script criado logo acima na micro vm utilizando o contexto criado e então podemos acessar o resultado da execução das regex's fazendo **vmVariables.regexResult**.
O importante aqui é notar a propriedade **timeout** que é justamente o que nos faz conseguir continuar processando coisas, mesmo que essa micro vm acabe travando pois ao se chegar ao tempo limite definido em **maxRegexEvaluationTimeoutInMillissecons**, que no nosso caso está configurado para 50, a vm é morta e um erro é lançado. Esse erro lançado e capturado no bloco de catch  e então fazemos o tratamento dele, lançando um erro personalizado de timeout.

E basicamente é assim que podemos tratar uma regex que não sabemos se irá travar ou não, ou até mesmo outra task que poderia comprometer nossa aplicação.

Agora que vimos como podemos resolver esse problema vamos testar nossa solução e ver se ela de fato funciona. 
Mas isso fica para a parte 3 pois por aqui já foram muitas informações. Abaixo você encontra o link para a terceira e ultima parte desse artigo. Te espero lá 🙂.

[TerceiraParte](https://dev.to/r9n/protegendo-sua-api-nodejs-contra-redos-attackparte-3-40g7)