CRLF é o acrónimo usado para se referir ao Carriage Return (\r) Line Feed (\n). Como se pode notar a partir dos símbolos nos suportes, “Carriage Return” refere-se ao fim de uma linha, e “Line Feed” refere-se à nova linha. Assim, tanto CR quanto LF são usados para denotar o ponto final de uma linha. Quando um usuário pede conteúdo em um site, o servidor retorna o conteúdo do site junto com os cabeçalhos HTTP. Os cabeçalhos e o conteúdo são separados por uma combinação definida de CR e LF. É por causa do CRLF que um servidor sabe onde um novo cabeçalho começa ou termina. Uma vulnerabilidade de injeção de Carriage Return Line Feed (CRLF) é um tipo de injeção do lado do servidor que ocorre quando um atacante insere os caracteres CRLF em um campo de entrada para enganar o servidor, fazendo-o pensar que um objeto terminou e um novo começou. Isso acontece quando a aplicação web não desinfecta a entrada do Usuário para os caracteres CRLF. Tem uma classificação de gravidade média (P3 de acordo com o VRT de Bugcrowd).
CRLF Injection attack has two most important use cases:
- Log Splitting: O atacante insere um caráter de fim de linha e uma linha extra para falsificar as entradas de arquivo de log, a fim de enganar os administradores do sistema, escondendo outros ataques.
- HTTP response Splitting: CRLF injection é usado para adicionar cabeçalhos HTTP à resposta HTTP e, por exemplo, realizar um ataque XSS que leva à divulgação de informações.
Exemplo:
Um simples pedido GET pode ser criada da seguinte forma:
GET /%0d%0aSet-Cookie:CRLFInjection=PreritPathak HTTP/1.1
Nota: %0d e 0a %são codificados formas de \r e \n, respectivamente. Se a aplicação web é vulnerável, um atacante será capaz de definir um cookie no site.
Impacts of CRLF injection
CRLF Injection allows the attacker to set fake cookies, steal CSRF tokens, disclose user information by injecting a script (XSS) and perform a variety of other attacks. Ele também permite que atacantes para desativar & ignorar medidas de segurança, como XSS filtros & Política de Mesma Origem (SOP), tornando-os suscetíveis para os seguintes ataques:
1. XSS ou Cross Site Scripting
XSS ou Cross Site Scripting é uma vulnerabilidade de segurança que permite que um atacante injecte código JavaScript malicioso na aplicação web. Os seguintes pedidos de obtenção são trabalhados em uma injeção CRLF em cadeia de tentativa com XSS. por estourar um alerta contendo informações sensíveis do Usuário
www.target.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
por desativar a proteção XSS
www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
2. A divisão de resposta HTTP permite que um atacante defina cookies maliciosos no navegador da vítima. Na maioria dos casos, o seguinte pedido de obtenção resultará em um 307 redirecionamento, e assim a vítima será redirecionada para target.com & o URL não conterá o parâmetro Set-Cookie. No fundo, no entanto, o cookie será definido.
www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet
3. Phishing Attacks
An attacker can set the Location header which would redirect the victim to the evil website. Este site pode ser desenvolvido para se parecer exatamente com o site alvo e quando a vítima entra em suas credenciais, eles serão enviados para o atacante. O cabeçalho da localização pode ser definido como:
GET /%0d%0aLocation:%20https://evil.com HTTP/1.1
4. Fixação de sessão semelhante ao ataque de injeção de Cookie, aqui o atacante define o id de sessão de um usuário para um determinado valor. Este link é enviado para a vítima e quando a vítima faz login usando esta sessão, o atacante também pode login usando o mesmo ID de sessão.
www.target.com/%0d%0aSet-Cookie:session_id=942....
5. HTTP Header Injection
An attacker can leverage the CRLF injection to inject HTTP Headers in an application in order to defeat security mechanisms such XSS filters or the same-origin-policy.
www.target.com/%0d%0aHackersHeader:NewHeader
o CORS (Cruz Compartilhamento de Recursos de Origem) ativação de cabeçalhos pode ser injetado & o invasor pode usar o JavaScript para aceder a recursos sensíveis que são, de outra forma protegido por SOP (Política de Mesma Origem), que impede que os sites de diferentes origens para aceder a cada um dos outros.
6. Envenenamento por Cache Web é uma técnica devido à qual um atacante pode servir conteúdo envenenado manipulando um cache web. A fim de explorar com sucesso este problema, um atacante precisaria envenenar o proxy cache do site vulnerável, sindicadores, redes de entrega de conteúdo (CDNs) ou outros mecanismos de cache entre o cliente e o servidor. Depois de uma intoxicação web cache bem sucedida, a vítima não terá nenhuma idéia sobre o conteúdo malicioso que está sendo servido a eles pelo cache. O abaixo é um exemplo de como um atacante poderia potencialmente explorar uma injeção de cabeçalho host (usando CRLF) envenenando um web-cache.para o seguinte pedido::
$ telnet www.target.com 80Trying x.x.x.x...Connected to www.target.com.Escape character is '^]'.GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1 //or HostHost: target.com
haveria a seguinte resposta:
HTTP/1.1 200 OK
<
title
>Example</
title
>
<
script
src
=
"http://hacker.com/script.js"
>
casos de Utilização diversos:
1. Injectar um cabeçalho falso de resposta HTTP:
Content-Length: 10
Agora, o navegador web só irá processar os próximos 10 bytes.
2. Injectar um cabeçalho falso de resposta HTTP:
Content-Length: 0
isto é tratado como uma resposta terminada & os navegadores da web começam a analisar uma nova resposta.
mitigações:
um desenvolvedor deve manter as seguintes coisas em mente para evitar a injeção de CRLF:
- higienização da entrada do Usuário.
- Codificar CR & LF caracteres (\r \n), de modo que, mesmo quando eles são fornecidos, eles não são reconhecidas pelo servidor.
- valide the user input before they reach the response headers (e.g. by using methods like StringEscapeUtils.escapeJava()).
- um cabeçalho desnecessário deverá ser desactivado.a tabela seguinte enfatiza a gravidade da injeção de CRLF de acordo com vários padrões da indústria:
Classification | ID / Severity |
---|---|
OWASP 2017 | A1 |
CWE | 93 |
CVSS:3.0 | CVSS:3.0: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H |
Bugcrowd VRT | P3 |