Fechamos o Bloco XII com quatro classes avançadas que exploram não a injeção, mas como sistemas interpretam requisições, compartilham recursos, manipulam objetos e lidam com o tempo. São vulnerabilidades sofisticadas — HTTP request smuggling, CORS mal configurado, prototype pollution e race conditions — que representam a fronteira do teste web e aparecem nos relatórios de pesquisa mais avançados. O objetivo aqui é conceitual: entender o princípio de cada uma, porque a exploração detalhada é matéria de estudo aprofundado. Pratique nos labs avançados do PortSwigger.

HTTP Request Smuggling

Comece pelo HTTP Request Smuggling, uma das classes mais elegantes e perigosas. Na web moderna, sua requisição frequentemente passa por múltiplos servidores em cadeia antes de chegar ao destino — um servidor de borda (proxy, load balancer, CDN) recebe a requisição e a repassa a um servidor de aplicação. O request smuggling explora discordâncias na forma como esses dois servidores interpretam onde uma requisição termina e a próxima começa. Se o servidor de borda e o de aplicação discordam sobre os limites da requisição (por causa de ambiguidades em como o tamanho da requisição é especificado nos cabeçalhos), um atacante pode "contrabandear" uma requisição escondida dentro de outra — de modo que parte do que ele enviou seja interpretada pelo servidor de aplicação como uma requisição separada, potencialmente afetando outros usuários (envenenando as respostas que eles recebem, sequestrando suas requisições). É um ataque que explora a fronteira de interpretação entre sistemas, e seu impacto pode ser severo justamente porque afeta o processamento de requisições de terceiros.

CORS mal configurado

Em seguida, o CORS mal configurado. O navegador impõe, por segurança, a "same-origin policy" — que impede que um site leia respostas de outro site (protegendo seus dados). O CORS (Cross-Origin Resource Sharing) é o mecanismo que permite relaxar essa restrição de forma controlada, autorizando sites específicos a acessar recursos de outra origem. O problema surge quando o CORS é configurado de forma permissiva demais — por exemplo, refletindo qualquer origem como confiável, ou confiando em origens que não deveria. Uma configuração CORS insegura pode permitir que um site malicioso faça requisições autenticadas à aplicação em nome da vítima e leia as respostas — vazando dados sensíveis. É uma falha de configuração (aula OWASP Top 10: o mapa das vulnerabilidades web) que enfraquece uma proteção fundamental do navegador, e que exige entender a same-origin policy para reconhecer.

Prototype pollution

O prototype pollution é uma vulnerabilidade específica de JavaScript (portanto relevante em aplicações Node.js e front-ends modernos). Em JavaScript, objetos herdam propriedades de um "protótipo", e há uma cadeia de protótipos que remonta a um protótipo base compartilhado. O prototype pollution ocorre quando um atacante consegue modificar esse protótipo base — injetando propriedades que serão herdadas por todos os objetos da aplicação. Ao poluir o protótipo, o atacante pode alterar o comportamento da aplicação de formas inesperadas, potencialmente escalando para negação de serviço, bypass de segurança, ou até execução de código, dependendo de como a aplicação usa os objetos afetados. É uma classe que reflete peculiaridades da linguagem JavaScript e ganhou proeminência com a onipresença do Node.js.

Race conditions: explorar o tempo

Por fim, as race conditions (condições de corrida), que exploram o tempo em vez da lógica. Uma race condition ocorre quando o resultado de uma operação depende da ordem ou do momento de eventos concorrentes, e a aplicação não trata isso adequadamente. O exemplo clássico na web: uma aplicação verifica se você tem saldo suficiente e então debita — se um atacante envia muitas requisições simultâneas na janela entre a verificação e o débito, pode conseguir gastar o mesmo saldo várias vezes (o famoso cenário de resgatar um cupom de desconto múltiplas vezes, ou sacar mais do que tem). O atacante explora a pequena janela de tempo em que a aplicação processa requisições concorrentes de forma insegura. Ferramentas modernas (o Burp tem recursos para isso) permitem enviar requisições quase perfeitamente simultâneas para explorar essas janelas. As race conditions são sutis porque a aplicação funciona perfeitamente em uso normal — a falha só aparece sob concorrência precisa.

A segurança web vai além da injeção

O ponto conceitual que fecha o bloco: essas classes avançadas mostram que a segurança web vai além da injeção. Elas exploram a complexidade dos sistemas modernos — múltiplos servidores em cadeia (smuggling), políticas de compartilhamento entre origens (CORS), peculiaridades de linguagem (prototype pollution), e concorrência (race conditions). O tema unificador não é mais "dado virando instrução", mas algo mais amplo: discrepâncias, suposições e complexidade não gerenciada criam brechas. Cada uma explora uma suposição que a aplicação faz e que não se sustenta — que os servidores concordam sobre os limites da requisição, que as origens são confiáveis, que os protótipos não serão alterados, que as operações são atômicas. Reconhecer suposições implícitas e testá-las é a marca do pentester avançado.

Uma contramedida para cada classe

Do lado defensivo, cada classe tem sua contramedida: contra request smuggling, normalizar como os servidores em cadeia interpretam requisições (usar HTTP/2 de ponta a ponta, configurações consistentes, rejeitar requisições ambíguas); contra CORS, configurar rigorosamente as origens permitidas (allowlist explícita, nunca refletir qualquer origem, nunca combinar credenciais com origem curinga); contra prototype pollution, validar entradas e usar estruturas de dados que não sejam vulneráveis à poluição de protótipo; contra race conditions, usar mecanismos de sincronização adequados (locks, transações atômicas) que garantam que operações críticas não sejam interrompidas por concorrência. A lição defensiva unificada: a complexidade é inimiga da segurança, e sistemas modernos exigem atenção às interações entre componentes, não só a cada componente isolado.

Fecha o grosso do Bloco XII

Com esta aula, encerramos o grosso do Bloco XII — Web e Aplicações. Você percorreu do fundamento (HTTP, OWASP Top 10) às classes clássicas (SQLi, XSS, CSRF, SSRF, command injection, autenticação), à ferramenta (Burp), ao manuseio de arquivos (upload, LFI/RFI), e às classes avançadas (XXE, SSTI, desserialização, smuggling, CORS, prototype pollution, race conditions). A web é o maior campo da segurança, e você agora tem tanto o mapa quanto a profundidade. A aula OAuth, SAML e SSO: atacando a autenticação federada (OAuth/SAML/SSO) complementaria com autenticação federada, mas o núcleo está completo. Vem a seguir um território adjacente e cada vez mais crítico: o Bloco XIII — API Security, porque metade das aplicações modernas é API.

Fontes e leituras recomendadas

  • PortSwigger Web Security Academy — labs de request smuggling, CORS e race conditions
  • OWASP — categoria Security Misconfiguration e o Web Security Testing Guide
  • MDN Web Docs — same-origin policy e CORS
  • Pesquisa sobre prototype pollution em aplicações Node.js

Exercícios

  1. Qual discrepância o HTTP request smuggling explora, e por que seu impacto atinge terceiros?

    ✓ Resposta:

    Explora a discordância entre dois servidores em cadeia (o de borda, como proxy ou CDN, e o de aplicação) sobre onde uma requisição termina e a próxima começa, causada por ambiguidades na forma como o tamanho é especificado nos cabeçalhos. Atinge terceiros porque parte do que o atacante envia é interpretada pelo servidor de aplicação como uma requisição separada, podendo envenenar as respostas ou sequestrar as requisições de outros usuários.

  2. O que a same-origin policy protege, e como um CORS permissivo demais a enfraquece?

    ✓ Resposta:

    A same-origin policy impede que um site leia as respostas de outro, protegendo os dados do usuário. O CORS relaxa essa restrição de forma controlada; configurado de modo permissivo demais — refletindo qualquer origem como confiável ou confiando em origens indevidas — permite que um site malicioso faça requisições autenticadas em nome da vítima e leia as respostas, vazando dados sensíveis.

  3. O que é prototype pollution e por que sua consequência é tão ampla dentro da aplicação?

    ✓ Resposta:

    É uma falha específica de JavaScript em que o atacante modifica o protótipo base do qual todos os objetos herdam propriedades. A consequência é ampla porque as propriedades injetadas passam a ser herdadas por todos os objetos da aplicação, podendo alterar seu comportamento de formas inesperadas — negação de serviço, bypass de segurança ou até execução de código, conforme o modo como a aplicação usa os objetos afetados.

  4. Descreva o mecanismo de uma race condition do tipo "verificar e depois agir", com um exemplo.

    ✓ Resposta:

    Ocorre quando o resultado de uma operação depende da ordem ou do momento de eventos concorrentes e a aplicação não trata isso adequadamente. Exemplo: a aplicação verifica se há saldo suficiente e então debita; enviando muitas requisições simultâneas na janela entre a verificação e o débito, o atacante consegue gastar o mesmo saldo várias vezes (ou resgatar um cupom múltiplas vezes). A falha só aparece sob concorrência precisa, o que a torna sutil.

  5. Qual é o tema unificador dessas quatro classes avançadas, e o que ele revela sobre a marca do pentester avançado?

    ✓ Resposta:

    O tema não é mais "dado virando instrução", e sim "discrepâncias, suposições e complexidade não gerenciada criam brechas": cada classe explora uma suposição que não se sustenta — que os servidores concordam sobre os limites da requisição, que as origens são confiáveis, que os protótipos não serão alterados, que as operações são atômicas. A marca do pentester avançado é reconhecer essas suposições implícitas e testá-las.