XSS (Cross-Site Scripting)

XSS WordPress é a aplicação ao CMS de uma das classes de ataque mais comuns na web: Cross-Site Scripting, em que um atacante consegue injetar código JavaScript malicioso em páginas legítimas e fazer com que esse código execute no navegador de outras pessoas que visitam o site. O resultado pode ser roubo de cookies, sequestro de sessão, redirecionamentos forçados, defacement ou roubo de dados de formulários. O core do WordPress tem mitigação forte; a maioria dos casos reais explora plugins mal escritos.

O que é XSS

O nome “Cross-Site Scripting” descreve o vetor original do ataque: rodar script de um site no contexto de outro site. Na prática moderna, o conceito é mais amplo: qualquer execução de JavaScript em página onde o atacante não deveria ter capacidade de inserir código.

O fluxo típico envolve três personagens. O atacante encontra um campo onde input do usuário é refletido na página sem escape adequado. Insere JavaScript malicioso nesse campo. Vítima abre a página, o JavaScript executa no navegador dela com cookies e sessão dela ativa, e o atacante consegue executar ações em nome da vítima.

Quem busca o que é xss costuma estar tentando entender uma CVE em plugin instalado, ou auditando código próprio. Em ambos os casos, a resposta envolve duas perguntas: onde input do usuário entra na página e onde esse input é exibido. XSS mora exatamente entre esses dois pontos.

Para o usuário final, XSS é praticamente invisível. A página parece normal, o domínio é o legítimo, o cadeado HTTPS está ativo. Mas no fundo, código do atacante está rodando junto, lendo cookies, capturando teclas, redirecionando para domínios maliciosos. É exatamente essa invisibilidade que torna XSS tão perigoso.

Tipos de XSS: refletido, persistente e DOM

XSS refletido é a variante mais simples. O input malicioso vai em uma URL ou em um POST, é processado pelo servidor e refletido de volta na resposta sem escape. O atacante envia link com payload para a vítima, ela clica, o JavaScript executa. Tudo acontece em uma única requisição. Não persiste no banco, mas funciona se a vítima clicar.

XSS persistente é a variante mais perigosa. O input malicioso é salvo no banco do site (em comentário, em metadado, em opção de plugin) e exibido depois para todos que visitarem a página afetada. Um único ataque atinge todos os visitantes seguintes. Comentários WordPress sem moderação foram vetores históricos clássicos.

XSS baseado em DOM acontece inteiramente no navegador. O servidor não está envolvido na manipulação. JavaScript do site lê parâmetros da URL ou do hash e os insere no DOM sem escape. Atacante envia URL com payload, a vítima abre, o próprio script da página injeta o conteúdo malicioso. É o tipo mais difícil de detectar via auditoria de servidor.

O termo cross site scripting cobre todos os três. CVEs em plugins WordPress costumam mencionar qual variante específica está envolvida, e a defesa varia ligeiramente para cada uma. Combine com proteção geral contra vulnerabilidades e CSRF em conjunto.

Como WordPress se protege contra XSS

O core fornece um conjunto rico de funções de escape, cada uma para um contexto específico. esc_html escapa para uso dentro de HTML normal. esc_attr escapa para uso dentro de atributos HTML. esc_url normaliza e valida URLs. esc_js escapa string para uso em código JavaScript inline. esc_textarea escapa para uso dentro de textareas. wp_kses permite HTML restrito controlado por allowlist.

O editor visual do WordPress (TinyMCE) e o Gutenberg passam por filtros internos que permitem só um conjunto de tags HTML em conteúdo de posts. Tags como script, iframe, embed e onclick são removidas automaticamente do conteúdo gerado pelo editor. Assinante e Contribuidor têm filtros ainda mais restritivos que Administrador.

O sistema de comentários sanitiza input por padrão e exige moderação de comentários novos vindos de email não cadastrado. Plugins de antispam (Akismet, Antispam Bee) somam camada extra. URLs em comentários ganham rel=nofollow ugc automaticamente para proteger SEO mesmo quando passam pelo filtro.

Para usuários acima de Editor, o WordPress permite por padrão o uso de HTML mais amplo e até de unfiltered_html (capacidade especial). Isso é por design: editores precisam poder embutir vídeos, código de demo e widgets externos. A contrapartida é que essas contas precisam ter senhas fortes, 2FA ativo e auditoria de capacidade. Combine com hardening via wp-config.php.

Como prevenir XSS no seu código

A regra de ouro é: nunca exiba dado vindo de fora sem escape. Toda saída precisa passar pela função de escape correspondente ao contexto. echo $variavel sem esc_html ou similar é vulnerabilidade pronta. echo esc_html($variavel) elimina o ataque no ato.

O segundo passo é escolher a função certa para o contexto. esc_html para conteúdo dentro de elementos HTML. esc_attr para conteúdo dentro de atributos. esc_url para URLs. esc_js para strings que vão entrar em JavaScript. Usar esc_html dentro de atributo HTML deixa passar payloads que esc_attr bloqueia.

O terceiro passo é fazer o mesmo na entrada via sanitização. Sanitizar na entrada e escapar na saída são camadas complementares, e ataque xss costuma atravessar exatamente quando uma das duas é esquecida. Use sanitize_text_field, esc_url_raw e wp_kses para entrada; esc_html, esc_attr e esc_url para saída.

O quarto passo é configurar Content Security Policy via cabeçalho HTTP. CSP define quais origens podem carregar scripts, estilos e recursos. Bem configurada, CSP bloqueia execução de JavaScript inline mesmo se a página tiver XSS, neutralizando o ataque mesmo quando ele consegue ser injetado. Combine com proteção contra SQL Injection para fechar os dois vetores mais comuns juntos.

Para times que querem proteção contínua contra XSS sem auditar plugin a plugin manualmente, a FULL Services entrega o AIOS já licenciado e configurado dentro da stack profissional, com firewall de aplicação que bloqueia payloads conhecidos de XSS, hardening padrão de WordPress e cabeçalhos de CSP pré-tunados. Em vez de revisar código de cada plugin caso a caso, o site roda em uma camada de segurança validada em produção desde o primeiro deploy.