Pré-requisitos
Este artigo presume o seguinte ambiente:
- Desenvolvimento de um aplicativo baseado em navegador usando OAuth 2.0 e OpenID Connect.
- Existência de uma SPA, as APIs que ela chama e um servidor de autorização.
- A SPA e seus componentes de suporte no lado do servidor podem ser colocados no mesmo domínio pai.
- HTTPS é um pré-requisito (necessário para emitir Cookies Seguros).
Riscos de XSS em Aplicativos Baseados em Navegador
O código do aplicativo executado no navegador é vulnerável a tudo o que acontece no ambiente de execução do navegador. O XSS tem um grande impacto e, como o código do ataque é executado no mesmo contexto que o aplicativo, as seguintes operações são possíveis:
- Ler valores armazenados no localStorage ou sessionStorage.
- Ler variáveis na memória acessíveis a partir do JavaScript.
- Executar todas as chamadas de API que o aplicativo pode realizar.
- Alterar o comportamento sobrescrevendo funções embutidas (poluição de protótipo).
Existem múltiplos pontos de entrada para XSS, como vulnerabilidades em bibliotecas dependentes, falhas no processamento de entrada/saída do seu próprio código ou comprometimento de scripts de terceiros. Como é difícil prevenir completamente o XSS, uma política realista é "limitar o impacto caso ocorra uma intrusão".
Enquanto os tokens estiverem no navegador, a possibilidade de roubo de tokens via XSS permanece. Se um invasor usar um token de atualização roubado em seu próprio ambiente, ele pode chamar APIs por um longo período, mesmo após o usuário fechar o site. Embora a rotação de tokens e os timeouts de inatividade possam mitigar o impacto, não são soluções fundamentais.
Design que Não Coloca Tokens no Navegador
O padrão BFF fornece um componente no lado do servidor dedicado à SPA e centraliza as responsabilidades do cliente OAuth ali. A SPA não lida diretamente com o processamento OAuth, mas realiza a autenticação e as chamadas de API por meio do BFF.
A divisão de papéis é a seguinte:
- Comunicação do protocolo OAuth com o servidor de autorização: Manipulada pelo BFF.
- Manter os tokens de acesso e atualização: Apenas o BFF.
- Manter o estado de autenticação entre a SPA e o BFF: Cookie HttpOnly.
- Chamadas de API: A SPA envia requisições ao BFF, e o BFF converte o Cookie em um token e o encaminha para a API.
Nesta configuração, os tokens circulam apenas entre o BFF e as APIs que ele chama, sendo invisíveis para o JavaScript do navegador. Mesmo que ocorra um XSS, um invasor não pode extrair o token e usá-lo de outro lugar. Tudo o que um invasor pode fazer é enviar requisições ao BFF dentro do escopo da sessão atualmente aberta pelo usuário. Embora esse impacto não seja desprezível, a duração e o escopo do impacto são significativamente limitados em comparação com o roubo de tokens.
O BFF atua como o que a terminologia OAuth chama de "cliente confidencial". Ele possui um segredo de cliente e completa a troca de códigos de autorização por tokens e o processamento de atualização inteiramente no lado do servidor.
Fluxo de Autenticação
Um fluxo de autenticação típico é o seguinte:
- Quando a SPA inicia um login, ela envia uma requisição de login ao BFF.
- O BFF inicia um fluxo de código de autorização com PKCE, gera uma URL de redirecionamento para o servidor de autorização e a retorna para a SPA.
- A SPA direciona o navegador para essa URL, e o usuário se autentica no servidor de autorização.
- O servidor de autorização retorna um código de autorização para a URI de redirecionamento do BFF.
- O BFF troca o código de autorização por tokens e obtém um token de acesso e um token de atualização.
- O BFF armazena os tokens em sua própria área segura (cookie criptografado, armazenamento de sessão no servidor, etc.) e retorna apenas um identificador de sessão para a SPA por meio de um Cookie HttpOnly.
- Quando a SPA chama uma API, ela envia a requisição por meio do BFF. O Cookie é enviado simultaneamente, e o BFF o converte em um token de acesso e o encaminha para a API upstream.
- Se o token de acesso expirar, o BFF o atualiza silenciosamente usando o token de atualização.
Da perspectiva da SPA, o estado de login é mantido pelo Cookie, e as requisições de API são concluídas com chamadas fetch normais. O código que lida diretamente com tokens OAuth ou códigos de autorização não existe na SPA.
Configurações de Segurança Necessárias
Os seguintes atributos devem ser definidos para o Cookie emitido pelo BFF:
- HttpOnly: Proíbe o acesso a partir do JavaScript. Mesmo com XSS, o conteúdo do Cookie não pode ser lido.
- Secure: Enviado apenas por HTTPS.
- SameSite=Strict: Garante que o Cookie não seja enviado com requisições de outros sites. Isso ajuda a bloquear os principais caminhos de ataque CSRF, mas a proteção CSRF não é concluída apenas com isso.
- Prefixo __Host-: Adicionar o prefixo __Host- ao nome do Cookie garante que o navegador limite o Cookie ao host emissor e não o compartilhe com subdomínios.
Se os tokens forem armazenados em um Cookie criptografado (sessão do lado do cliente), o conteúdo do Cookie é criptografado. Se os tokens forem colocados em um armazenamento de sessão no servidor (sessão do lado do servidor), o Cookie contém apenas um identificador de sessão, portanto a criptografia não é necessária.
A Proteção CSRF Não Deve Confiar Apenas no SameSite
Como usa autenticação baseada em Cookie, o BFF deve implementar proteção contra CSRF. SameSite=Strict é uma medida válida, mas não é a solução completa. É necessária cautela especialmente em configurações onde a SPA está em www.exemplo.com e o BFF em api.exemplo.com. Como a determinação do SameSite é feita por site, e não por origem, requisições de outros subdomínios sob exemplo.com são consideradas "mesmo site", e os Cookies serão enviados mesmo com SameSite=Strict.
Portanto, reforce a defesa CSRF com uma das seguintes opções:
- Se o BFF e a SPA estiverem em origens diferentes, use CORS e validação do cabeçalho Origin para defesa.
- Para requisições que alteram o estado, verifique os tokens CSRF usando o método de cookie anti-falsificação / dupla submissão.
Limite o CORS a Origens Exatas
O CORS deve ser permitido apenas para a origem exata da SPA. Para requisições autenticadas que envolvem Cookies, os navegadores não permitem curingas (*) no Access-Control-Allow-Origin. Portanto, o BFF deve refletir a origem exata da SPA na resposta. Essa limitação rigorosa das origens permitidas funciona como parte da defesa CSRF.
O gerenciamento de chaves é necessário para os dados de sessão mantidos pelo BFF, especialmente as informações de token armazenadas em Cookies criptografados. Incorpore operações para injetar chaves com segurança como configurações do BFF e girá-las regularmente.
Observe que colocar a SPA e o BFF no mesmo domínio pai é para satisfazer a condição de que os Cookies de Mesmo Site funcionem como Cookies primários.
Evolução: BFF Orientado por API
Se um BFF for construído como um aplicativo web tradicional, a renderização no lado do servidor do BFF se envolve nas transições de página da SPA. Um BFF orientado por API minimiza esse impacto.
Os papéis são divididos em dois:
- Agente OAuth: Uma API responsável pelo processamento do protocolo OAuth. É chamada pela SPA via JSON.
- Proxy OAuth: Opera como um plugin de gateway de API, extrai o token do Cookie e o encaminha para a API upstream.
Nesta configuração, a SPA simplesmente chama o Agente OAuth como uma API REST normal. A experiência de desenvolvimento do frontend da SPA pode ser mantida quase igual à anterior à introdução do BFF.
Considerações para Adoção
Ao adotar o padrão BFF, considere o seguinte:
- Componentes arquiteturais adicionais aumentam os custos de desenvolvimento e operação.
- A SPA e o BFF devem ser colocados no mesmo domínio pai.
- Uma configuração que simplesmente encaminha o cabeçalho Authorization por meio de um proxy reverso não é um BFF. A essência de um BFF é manter o token como um cliente confidencial.
- PKCE e BFF são usados juntos, não como alternativas.
- O BFF deve verificar o host de destino antes de encaminhar para evitar a exposição do token a hosts não intencionais.
- O design do logout se torna complexo, pois as sessões da SPA, os cookies do BFF e as sessões do servidor de autorização devem estar todos vinculados.
Resumo
Uma maneira prática de lidar com tokens com segurança em aplicativos baseados em navegador é não colocá-los no navegador. O padrão BFF move as responsabilidades do cliente OAuth para o lado do servidor e passa apenas Cookies HttpOnly para o navegador. Isso impede o roubo de tokens mesmo se ocorrer XSS. Ao dividir os papéis em um Agente OAuth e um Proxy OAuth, a segurança pode ser fortalecida enquanto se mantém a experiência de desenvolvimento da SPA.
