Compreendendo a injeção de CRLF: uma vulnerabilidade e mitigação de aplicativos da Web

Início » Cibersegurança » Segurança de aplicativos » Compreendendo a injeção de CRLF: uma vulnerabilidade e mitigação de aplicativos da Web

A injeção de CRLF (Carriage Return Line Feed) é uma vulnerabilidade de aplicativo da web que ocorre quando um invasor pode injetar caracteres CRLF maliciosos em uma resposta HTTP. Esta vulnerabilidade pode levar a vários problemas de segurança, como injeção de cabeçalho HTTP, divisão de resposta HTTP, fixação de sessão, cross-site scripting (XSS) e envenenamento de cache.

Para entender a injeção de CRLF, vamos analisar o termo:

Retorno de Transporte (CR):É um caractere de controle (código ASCII 13) que instrui o cursor a retornar ao início da linha atual.

Alimentação de linha (LF):É um caractere de controle (código ASCII 10) que instrui o cursor a passar para a próxima linha.

No contexto do HTTP, CRLF refere-se à sequência de caracteres CR e LF (“\r\n”). Esses caracteres são usados para separar linhas no protocolo HTTP.

A vulnerabilidade de injeção de CRLF surge quando os dados controlados pelo usuário (entrada) não são devidamente higienizados ou validados antes de serem usados na construção de uma resposta HTTP. Os invasores exploram essa vulnerabilidade injetando caracteres CRLF na entrada do usuário com o objetivo de manipular a resposta HTTP.

A injeção de CRLF pode ser usada como parte de uma cadeia de vulnerabilidades para explorar vários problemas de segurança. Aqui estão algumas vulnerabilidades comuns da cadeia que podem ser aproveitadas junto com a injeção de CRLF:

A injeção de CRLF pode ser combinada com outras vulnerabilidades, como validação de entrada inadequada ou concatenação insegura de entrada do usuário, para realizar ataques de divisão de resposta HTTP. Ao injetar caracteres CRLF, um invasor pode manipular os cabeçalhos de resposta e potencialmente dividir a resposta em várias partes, levando a vários problemas de segurança, como envenenamento de cache, fixação de sessão ou script entre sites (XSS).

Exemplo:

Vamos considerar um exemplo diferente em que o segmento de código lê o endereço de e-mail de um usuário em uma solicitação HTTP e o define como um cabeçalho de cookie em uma resposta HTTP:

Neste exemplo, o aplicativo pega o endereço de e-mail enviado na solicitação e o define como um cookie denominado “user_email” na resposta HTTP.

Suponha que o endereço de e-mail “[email protegido]” seja enviado na solicitação. A resposta HTTP incluindo este cookie pode ser assim:

Esta resposta mantém o formato pretendido porque a entrada (“[email protegido]”) é um endereço de e-mail válido sem caracteres prejudiciais.

Agora, vamos considerar o que acontece se um invasor enviar um endereço de e-mail malicioso contendo caracteres CRLF:

O valor do parâmetro “email” é “john.doe%40example.com%0d%0aSet-Cookie%3A+admin%3Dtrue%0d%0a”. Quando o aplicativo processa essa entrada e define o cookie, a resposta HTTP pode ser manipulada da seguinte forma

Nesse caso, o invasor injetou caracteres CRLF (“%0d%0a”) no parâmetro email, o que levou à inserção de um cabeçalho “Set-Cookie” adicional na resposta. O invasor definiu efetivamente outro cookie chamado “admin” com o valor “true”. Isso pode ser usado para escalonamento de privilégios ou outros ataques relacionados à segurança.

A injeção de CRLF pode ser usada como um trampolim para ataques de script entre sites. Ao injetar caracteres CRLF para manipular a resposta, um invasor pode introduzir scripts maliciosos que podem ser executados no contexto de outros usuários, levando ao sequestro de sessão, roubo de dados ou outras formas de acesso não autorizado.

Exemplo:

Vamos criar uma carga útil para escalar CRLF para Cross Site Scripting (XSS):

Ao realizar um VAPT (Avaliação de Vulnerabilidade e Teste de Penetração) em um aplicativo da web, descobri uma vulnerabilidade potencial de CRLF (Carriage Return Line Feed). Encontre a explicação para a detecção e exploração da vulnerabilidade CRLF com prova de conceito:

Ao adicionar comentários, todos os cabeçalhos e conteúdos desnecessários ficam sob comentários. O comentário HTML é usado porque a resposta tem o cabeçalho Content-Type:text/html.