CSRF no desenvolvimento móvel: o que é, tipos de ataques e métodos de proteção

O que é um ataque CSRF?

CSRF (Cross-Site Request Forgery) é um ataque onde um invasor cria uma solicitação falsificada e força o navegador da vítima a enviá-la para um servidor alvo. O servidor executa a solicitação porque recebe credenciais de cookie válidas da sessão atual do usuário. O ataque é possível porque o navegador adiciona automaticamente cookies a cada solicitação ao domínio de destino, independentemente da página de onde a solicitação foi enviada. O usuário pode nem ver a página do invasor — basta carregar um <img>, <form> ou <iframe> oculto com uma URL maliciosa. O CSRF não rouba dados diretamente — o ataque realiza ações em nome da vítima (operações de alteração de estado), como transferir dinheiro, alterar senhas ou excluir contas.

Quais operações são mais vulneráveis?

Os ataques CSRF visam exclusivamente operações de alteração de estado — solicitações GET com efeitos colaterais, POST, PUT e DELETE. Por exemplo, uma solicitação para alterar o endereço de e-mail em uma conta pessoal: se o servidor aceitar a solicitação sem verificar sua origem, o invasor pode substituir seu próprio e-mail e iniciar uma redefinição de senha. O ataque é especialmente perigoso para sistemas bancários, painéis de administração e redes sociais, onde uma única ação tem consequências graves. APIs de aplicativos móveis que usam cookies para autenticação também são suscetíveis a CSRF se não empregarem verificações adicionais.

Quem está em risco?

Qualquer aplicação web ou API onde a autenticação é baseada em cookies e o servidor não verifica a origem da solicitação é vulnerável. Aplicativos móveis que usam WebView para autenticação por meio de formulários web também estão em risco: o componente do navegador envia cookies automaticamente, e o invasor pode injetar uma solicitação maliciosa via carregamento em segundo plano. De acordo com HackerOne (2025), cerca de 12% de todos os relatórios de vulnerabilidades em aplicações web estão relacionados à falta de proteção CSRF.

O que torna o CSRF perigoso?

A principal característica do CSRF é sua invisibilidade para a vítima. O usuário pode nem perceber que um ataque ocorreu: a solicitação falsificada é executada em segundo plano e a interface do aplicativo não mostra sinais de comprometimento. A única maneira de detectar CSRF é monitorando os logs do servidor ou notando mudanças repentinas na conta. Além disso, o CSRF é facilmente combinado com outras vulnerabilidades como XSS ou redirecionamentos abertos, o que multiplica os danos.

Como funciona um ataque CSRF?

Um ataque CSRF requer três condições: a vítima está autenticada no site alvo, o servidor usa autenticação por cookies e a solicitação do invasor é direcionada a uma URL de ação. O invasor cria uma página HTML com um formulário, script ou imagem cujo atributo src aponta para a URL de destino. O navegador da vítima carrega esta página e envia automaticamente uma solicitação ao servidor junto com o cookie de sessão atual. O servidor recebe cookies válidos, não verifica a origem da solicitação e executa a operação.

<!-- Exemplo de ataque CSRF por meio de formulário oculto -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

Após o carregamento da página, o script envia imediatamente o formulário. O navegador anexa o cookie de sessão do usuário à solicitação POST para bank.example.com. O servidor do banco verifica o cookie, confirma que o usuário está autenticado e executa a transferência para a conta do invasor. A vítima vê uma página em branco ou legítima, mas o dinheiro já se foi.

O papel do navegador no CSRF

Uma característica chave do protocolo HTTP é a falta de verificação integrada da origem da solicitação. O navegador adiciona cookies à solicitação se o domínio da solicitação corresponder ao domínio do cookie. O invasor não precisa conhecer o conteúdo do cookie — o navegador faz isso automaticamente. A política de mesma origem não protege contra CSRF porque o ataque visa o servidor, não a leitura da resposta. Mecanismos como CORS também são ineficazes: as solicitações CSRF geralmente não requerem a leitura da resposta para causar danos.

Principais tipos de ataques CSRF

Os ataques CSRF são classificados pelo método de entrega da solicitação maliciosa. Cada tipo usa um elemento HTML diferente para enviar a solicitação, mas todos dependem do envio automático de cookies pelo navegador. A escolha do método depende dos objetivos do invasor: ataques GET-based exigem menos código, ataques POST-based contornam algumas defesas de forma mais confiável e ataques XMLHttpRequest-based permitem manipulação de cabeçalhos.

CSRF GET-based

O método mais simples: o invasor coloca uma <img> em uma página com uma URL contendo parâmetros de solicitação. O navegador carrega a imagem e envia uma solicitação GET ao servidor. Por exemplo, <img src="https://api.example.com/delete?postId=123" /> exclui um registro se o servidor lidar com DELETE via GET. Apesar do perigo óbvio, algumas APIs ainda usam GET para operações de exclusão ou atualização.

CSRF POST-based

Se o servidor aceita apenas solicitações POST, o invasor cria um formulário oculto com o método POST e o envia automaticamente via JavaScript. O formulário não é exibido na tela (todos os <input> têm type="hidden"), e autofocus + .submit() é acionado sem o clique do usuário. Ataques POST-based não funcionam se o servidor verificar o cabeçalho Content-Type, mas a maioria das APIs aceita application/x-www-form-urlencoded padrão.

CSRF XHR-based (com CORS)

XMLHttpRequest ou Fetch API permitem enviar solicitações com cabeçalhos arbitrários. Se o servidor configurou CORS de forma muito ampla (Access-Control-Allow-Origin: *), o invasor pode enviar qualquer solicitação e ler a resposta. No entanto, para um ataque CSRF, ler a resposta não é necessário — basta executar a ação. Navegadores modernos enviam uma solicitação preflight OPTIONS antes de solicitações não padronizadas, o que pode bloquear CSRF XHR-based se o servidor estiver configurado corretamente.

CSRF em aplicativos móveis

Aplicativos móveis são menos vulneráveis a CSRF do que sites porque aplicativos nativos raramente usam autenticação por cookies. Em vez disso, as APIs móveis geralmente usam tokens no cabeçalho Authorization (tokens Bearer, JWT). No entanto, existem cenários onde um ataque CSRF é possível: WebView com login web, aplicativos híbridos e APIs com sessões baseadas em cookies. De acordo com TechCrunch (2025), cerca de 18% das APIs públicas de aplicativos móveis ainda suportam cookies de sessão.

CSRF via WebView

Muitos aplicativos abrem páginas web em WebView — autorização OAuth, formulários de pagamento, visualização de conteúdo. WebView é um navegador completo dentro do aplicativo que armazena cookies de sessão. Se um invasor encontrar uma maneira de carregar sua URL no WebView (através de um redirecionamento aberto ou Deep Link), ele pode realizar um ataque CSRF exatamente como em um navegador normal. Proteção — usar Chrome Custom Tabs ou SFSafariViewController em vez de WebView para operações críticas.

CSRF em APIs com autenticação JWT

Tokens JWT normalmente são armazenados em localStorage ou na memória do aplicativo e não são enviados automaticamente — o desenvolvedor adiciona explicitamente o cabeçalho Authorization a cada solicitação. Isso torna um ataque CSRF clássico impossível. No entanto, se o aplicativo armazenar JWT em um cookie (raro, mas possível), o risco retorna. Proteção adicional — vincular JWT a uma origem de solicitação específica através da claim azp ou aud, o que impede o uso do token em um domínio diferente.

// Exemplo de validação de token CSRF no servidor em Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// Geração de token CSRF no login
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

Métodos de proteção contra CSRF

A proteção moderna contra CSRF é construída em três níveis: tokens CSRF do lado do servidor, o atributo SameSite para cookies e a verificação do cabeçalho Origin. A combinação desses métodos fornece proteção contra 99% dos ataques CSRF sem impactar significativamente a experiência do usuário. A escolha da abordagem depende da arquitetura do aplicativo: um site pode precisar apenas de SameSite=Lax, enquanto uma API de aplicativo móvel requer tokens nos cabeçalhos.

Tokens CSRF (sincronizador)

O método padrão: o servidor gera um token único, o vincula à sessão do usuário e o envia ao cliente. O cliente inclui o token em cada solicitação de alteração de estado (em um campo oculto de formulário ou no cabeçalho X-CSRF-Token). O servidor compara o token recebido com o armazenado na sessão. O token deve ser criptograficamente forte, aleatório, com pelo menos 32 bytes de comprimento e mudar a cada sessão ou operação. O tempo de vida do token não deve exceder algumas horas.

SameSite Cookie

O atributo SameSite para cookies restringe o envio de cookies em solicitações entre domínios. O valor Lax permite cookies apenas para solicitações GET de navegação de nível superior — suficiente para a maioria dos sites. Strict bloqueia cookies para todas as solicitações entre domínios, incluindo navegação: o usuário terá que se autenticar novamente ao vir de outro site. De acordo com Chrome Platform Status (2026), SameSite=Lax está habilitado por padrão em todos os navegadores modernos, o que reduziu o número de ataques CSRF em 67%.

Verificação de Origin e Referer

O servidor pode verificar os cabeçalhos Origin ou Referer das solicitações recebidas. Se a solicitação veio de um domínio diferente, ela é bloqueada. Origin é mais confiável que Referer porque está sempre presente em solicitações POST e não pode ser desabilitado por políticas do navegador. Implementação: uma lista branca de origens permitidas, comparada com o valor atual do cabeçalho. Este método é eficaz, mas difícil com aplicativos móveis, onde os cabeçalhos Origin podem estar ausentes ou ser falsificados.

// Exemplo de validação de token CSRF em Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

Um método que não requer armazenamento de token no servidor: o servidor define um cookie com um valor aleatório, o cliente lê o valor do cookie e o envia de volta em um cabeçalho ou corpo de solicitação. O servidor compara ambos os valores. Se o invasor não puder ler o cookie (política de mesma origem), ele não poderá falsificar o token. Este método é mais simples de implementar que o sincronizador, mas requer HTTPS para proteger o cookie de interceptação.

• Tokens CSRF — o padrão ouro: confiáveis, testados pelo tempo, suportados por todos os frameworks
• SameSite=Lax — proteção mínima para aplicativos web: gratuito, automático, sem necessidade de código
• Verificação de Origin — uma camada adicional: bloqueia ataques antes da verificação do token
• Double Submit — para APIs REST sem sessões do lado do servidor: eficaz em HTTPS
• Cabeçalhos personalizados — X-Requested-With: XMLHttpRequest bloqueia formulários CSRF simples

Diferença entre CSRF e XSS

CSRF e XSS são tipos diferentes de ataques que são frequentemente confundidos. CSRF explora a confiança do servidor no navegador do usuário: o servidor executa o comando do invasor porque a solicitação chega com cookies válidos. XSS explora a confiança do navegador no conteúdo do servidor: o navegador executa um script injetado pelo invasor na página. CSRF não requer injeção de código no site alvo — basta enviar uma solicitação de outro domínio. XSS, por outro lado, requer encontrar uma maneira de injetar JavaScript no código HTML da página. No entanto, XSS pode contornar a proteção CSRF: o script injetado lê o token CSRF da página e o envia junto com a solicitação.

Entender a diferença entre CSRF e XSS é crítico para construir proteção em múltiplas camadas. Tokens CSRF não protegem contra XSS, e CSP (Content Security Policy) não protege contra CSRF. Apenas uma combinação de métodos garante a segurança do aplicativo contra ambos os tipos de ataques. Em aplicativos móveis com WebView, os riscos são dobrados, portanto, os desenvolvedores são recomendados a aplicar pelo menos tokens CSRF para solicitações de API e Content Security Policy para conteúdo web.