Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Mamão com Açúcar como Prefixo de uma Request, como resolver ?

Olá , tudo bem ?

Fiquei com uma dúvida de como deveria fazer de uma maneira profissional caso o meu usuário da API servlet, resolva inventar um prefixo ou instrução qualquer para ser enviada junto com o Token, como na imagem abaixo:

Imagem do Insmonia

No caso eu tenho como tratar se o prefixo for "Bearer" através de um replace que só pega o tokenJWT enviado mas e do contrário? Quando o usuário pode escrever algo bem grande ou mesmo alguma linha de código, como eu deveria tratar na minha aplicação ?

package med.voll.api.infra.security;


import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.springframework.stereotype.Component;
import org.springframework.web.filter.OncePerRequestFilter;

import java.io.IOException;
@Component
public class SecurityFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String tokenJWT = recuperarToken(request);
        System.out.println(tokenJWT);
        filterChain.doFilter(request, response);
    }
    private String recuperarToken(HttpServletRequest request){
        String autorizationHeader = request.getHeader("Authorization");
        if(autorizationHeader == null || autorizationHeader.isEmpty()){
            throw new RuntimeException("TokenJWT não enviado no cabeçalho Authorization");
        }
        return autorizationHeader.replace("Bearer","");
    }
}

Isso pode ser considerado uma falha de segurança o envio de prefixos gigantes ? Quais são outras falhas que eu deveria estar atento no meu código?

Obrigado.

2 respostas
solução!

Olá, Adalberto! Como vai?

Excelente pergunta! A questão que você levantou é muito relevante e trata de um ponto muito importante na segurança de uma aplicação.

Primeiramente, é importante ressaltar que o prefixo "Bearer" é um padrão utilizado em autenticação do tipo JWT (JSON Web Token). Quando o cliente envia uma requisição com um token JWT, ele deve incluir o prefixo "Bearer" antes do token, para indicar que o tipo de autorização é Bearer.

Em relação à sua dúvida, se o usuário enviar um prefixo gigante ou uma linha de código, isso pode sim ser considerado uma falha de segurança, pois pode levar a um ataque de negação de serviço (DoS - Denial of Service), onde o servidor fica sobrecarregado ao tentar processar uma requisição muito grande.

Para resolver isso, você pode adicionar uma validação no seu método recuperarToken para verificar se o prefixo enviado é "Bearer". Caso contrário, você pode retornar um erro para o cliente. Veja um exemplo de como você pode fazer isso:

private String recuperarToken(HttpServletRequest request){
    String autorizationHeader = request.getHeader("Authorization");
    if(autorizationHeader == null || autorizationHeader.isEmpty() || !autorizationHeader.startsWith("Bearer")){
        throw new RuntimeException("TokenJWT inválido ou não enviado no cabeçalho Authorization");
    }
    return autorizationHeader.replace("Bearer","");
}

Além disso, outra boa prática de segurança é limitar o tamanho do cabeçalho de autorização. Isso pode ser feito configurando o servidor para rejeitar requisições com cabeçalhos muito grandes.

Em relação a outras falhas que você deveria estar atento no seu código, alguns pontos importantes são:

  • Sempre valide os dados de entrada: nunca confie nos dados enviados pelo cliente. Sempre valide os dados antes de processá-los.
  • Use HTTPS: para proteger as informações transmitidas entre o cliente e o servidor, sempre use HTTPS em vez de HTTP.
  • Gerencie as dependências: sempre mantenha as dependências do seu projeto atualizadas, pois versões antigas podem conter vulnerabilidades de segurança.

Espero ter ajudado e bons estudos!

Obrigado, vou fazer as modificações aqui.