A web é, de longe, o maior campo de vulnerabilidades do mundo. Praticamente toda organização tem aplicações web expostas, elas concentram dados valiosos, e a maior parte dos pentests e quase todo o bug bounty (aula Bug bounty e portfólio: transformando conhecimento em carreira) giram em torno delas. Mas você não pode atacar o que não entende — então, antes de qualquer vulnerabilidade, esta aula constrói o modelo mental de como uma aplicação web funciona, com foco no protocolo que a sustenta: o HTTP. Sem dominar HTTP, você decora ataques sem compreendê-los; com ele, você raciocina sobre qualquer falha web. Pratique com o DVWA e o Juice Shop (aula Alvos vulneráveis: conhecendo o campo de batalha).

A arquitetura cliente-servidor

Comece pela arquitetura cliente-servidor da web. Quando você acessa um site, seu navegador (o cliente) envia uma requisição a um servidor, que processa e devolve uma resposta. Mas há camadas que importam para o atacante. O front-end é o que roda no navegador (HTML, CSS, JavaScript) — visível e manipulável pelo usuário, o que é crucial: nada que roda no cliente é confiável, porque o atacante controla o próprio navegador. O back-end é o que roda no servidor (a lógica da aplicação, em PHP, Python, Java, Node...) — invisível ao usuário, e onde as decisões de segurança devem acontecer. E o banco de dados guarda os dados persistentes, consultado pelo back-end. Entender essa separação é fundamental: muitas vulnerabilidades nascem de confiar no que vem do cliente (que o atacante controla) ou de falhas na comunicação entre back-end e banco (SQL Injection).

A anatomia de uma requisição HTTP

O coração de tudo é o HTTP — o protocolo de requisição-resposta da web. Toda interação é uma requisição do cliente e uma resposta do servidor, e você precisa conhecer a anatomia de uma requisição HTTP, porque é o que você vai manipular em cada ataque:

POST /login HTTP/1.1                    ← método + caminho + versão
Host: exemplo.com                        ← cabeçalhos (headers)
Cookie: session=abc123
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0...

usuario=admin&senha=1234                 ← corpo (body), com os dados enviados

Os métodos HTTP indicam a intenção: GET (buscar dados — os parâmetros vão na URL), POST (enviar dados — vão no corpo), PUT/DELETE (modificar/remover), entre outros. Os cabeçalhos carregam metadados (o Cookie de sessão, o tipo de conteúdo, o User-Agent). E o corpo carrega os dados enviados. Cada uma dessas partes é um ponto onde o atacante pode injetar entrada maliciosa — e cada vulnerabilidade web, no fundo, explora como o servidor processa alguma parte dessa requisição que o atacante controla.

Estado e sessões num protocolo stateless

Um conceito central para segurança web é o estado e as sessões. O HTTP é stateless (sem estado) — cada requisição é independente, o servidor não "lembra" da anterior. Mas aplicações precisam lembrar quem você é (você loga uma vez e permanece logado). A solução são os cookies de sessão: ao logar, o servidor te dá um identificador de sessão (um cookie), que seu navegador reenvia em cada requisição, e o servidor usa para te reconhecer. Esse cookie de sessão é, essencialmente, a sua identidade naquela aplicação — e por isso é um alvo cobiçado: roubá-lo (via XSS, aula Cross-Site Scripting (XSS): injetando no navegador da vítima) ou forjá-lo permite se passar por você. Muitas vulnerabilidades web (sequestro de sessão, CSRF, falhas de autenticação) giram em torno de como as sessões são gerenciadas.

O que os códigos de status revelam

As respostas HTTP também comunicam muito, começando pelos códigos de status: 200 (OK, sucesso), 301/302 (redirecionamento), 403 (proibido), 404 (não encontrado), 500 (erro do servidor). Esses códigos são pistas constantes para o atacante — um 403 revela que algo existe mas está protegido; um 500 revela que sua entrada quebrou algo no servidor (frequentemente o primeiro sinal de uma injeção); a diferença de resposta entre duas requisições é o que revela vulnerabilidades "cegas". Aprender a ler as respostas HTTP — códigos, cabeçalhos, corpo, tempo de resposta — é tão importante quanto construir as requisições.

A superfície de ataque web

Por fim, a superfície de ataque web e as tecnologias modernas. Aplicações modernas frequentemente separam front-end e back-end via APIs (Bloco XIII), usam frameworks (que trazem suas próprias vulnerabilidades e proteções), e dependem de muitos componentes. A superfície inclui cada ponto de entrada de dados: campos de formulário, parâmetros de URL, cabeçalhos, cookies, uploads de arquivo, APIs. O mapeamento dessa superfície (quais páginas, parâmetros, funcionalidades existem) é o reconhecimento web — feito com spidering/crawling (mapear a aplicação), análise do JavaScript do front-end (que revela endpoints e lógica), e ferramentas como o Burp Suite (aula Burp Suite: a bancada de trabalho do pentester web). Cada ponto de entrada é uma hipótese de vulnerabilidade a testar.

Nunca confie na entrada do usuário

Do lado defensivo, entender a arquitetura web fundamenta o princípio de segurança web mais importante, que recorre em todo o bloco: nunca confie na entrada do usuário. Como o atacante controla o cliente (o navegador) e pode forjar qualquer requisição (com ferramentas, ignorando as validações do front-end), toda validação e decisão de segurança deve ocorrer no back-end. As defesas transversais que veremos derivam disso: validação e sanitização de entrada no servidor, gerenciamento seguro de sessões, uso correto de HTTPS (Bloco IV), e cabeçalhos de segurança. A lição: a web é insegura por natureza (um protocolo aberto, um cliente hostil controlável), e a segurança web é a disciplina de processar com desconfiança tudo que atravessa essa fronteira.

Fontes e leituras recomendadas

Exercícios

  1. Diferencie front-end e back-end quanto a onde rodam e por que "nada que roda no cliente é confiável".

    ✓ Resposta:

    O front-end roda no navegador (HTML/CSS/JS), visível e manipulável pelo usuário; o back-end roda no servidor (lógica da aplicação), invisível ao usuário. Nada que roda no cliente é confiável porque o atacante controla o próprio navegador e pode alterar ou ignorar o que o front-end faz, forjando requisições à vontade.

  2. Descreva a anatomia de uma requisição HTTP (método, caminho, cabeçalhos, corpo) e o papel de cada parte.

    ✓ Resposta:

    Uma requisição tem: método (a intenção — GET busca, POST envia), caminho (o recurso alvo), cabeçalhos (metadados como Cookie, Content-Type, User-Agent) e corpo (os dados enviados). Cada parte é um ponto onde o atacante pode injetar entrada maliciosa que o servidor processará.

  3. Sendo o HTTP stateless, como as aplicações "lembram" quem você é, e por que o cookie de sessão é um alvo cobiçado?

    ✓ Resposta:

    O servidor entrega, ao logar, um identificador de sessão via cookie, que o navegador reenvia em cada requisição, permitindo ao servidor reconhecer o usuário apesar de o HTTP ser stateless. O cookie de sessão é cobiçado porque representa a identidade do usuário na aplicação — roubá-lo ou forjá-lo permite se passar por ele.

  4. Por que os códigos de status HTTP (como 500) são pistas valiosas para o atacante?

    ✓ Resposta:

    Porque revelam como o servidor reagiu à entrada: um 500 indica que a entrada quebrou algo no servidor (frequente primeiro sinal de injeção), um 403 indica algo existente porém protegido, e diferenças de resposta entre requisições revelam vulnerabilidades cegas. Ler as respostas guia o ataque.

  5. Qual é o princípio de segurança web mais importante que decorre da arquitetura, e por que a validação deve ocorrer no back-end?

    ✓ Resposta:

    O princípio é "nunca confie na entrada do usuário". A validação deve ocorrer no back-end porque o atacante controla o cliente e pode contornar qualquer validação do front-end, forjando requisições diretamente; apenas o servidor está fora do alcance da manipulação do atacante e pode impor segurança de forma confiável.