Get best of the week

Sobre o armazenamento de tokens JWT em navegadores


O padrão aberto da JWT apareceu oficialmente em 2015 ( rfc7519 ), prometendo recursos interessantes e amplas perspectivas. O armazenamento adequado do token do Access é vital para a criação de um sistema de autorização e autenticação na Web moderna, onde os sites criados com a tecnologia SPA estão se tornando cada vez mais populares.

O armazenamento incorreto de tokens leva ao roubo e à reutilização pelos invasores.

Então, onde guardar?


Considere as principais opções para armazenar o token JWT Access em um navegador:

  1. Armazenamento local / armazenamento de sessão - o método não é seguro e é suscetível a ataques como o XSS, especialmente se você conectar scripts de CDNs de terceiros (adicionar o atributo de integridade não pode garantir 100% de segurança) ou não tem certeza de que os scripts que você conectar não têm a capacidade de "mesclar" dados de armazéns para o lado. Além disso, se o Armazenamento local estiver disponível entre as guias, o Armazenamento de sessões estará disponível em apenas uma guia e a abertura de um site em uma nova guia causará apenas uma nova rodada de token / autorização de acesso.
  2. , , fetch . – .
  3. Cookies. «» cookie sessions. Access cookie CSRF. XSS . CSRF Cookie SameSite Strict– , , credentials, CSRF .
    – Access JS httpOnly, Secure .

    Um ponto importante é definir um cookie apenas para a API do domínio / caminho, para que as solicitações de estática pública não contenham uma sobrecarga no cabeçalho.

Qual é o resultado?


Os cookies, quando usados ​​corretamente, são a solução mais segura e apropriada para armazenar o token JWT Access no momento e devem seguir as seguintes regras:

  1. Ser instalado para a API de domínio / caminho para evitar sobrecarga ao solicitar arquivos estáticos (imagens públicas / estilos / arquivos js).
  2. Tenha um sinalizador seguro (apenas para transferência via https).
  3. Tenha o sinalizador httpOnly (para impossibilidade de acessar a partir do JavaScript).
  4. O atributo SameSite deve ser Estrito para proteger contra ataques CSRF, proibir a transferência de cookies se a transição para sua API não for do domínio definido no cookie.

No lado do servidor, também deve ser configurado:

  1. Política de segurança de conteúdo - restrinja domínios confiáveis ​​para evitar possíveis ataques XSS
  2. Cabeçalho X-Frame-Options para proteger contra ataques de clickjacking.
  3. X-XSS-Protection - force o mecanismo de proteção interno do navegador contra ataques XSS.
  4. X-Content-Type-Options - para proteger contra a substituição de tipos MIME.

A conformidade com essas medidas, juntamente com a rotação frequente de tokens de acesso / atualização, deve ajudar a garantir um alto nível de segurança no site.

Limitações


Apesar do fato de o atributo SameSite ser suportado em muitos navegadores populares , também existem navegadores que não o suportam ou que o suportam parcialmente (olá IE e Safari para Mac). Para esses casos, você precisa de um fallback para os tokens CSRF. Nesse caso, junto com as solicitações à API, o token CSRF também deve ser transmitido. O token CSRF correto deve ser gerado pelo servidor, levando em consideração a impressão digital do usuário, a fim de minimizar a probabilidade de sua substituição.

More articles:


All Articles