O que é CRLF?

quando um navegador envia um pedido para um servidor web, o servidor web responde de volta com uma resposta contendo tanto os cabeçalhos de resposta HTTP e o conteúdo real do site, ou seja, o corpo de resposta. Os cabeçalhos HTTP e a resposta HTML (o conteúdo do site) são separados por uma combinação específica de caracteres especiais, nomeadamente um carriage return e uma linha feed. Para abreviar, eles também são conhecidos como CRLF.

o servidor web usa o CRLF para entender quando o novo cabeçalho HTTP começa e outro termina. O CRLF também pode dizer a uma aplicação web ou usuário que uma nova linha começa em um arquivo ou em um bloco de texto. Os caracteres CRLF são uma mensagem padrão HTTP / 1.1, por isso é usado por qualquer tipo de servidor web, incluindo Apache, Microsoft IIS, e todos os outros.

What is the CRLF Injection Vulnerability?

In a CRLF injection vulnerable attack the attacker inserts both the carriage return and linefeed characters into user input to trick the server, the web application or the user into thinking that an object is terminated and another one has started. Como tal, as sequências CRLF não são personagens maliciosos, no entanto, eles podem ser usados para a intenção maliciosa, para a divisão de resposta HTTP etc.

injeção de CRLF em aplicações web

em aplicações web uma injeção de CRLF pode ter impactos graves, dependendo do que a aplicação faz com itens individuais. Os impactos podem variar desde a divulgação de informações até a execução de Código, uma vulnerabilidade de segurança de aplicação web de impacto direto. Na verdade, um ataque de injeção CRLF pode ter repercussões muito graves em uma aplicação web, apesar de nunca ter sido listado no Top 10 da OWASP. Por exemplo, também é possível manipular arquivos de log em um painel de administração como explicado no exemplo abaixo.

Um exemplo de injecção de CRLF num ficheiro de Registo

Imagine um ficheiro de registo num painel de administração com o padrão de fluxo de saída do caminho IP-tempo visitado, como o abaixo:

123.123.123.123 - 08:15 - /index.php?page=home

If an attacker is able to inject the CRLF characters into the HTTP request he is able to change the output stream and fake the log entries. Ele pode mudar a resposta da aplicação webs para algo como o abaixo:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

o %0d e %0a são as formas url codificadas de CR e LF. Portanto, as entradas de log seriam assim após o atacante inserir esses caracteres e a aplicação exibi-lo:

IP – Time – Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

portanto, explorando uma vulnerabilidade de injeção CRLF, o atacante pode falsificar entradas no arquivo de log para ofuscar suas próprias ações maliciosas. O atacante está literalmente fazendo o seqüestro de páginas e modificando a resposta. Por exemplo, imagine um cenário onde o atacante tem a senha de administração e executou o parâmetro de restrição, que só pode ser usado por um administrador.

o problema é que se o administrador notar que um IP desconhecido usou o parâmetro de restrição, vai notar que algo está errado. No entanto, desde agora parece que o comando foi emitido pelo localhost (e, portanto, provavelmente por alguém que tem acesso ao servidor, como um administrador) não parece suspeito.

a parte inteira da consulta que começa com %0d%0a será tratada pelo servidor como um parâmetro. Depois disso há outro & com o parâmetro restrictedaction que será analisado pelo servidor como outro parâmetro. Efetivamente, esta seria a mesma consulta que:

/index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Description

desde que o cabeçalho de uma resposta HTTP e seu corpo são separados por caracteres CRLF um atacante pode tentar injectar esses. Uma combinação de CRLFCRLF irá dizer ao navegador que o cabeçalho termina e o corpo começa. Isso significa que ele agora é capaz de escrever dados dentro do corpo de resposta onde o código html é armazenado. Isso pode levar a uma vulnerabilidade de scripts Cross-site.

Um exemplo de divisão de respostas HTTP levando a XSS

Imagine uma aplicação que define um cabeçalho personalizado, por exemplo:

X-Your-Name: Bob

o valor do cabeçalho é definido através de um parâmetro get chamado “name”. Se nenhuma codificação de URL está no lugar e o valor é refletido diretamente dentro do cabeçalho, pode ser possível para um atacante inserir a combinação acima mencionada de CRLFCRLF para dizer ao navegador que o corpo do pedido começa. Dessa forma, ele é capaz de inserir dados como o XSS payload, por exemplo:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

o acima mostrará uma janela de alerta no contexto do domínio atacado.

HTTP Header Injection

Description

explorando uma injecção de CRLF, um atacante também pode inserir cabeçalhos HTTP que podem ser usados para derrotar mecanismos de segurança como um filtro XSS do navegador ou a mesma política de origem. Isso permite que o atacante ganhe informações sensíveis como tokens CSRF. Ele também pode definir cookies que poderiam ser explorados registrando a vítima na conta do atacante ou explorando vulnerabilidades de scripting cross-site (XSS) que não poderiam ser exploradas.

Um exemplo de injeção de cabeçalho HTTP para extrair dados sensíveis

Se um atacante é capaz de injetar os cabeçalhos HTTP que ativam CORS (Cross Origin Resource Sharing), ele pode usar javascript para acessar recursos que são de outra forma protegidos pelo SOP (mesma Política de origem), o que impede os sites de origens diferentes de acessar uns aos outros.

os impactos da vulnerabilidade da injeção de CRLF

o impacto das injeções de CRLF variam e também incluem todos os impactos da programação transversal para a divulgação de informações. Ele também pode desativar certas restrições de segurança, como filtros XSS e a mesma Política de origem nos navegadores da vítima, deixando-os suscetíveis a ataques maliciosos.

como prevenir injeções de cabeçalho CRLF/HTTP em aplicações web

a melhor técnica de prevenção é não usar Usuários de entrada diretamente dentro dos cabeçalhos de resposta. Se isso não for possível, você deve sempre usar uma função para codificar os caracteres especiais CRLF. Outra boa prática de segurança de aplicações web é atualizar sua linguagem de programação para uma versão que não permite que CR e LF sejam injetados dentro de funções que definem cabeçalhos HTTP.

a Vulnerabilidade de Classificação e Tabela de Gravidade