Web Security Basics Every Developer Must Know — txt1.ai

Por Marcus Chen, Engenheiro Sênior de Segurança em uma empresa fintech da Fortune 500 com 12 anos de experiência em fortalecer aplicativos web que processam mais de $2 bilhões em transações diárias

Três anos atrás, vi um desenvolvedor júnior enviar código para produção às 16:47 de uma sexta-feira. Às 18:15, nosso centro de operações de segurança estava aceso como uma árvore de Natal. Uma vulnerabilidade de injeção de SQL em uma funcionalidade de pesquisa aparentemente inofensiva havia exposto 340.000 registros de clientes. A violação nos custou $4,2 milhões em remediação, multas regulatórias e negócios perdidos. O desenvolvedor? Um engenheiro brilhante que simplesmente não sabia o que não sabia sobre segurança na web.

Esse incidente mudou a maneira como abordo a educação em segurança. Percebi que a maioria dos desenvolvedores não é imprudente—eles estão apenas operando em um vácuo de conhecimento. Programas de ciência da computação gastam talvez duas semanas em segurança, se você tiver sorte. Bootcamps muitas vezes a ignoram completamente. No entanto, somos esperados para construir fortalezas enquanto apenas sabemos como empilhar tijolos.

Passei a última década nas trincheiras da segurança na web, desde testes de penetração até a construção de frameworks de segurança usados por equipes de mais de 200 desenvolvedores. Eu vi ataques evoluírem de tentativas rudimentares de script-kiddies para operações sofisticadas de estados-nação. E aprendi que os fundamentos—os princípios básicos que todo desenvolvedor deve internalizar—não mudaram tanto quanto você poderia pensar. Domine esses princípios centrais e você evitará 90% das vulnerabilidades que vejo em código de produção todos os dias.

Entendendo a Superfície de Ataque: O que Você Realmente Está Protegendo

Quando pergunto aos desenvolvedores o que eles estão protegendo, geralmente ouço "dados do usuário" ou "o banco de dados." Isso não está errado, mas está incompleto. Sua superfície de ataque é cada único ponto onde seu aplicativo aceita entrada, processa dados ou interage com sistemas externos. É o formulário de login, sim, mas também é aquele endpoint de API que você escreveu para uso interno apenas, a funcionalidade de upload de arquivos no painel de administração e até mesmo as mensagens de erro que você exibe para os usuários.

Deixe-me dar um exemplo concreto da minha própria experiência. Tínhamos um endpoint de API interno que aceitava cargas JSON para atualizações em massa de usuários. Era "apenas interno"—nenhuma autenticação era necessária porque era acessível apenas pela nossa VPN. Exceto que alguém configurou incorretamente um proxy reverso, e, de repente, esse endpoint ficou exposto à internet por aproximadamente 18 horas antes de sermos capazes de detectar. Durante essas 18 horas, scanners automatizados já o encontraram e tentaram 2.847 vetores de ataque diferentes.

A superfície de ataque inclui cada dependência em seu package.json ou requirements.txt. Quando a vulnerabilidade Log4Shell apareceu em dezembro de 2021, passei 72 horas consecutivas ajudando equipes a identificar e corrigir sistemas afetados. A vulnerabilidade não estava no código que escrevemos—estava em uma biblioteca de registro que era uma dependência de uma dependência de uma dependência. Sua superfície de ataque se estende por toda a sua árvore de dependências, que para uma aplicação Node.js típica pode incluir mais de 800 pacotes.

Pense sobre as fronteiras de confiança do seu aplicativo. Onde os dados não confiáveis entram em seu sistema? Cada campo de formulário, cada parâmetro de URL, cada cabeçalho HTTP, cada cookie, cada corpo de requisição de API. Se vem de fora da memória do servidor, é não confiável. Eu já vi desenvolvedores validarem cuidadosamente as entradas de formulário, mas ignorarem completamente os parâmetros de URL, ou sanitizarem os dados POST, enquanto deixavam os parâmetros GET totalmente abertos. Os atacantes não se importam com o seu modelo mental sobre o que "deveria" ser validado—eles probe tudo.

Sua superfície de ataque também inclui vulnerabilidades baseadas em tempo. Aquele token de redefinição de senha que você gera? Se ele é previsível ou não expira, é um vetor de ataque. Identificadores de sessão, chaves de API, nomes de arquivos temporários—qualquer coisa que um atacante possa adivinhar ou forçar, dado tempo suficiente. Uma vez, encontrei um sistema onde os tokens de redefinição de senha eram apenas inteiros sequenciais. Um atacante poderia solicitar uma redefinição para sua própria conta, ver o token 45231, e então tentar os tokens 45230, 45229, 45228 para redefinir as senhas de outros usuários.

Validação de Entrada: Sua Primeira Linha de Defesa

Se eu pudesse tatuar um princípio na testa de cada desenvolvedor, seria este: nunca confie na entrada do usuário. Nem a entrada do seu aplicativo móvel. Nem a entrada da API do seu "parceiro de confiança." Nem mesmo a entrada do seu próprio JavaScript no frontend. Tudo que cruza uma fronteira de confiança deve ser validado, sanitizado e tratado como potencialmente malicioso até que se prove o contrário.

As vulnerabilidades mais perigosas não são aquelas que hackers encontram—são aquelas que os desenvolvedores não sabem que existem em seu código até que seja tarde demais.

Vejo desenvolvedores cometerem o mesmo erro repetidamente: eles validam a entrada no frontend e assumem que isso é suficiente. Aqui está a realidade—posso contornar sua validação de frontend em cerca de 15 segundos usando ferramentas de desenvolvedor do navegador ou um simples comando curl. A validação de frontend é para a experiência do usuário, não para a segurança. A verdadeira validação acontece no servidor, toda vez, sem exceções.

A validação de entrada eficaz tem três componentes: verificação de tipo, validação de formato e validação de lógica de negócios. A verificação de tipo garante que um campo que espera um número realmente receba um número, não uma string contendo tentativas de injeção de SQL. A validação de formato usa listas de permissão (não listas de negação) para garantir que os dados correspondam aos padrões esperados. Se você espera um endereço de e-mail, valide contra uma regex adequada para e-mails. Se você espera um número de telefone dos EUA, valide o formato explicitamente.

A validação de lógica de negócios é onde a maioria dos desenvolvedores para de pensar. Só porque algo é tecnicamente válido, não significa que faça sentido no contexto do seu aplicativo. Uma vez, revisei um código onde um carrinho de compras permitia quantidades negativas. O desenvolvedor havia validado que a entrada era um inteiro, mas nunca verificou se era positivo. Um atacante poderia "comprar" -100 itens e receber um crédito em vez de ser cobrado. A correção foi trivial, mas a falha custou à empresa $23.000 antes de ser descoberta.

Aqui está minha abordagem prática: defina esquemas rigorosos para cada entrada que seu aplicativo aceita. Use bibliotecas de validação, como Joi para Node.js, Pydantic para Python ou validação integrada em frameworks como Laravel ou Django. Essas bibliotecas permitem que você declare exatamente como é a entrada válida, e elas rejeitam tudo o que não for assim por padrão. Quando a validação falha, registre. Falhas de validação repetidas do mesmo endereço IP ou conta de usuário podem indicar um ataque em andamento.

Mais um ponto crítico: valide em cada camada. Se os dados fluem da sua API para um trabalho em segundo plano para um banco de dados, valide em cada etapa. Eu já vi ataques que exploraram a lacuna entre a validação da API e o processamento de trabalhos em segundo plano. A API validou a entrada corretamente, mas o trabalho em segundo plano assumiu que os dados eram seguros porque vinham do banco de dados. Um atacante que pudesse escrever diretamente no banco de dados (através de uma vulnerabilidade separada) poderia contornar toda a validação.

Autenticação e Autorização: Sabendo Quem e o Que

A autenticação responde "quem é você?" A autorização responde "o que você está autorizado a fazer?" Confundir esses dois conceitos, ou implementá-los de forma inadequada, cria algumas das vulnerabilidades mais exploráveis que encontro. Já vi sistemas com autenticação extremamente segura que permitiam a qualquer usuário autenticado acessar os dados de qualquer outro usuário porque a autorização era uma reflexão tardia.