XSS, CSRF e man-in-the-middle: ataques web e de rede e defesas

Além dos malwares e golpes de engenharia social, as provas de segurança cobram ataques técnicos a aplicações web e à comunicação em rede. Os três que mais se confundem são o XSS, o CSRF e o ataque do homem no meio (MITM). Cada um explora uma falha diferente e é combatido por uma defesa diferente. Quem associa o ataque à sua fraqueza acerta a maior parte das questões. O guia de injeção de SQL trata de outro ataque da mesma família. Aqui o exemplo foi executado em um teste local, para estudo da defesa.

O princípio comum: confiança mal colocada

Muitos ataques web exploram uma confiança indevida. Ou o site confia no dado que veio do usuário (XSS), ou confia que a requisição veio de quem está logado (CSRF), ou o usuário confia no canal por onde a informação trafega (MITM). Identificar onde está a confiança quebrada indica a defesa.

XSS: cross-site scripting

No XSS, o atacante faz o site entregar ao navegador de outra pessoa um código (geralmente JavaScript) que o atacante escreveu, e o navegador o executa porque acha que veio do site confiável. A falha está no site que devolve na página um dado digitado por alguém sem tratá-lo.

Exemplo de cenário: um campo de comentário aceita texto e o exibe a todos os visitantes. Se alguém envia um comentário contendo uma marcação de script e o site a insere na página como está, todo visitante que abrir a página executará esse script no contexto do site. O script poderia ler dados da página, enviar informações a terceiros ou agir em nome do usuário.

Variações:

Tipo	Como o código chega à vítima
Armazenado (stored)	fica gravado no servidor (comentário, perfil) e atinge quem visita
Refletido (reflected)	vem em um parâmetro do link e é devolvido na resposta; a vítima precisa clicar no link
Baseado em DOM	o próprio script da página manipula o dado de forma insegura, no navegador

A defesa principal: codificar a saída

A defesa central é tratar todo dado externo como texto, e não como código, convertendo os caracteres especiais antes de exibi-lo. O teste mostrou o efeito. O texto de entrada <script>alert(1)</script> foi convertido, pela função de escape de HTML, em:

&lt;script&gt;alert(1)&lt;/script&gt;

O navegador mostra esse resultado como texto na tela e não o executa. Do mesmo modo, aspas e o “e comercial” são convertidos (" vira " e & vira &). Outras defesas:

Validação de entrada (lista de formatos permitidos), útil, mas sozinha não basta.
Política de segurança de conteúdo (CSP), um cabeçalho que restringe de onde scripts podem ser carregados.
Marcar cookies de sessão como inacessíveis ao JavaScript (atributo HttpOnly), para reduzir o roubo de sessão.
Usar bibliotecas e modelos que codificam a saída por padrão.

Resumo: XSS = o site devolve dado do usuário sem codificar. Quem sofre é o navegador da vítima.

CSRF: falsificação de requisição entre sites

No CSRF (cross-site request forgery), o atacante induz o navegador de uma vítima já autenticada em um site a enviar uma requisição indesejada a esse site. O navegador envia automaticamente os cookies de sessão, e o servidor, vendo uma sessão válida, executa a ação (transferir, alterar e-mail, apagar dado).

Exemplo: a vítima está logada em um serviço e abre em outra aba uma página maliciosa, que contém um formulário oculto apontando para a ação do serviço. A ação é executada em nome dela, sem que ela perceba. A falha está no site, que confia em que toda requisição com sessão válida foi intencional.

Defesas:

Token anti-CSRF: um valor imprevisível, ligado à sessão, exigido em cada requisição que altera estado; a página maliciosa não consegue conhecê-lo.
Atributo SameSite nos cookies, que limita o envio em requisições vindas de outros sites.
Confirmação adicional (nova senha, segundo fator) em ações sensíveis.
Usar o método HTTP adequado: ações que alteram estado não devem ocorrer em requisições de leitura (GET).

Resumo: CSRF = o navegador da vítima é usado para mandar uma ação ao site em que ela está logada.

XSS x CSRF: a diferença que cai na prova

Aspecto	XSS	CSRF
O que o atacante injeta	código que roda no navegador da vítima	uma requisição que o navegador envia
Explora a confiança	do usuário no site (o site entrega o script)	do site no usuário (a sessão válida basta)
Falha do site	não codificar a saída	não verificar a origem e a intenção da requisição
Defesa típica	codificação de saída, CSP	token anti-CSRF, SameSite

Detalhe técnico: um XSS bem-sucedido pode contornar a proteção contra CSRF, pois o script roda dentro do site e pode ler o token. Por isso, as duas defesas se somam.

MITM: homem no meio

No ataque do homem no meio (man-in-the-middle), o atacante se posiciona no caminho da comunicação entre duas partes, podendo observar e até alterar o conteúdo, sem que elas percebam. Isso viola a confidencialidade (leitura) e a integridade (alteração).

Como o atacante chega ao meio do caminho:

Redes Wi-Fi abertas ou falsas (“evil twin”), em que a vítima se conecta à rede do atacante.
Spoofing de ARP na rede local, que faz a vítima enviar o tráfego ao atacante.
Adulteração de DNS, que redireciona o nome para um servidor do atacante (veja DNS, DHCP e NAT).
Equipamentos de rede comprometidos.

Defesas:

Criptografia com autenticação do servidor: usar HTTPS (TLS), em que o certificado do servidor, validado pelo navegador, prova a identidade. O atacante não consegue ler nem alterar o tráfego cifrado sem que o navegador alerte sobre certificado inválido.
Não ignorar avisos de certificado.
VPN em redes não confiáveis.
Wi-Fi com autenticação e criptografia fortes (veja Wi-Fi: WPA2, WPA3 e 802.1X).
Autenticação mútua e uso de segurança nas camadas de rede.

Diferença entre MITM e sniffing: o sniffing apenas captura (escuta passiva); o MITM intercepta e pode modificar (ativo). Cifrar o tráfego derrota o sniffing no sentido de impedir a leitura, mas só a validação do certificado impede o MITM de se passar pelo servidor.

Quadro-resumo

Ataque	Alvo principal	Atributo violado	Defesa-chave
XSS	navegador da vítima, via site vulnerável	confidencialidade e integridade	codificar a saída, CSP
CSRF	ação autenticada da vítima	integridade	token anti-CSRF, SameSite
MITM	comunicação entre duas partes	confidencialidade e integridade	TLS com certificado válido, VPN
Injeção de SQL	banco de dados	confidencialidade, integridade	consulta parametrizada
DDoS	servidor ou rede	disponibilidade	filtragem, capacidade, mitigação em rede

Passo a passo para a prova

Identifique quem executa o quê: script no navegador (XSS), requisição forjada (CSRF), interceptação no caminho (MITM).
Localize a confiança quebrada.
Escolha a defesa que ataca essa causa: codificação, token ou criptografia com autenticação.
Descarte respostas que citam apenas antivírus: não resolvem falhas de aplicação.

Erros comuns

Confundir XSS com injeção de SQL: um ataca o navegador, o outro, o banco.
Achar que HTTPS impede o XSS ou o CSRF: ele protege o canal, não a lógica da aplicação.
Dizer que o token anti-CSRF é o mesmo que o cookie de sessão.
Dizer que o MITM só ocorre em rede sem fio.
Achar que validar entrada é suficiente contra XSS.

Fontes e atualização

Não há norma oficial brasileira específica sobre estes ataques; o conteúdo segue a literatura de segurança de aplicações. A codificação de saída do exemplo foi testada em execução. Nomes de cabeçalhos e atributos de cookies evoluem: confira a documentação vigente e o edital.

Próximos passos

Estude a defesa de banco em injeção de SQL.
Revise a visão geral em segurança da informação: ameaças, malware e golpes digitais.
Veja as ferramentas em firewall, IDS/IPS, VPN e MFA.