Precisamos armazenar o JWT no computador cliente. Se o armazenarmos em um LocalStorage / SessionStorage, ele poderá ser facilmente capturado por um ataque XSS. Se o armazenarmos em cookies, um hacker poderá usá-lo (sem lê-lo) em um ataque CSRF e personificar o usuário e entrar em contato com nossa API e enviar solicitações para executar ações ou obter informações em nome de um usuário.
Mas existem várias maneiras de proteger o JWT nos cookies para não serem roubados facilmente (mas ainda existem algumas técnicas avançadas para roubá-los). Mas se você quiser confiar no LocalStorage / SessionStorage, ele poderá ser acessado por um simples ataque XSS.
Portanto, para resolver o problema do CSRF, uso Cookies de envio duplo no meu aplicativo.
Método de envio duplo de cookies
Armazene o JWT em um cookie HttpOnly e use-o no modo seguro para transferir por HTTPS.
A maioria dos ataques de CSRF tem uma origem ou cabeçalho de referência diferente com o host original em suas solicitações. Portanto, verifique se você tem algum deles no cabeçalho, eles são provenientes do seu domínio ou não! Caso contrário, rejeite-os. Se a origem e o referenciador não estiverem disponíveis na solicitação, não se preocupe. Você pode confiar no resultado dos resultados da validação de cabeçalho X-XSRF-TOKEN, que explicarei na próxima etapa.
Embora o navegador forneça automaticamente seus cookies para o domínio da solicitação, há uma limitação útil: o código JavaScript que está sendo executado em um site não pode ler os cookies de outros sites. Podemos aproveitar isso para criar nossa solução CSRF. Para evitar ataques CSRF, precisamos criar um cookie legível em Javascript extra chamado: XSRF-TOKEN. Esse cookie deve ser criado quando o usuário estiver conectado e deve conter uma sequência aleatória e impossível de adivinhar. Também salvamos esse número no próprio JWT como uma reivindicação privada. Sempre que o aplicativo JavaScript desejar fazer uma solicitação, precisará ler esse token e enviá-lo em um cabeçalho HTTP personalizado. Como essas operações (leitura do cookie, configuração do cabeçalho) só podem ser realizadas no mesmo domínio do aplicativo JavaScript,
JS angular facilita sua vida
Felizmente, estou usando o Angular JS em nossa plataforma e os pacotes Angular, a abordagem de token CSRF, tornando mais simples a implementação. Para cada solicitação que nosso aplicativo Angular fizer do servidor, o $http
serviço Angular fará essas coisas automaticamente:
- Procure um cookie chamado XSRF-TOKEN no domínio atual.
- Se esse cookie for encontrado, ele lê o valor e o adiciona à solicitação como cabeçalho X-XSRF-TOKEN.
Assim, a implementação do lado do cliente é tratada automaticamente para você! Nós apenas precisamos definir um cookie nomeado XSRF-TOKEN
no domínio atual no lado do servidor e, quando nossa API receber qualquer chamada do cliente, ela deverá verificar o X-XSRF-TOKEN
cabeçalho e compará-lo com XSRF-TOKEN
o JWT. Se eles corresponderem, o usuário será real. Caso contrário, é uma solicitação forjada e você pode ignorá-la. Este método é inspirado no método "Double Submit Cookie".
Cuidado
Na realidade, você ainda é suscetível ao XSS, mas o invasor não pode roubar seu token JWT para uso posterior, mas ele ainda pode fazer solicitações em nome de seus usuários usando o XSS.
Se você armazena seu JWT no localStorage
ou armazena seu token XSRF no cookie HttpOnly, ambos podem ser facilmente capturados pelo XSS. Até o seu JWT em um cookie HttpOnly pode ser capturado por um ataque XSS avançado, como o método XST .
Portanto, além do método de envio duplo de cookies, você deve sempre seguir as práticas recomendadas contra o XSS, incluindo o escape de conteúdo. Isso significa remover qualquer código executável que faça com que o navegador faça algo que você não deseja. Normalmente, isso significa remover // <![CDATA[
tags e atributos HTML que fazem com que o JavaScript seja avaliado.
Leia mais aqui: