CSRF (Cross-Site Request Forgery)

CSRF WordPress é o ataque que engana um usuário autenticado a executar ações que ele não pretendia, aproveitando-se de sua sessão ativa no painel. O atacante não precisa roubar a senha — basta convencer o usuário logado a clicar em um link ou abrir uma página que dispare requisições maliciosas usando os cookies que ele já tem. No WordPress, o sistema de nonces é a defesa principal contra esse vetor.

O que é CSRF

CSRF é a sigla para Cross-Site Request Forgery, traduzido como Falsificação de Requisição em Sites Cruzados. A ideia é simples e elegante do ponto de vista do atacante: navegadores enviam cookies automaticamente em qualquer requisição para o domínio dono dos cookies. Se o atacante consegue fazer o navegador da vítima disparar uma requisição para o site alvo, essa requisição vai autenticada — porque os cookies de sessão estão lá.

O ataque clássico funciona assim: a vítima está logada no painel WordPress de seusite.com. Em outra aba, ela visita um site malicioso, que tem um formulário ou imagem oculta apontando para seusite.com/wp-admin/admin-post.php?action=delete_user&user_id=42. Quando o navegador carrega aquela imagem, dispara a requisição com os cookies da vítima — e o WordPress, achando que é o admin querendo, deleta o usuário 42.

O cross site request forgery se aproveita da confiança que o servidor tem na sessão ativa, sem confirmar que a requisição realmente partiu do contexto correto da aplicação. Difere do XSS (Cross-Site Scripting): no XSS, o atacante injeta código no próprio site da vítima. No CSRF, o atacante força o navegador a enviar requisições legítimas em nome do usuário.

O CSRF está na lista OWASP Top 10 desde sua criação. Mesmo com defesas modernas (SameSite cookies, tokens anti-CSRF), continua sendo vetor relevante porque a complexidade do WordPress, com milhares de plugins de qualidade variável, gera superfície grande de ataque. Plugins mal escritos sem proteção CSRF aparecem em CVEs todo mês.

Como CSRF afeta WordPress

O painel WordPress tem dezenas de ações sensíveis: criar usuário com permissão de admin, deletar posts, alterar configurações do site, instalar plugins, mudar tema, modificar opções da tabela wp_options. Qualquer uma dessas ações sem proteção contra CSRF vira vetor de ataque catastrófico.

O cenário mais comum é via plugins. Um plugin adiciona uma página de configurações ao painel. Se o desenvolvedor não implementou nonce na verificação do form, qualquer requisição POST com os parâmetros corretos modifica as configurações — independentemente de ter vindo do painel ou de um site externo. Atacante com CSRF zera proteções, ativa modos de debug, expõe dados sensíveis.

O cenário mais grave é privilege escalation. Plugins que permitem promover usuários a admin sem verificar nonce permitem a um atacante criar um usuário comum em um site e depois, via CSRF, fazer com que um admin existente promova esse usuário a administrador sem perceber. Daí em diante, o atacante tem controle total.

O cenário sutil é em REST API mal configurada. Endpoints REST que aceitam ações destrutivas precisam validar nonce ou usar autenticação por header dedicado. APIs que confiam só em cookie de sessão são vulneráveis a CSRF tanto quanto formulários tradicionais.

O cenário esquecido é em fluxos de AJAX. Cada handler registrado via wp_ajax_{action} precisa validar nonce. Plugins antigos que adicionaram AJAX em 2010 sem essa proteção continuam vulneráveis hoje, e seus usuários muitas vezes nem sabem.

Nonces como defesa principal

O WordPress combate ataque csrf com o sistema de nonces — uma sigla que vem de “number used once”. Apesar do nome, o nonce do WordPress não é exatamente “number used once” no sentido criptográfico estrito; é mais um token temporário, válido por 24 horas, gerado para cada usuário e cada ação específica.

O fluxo é: ao renderizar um formulário ou link que dispara ação sensível, o WordPress gera um nonce com wp_create_nonce(‘minha_acao’) e o inclui como campo hidden ou parâmetro de URL. Quando a requisição chega, o handler valida com check_admin_referer ou wp_verify_nonce. Se o nonce está ausente, expirado ou não corresponde ao usuário+ação, a requisição é rejeitada com erro 403.

O ponto chave é que o atacante remoto não consegue gerar nonces válidos. Mesmo conhecendo a estrutura da requisição, o nonce muda por usuário e por ação, e só pode ser gerado dentro do contexto autenticado do site. O ataque CSRF clássico fica neutralizado: a requisição falsificada chega sem nonce válido e é descartada.

Funções importantes a conhecer: wp_nonce_field para gerar campo hidden em forms, wp_nonce_url para anexar nonce a URL, check_admin_referer para validar em ações de painel, check_ajax_referer para validar em AJAX, wp_verify_nonce para validação manual. Combinar com nonces WordPress bem implementados é a base de qualquer plugin seguro.

Boas práticas para evitar CSRF

A primeira regra é: toda ação destrutiva ou modificadora precisa de nonce. Salvar configuração, deletar item, alterar permissão, processar pagamento — sem exceção. Auditar plugin próprio significa varrer cada admin-post.php, admin-ajax.php e endpoint REST e garantir que cada um valida nonce ou outro mecanismo equivalente.

A segunda regra é validar capability além do nonce. Nonce só prova que a requisição partiu do contexto correto. Validar com current_user_can(‘manage_options’) ou similar prova que o usuário tem permissão para a ação. Os dois juntos formam a defesa em camadas: contexto certo + permissão certa.

A terceira regra é configurar SameSite no cookie de sessão. Configurar a constante SECURE_AUTH_COOKIE e cookies com flag SameSite=Lax ou Strict reduz a superfície de CSRF, porque navegadores modernos passam a não enviar cookies em requisições cross-site automaticamente. Isso vem ganhando força como defesa adicional.

A quarta regra é manter plugins atualizados. A maioria das vulnerabilidades CSRF que viram CVE tem correção lançada rapidamente — o problema é o site que demora semanas para atualizar. Combine atualização frequente com monitoramento de vulnerabilidades e plugins de segurança que aplicam regras de WAF para bloquear ataques conhecidos antes do patch.

A quinta regra é ter firewall WordPress com regras específicas para padrões CSRF. Para sites profissionais que precisam dessa cobertura sem montar regras manualmente, a FULL Services entrega o AIOS (All-In-One Security) já licenciado e configurado dentro da stack profissional, com proteções nativas contra CSRF, XSS e brute force, monitoramento contínuo de tentativas suspeitas e alertas automáticos quando padrões de ataque são detectados. É a forma de ter cobertura por padrão, não por correção depois do incidente.