> For the complete documentation index, see [llms.txt](https://stacked-rwx.gitbook.io/public/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stacked-rwx.gitbook.io/public/web-security/explorando-bypass-de-autenticacao-jwt-atraves-de-assinatura-nao-verificada.md).
# Explorando bypass de autenticação JWT através de assinatura não verificada
## O que é JWT?
O JWT é um padrão utilizado para compartilhar informações, isso inclui dados confidenciais, a partir de um token que identifica um usuário autenticado em uma sessão.
Podemos observar a estrutura do JWT divida em três partes.
**Header:** Aqui é possivel observar as informações em objeto JSON como: algoritmo que está sendo usado e o tipo do token. Todos os dados são codificados em base64url.
**Payload:** Aqui é possível observar as informações sobre o usuário.
**Signature:** Aqui é onde ocorre todo processo de verificação da integridade do JSON e pela criptografia hash. É uma forma de evitar mudanças feitas de forma maliciosa.
## **Como funciona um ataque JWT?**
O ataque consiste em enviar informações modificadas para o servidor, caso esteja vulnerável, é possível escalonar privilégios e obter dados de outros usuários. Lembrando que é recomendável o uso do proxy, burp suite é um deles.
Em relação ao porquê ele ocorre, justamente se deve ao uso incorreto do JWT na aplicação. Juntamente a isto, as várias especificações que o JWT possui, sendo eles o JWS (JSON WEB SIGNATURE) e o JWE (JSON WEB ENCRYPTION) são flexíveis, o que consequentemente pode resultar em vulnerabilidades acidentalmente por parte dos desenvolvedores, sendo essas falhas responsáveis pela verificação incorreta da assinatura.
(Resumindo, o problema ocorre pela má verificação da assinatura do token.)
## Ataque de bypass de autenticação JWT através de assinatura não verificada
Para sabermos como essa vulnerabilidade ocorre na prática, irei utilizado o laboratório do Portswigger.
Ao acessar o laboratório, nos deparamos com um blog. Clicando em “My account”, nós seremos redirecionados até a página de login.
O usuário é “wiener” e a senha é “peter” para que possamos logar. Nesse momento, vamos até o nosso proxy do burp suite para que possamos interceptar todas as requisições durante o login.
Pronto, a nossa primeira requisição foi interceptada pelo Burp Suite. Agora clicando em forward, vamos poder observar qual será a próxima requisição que será feita.
Encontrando a requisição certa, vamos enviá-la para o Repeater.
Bem, eu utilizo uma extensão chmada JWT Editor que vocês podem encontrar no BAPP Store do Burp Suite ou clicando [aqui](https://portswigger.net/bappstore/26aaa5ded2f74beea19e2ed8345a93dd). Clicando em SEND, podemos notar que o nosso login foi efetuado.
Vejam agora o token presente no cookie, é ele que vamos explorar. Clicando em “JSON Web Token”, podemos pegar as melhores informações sobre o token.
Observem que o token está com cores diferentes a cada ‘.’, o que quer dizer que cada parte colorida está sendo referenciado por uma estrutura do token.
\- A parte vermelha é o header;\
\- A parte rosa é o payload;\
\- A parte azul é a signature;
Observando um pouco abaixo, podemos notar que o header e o payload foram decodados e algumas informações forem exibidas. A nossa missão é escalarmos para o usuário administrator.
Para isso, vamos até o payload e vamos mudar o “sub”: “wiener” para “sub”: “administrator”.
Antes:
Depois:
Agora clique em SEND e obtenha um redirect (302).
Voltando até RAW, modifique o url com “id=wiener” para “id=administrator” e veja o resultado!
Sucesso! Depois de logado como administrador, a nossa missão é deletar o usuário Carlos. Para isso, vamos até “/admin” e vamos procurar pelo usuário Carlos.
Copiando o caminho passado dentro do href=””, conseguiremos deletar o usuário Carlos.
Yeah, laboratório resolvido!
Obrigado por ler até aqui.