HTTP response splitting ocorre quando os dados entram na aplicação web através de uma fonte não confiável, frequentemente em um request HTTP, sendo essa manipulada de forma que os dados enviados sejam adicionados em um response Header para o usuário sem ser validada a procura de caracteres maliciosos.
O HTTP response splitting é o que chamamos de vetor de ataques e não um ataque com finalidade por si só. Quando focamos a atenção meramente na técnica, vemos que ela simplesmente retrata um atacante enviando dados maliciosos para uma aplicação vulnerável e a aplicação inclui os dados no cabeçalho de resposta.
Para montar um exploit bem sucedido, a aplicação deve permitir que os dados inseridos contenham o caractere CR (carriage return, que pode ser enviado através de %0d ou \r) e o LF (line feed, que pode ser inserido através de um %0a ou \n) diretamente no header. Estes caracteres não apenas dão ao atacante controle dos headers e o corpo da resposta como também o restante de toda a resposta que a aplicação pretendia enviar para o usuário, criando desta forma uma resposta totalmente controlada por ele.
Exemplo:
O segmento de códigos abaixo se refere ao nome do autor de um weblog, pelo campo author, através de um HTTP request e é setado em um cookie header pelo HTTP response
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
Tendo que uma string que consiste de caracteres padrão alpha-numeric, como por exemplo, “Joao Pedro” é enviada em um HTTP response incluindo este cookie tenha a seguinte forma:
HTTP/1.1 200 OK
...
Set-Cookie: author=Joao Pedro
...
Entretanto, devido o valor do cookie ser formado por dados não validados em um user input, a resposta somente irá permanecer desta forma se o valor submetido para AUTHOR_PARAM não contiver os caracteres CR e LF. Se um atacante submeter uma string maliciosa como, por exemplo,
“Hacker\r\n\HTTP/1.1 200 OK\r\n...”
A resposta HTTP pode ser quebrada em 2 responses com a seguinte forma:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
Claramente a segunda resposta é totalmente controlada pelo atacante e pode ser construída com qualquer header e conteúdo desejado no corpo da pagina. A habilidade de um atacante construir respostas HTTP arbitrárias pode permitir uma variedade de ataques resultantes como, por exemplo:
- Cross-user Defacement
- Cache Poisoning
- Cross-site Scripting
- Page Hijacking
Nos próximos artigos veremos como utilizar a técnica demonstrada acima para obter diversos resultados de ataques como o Cache Poison e o Cross-site Scripting.
Diretor de Operações da In2Sec (Itelligence to Security), é formado em Análise de Sistemas com MBA em Gestão de Riscos, atuou em diversas empresas nacionais e multinacionais, no Brasil e exterior. Especialista em Gestão de Riscos e Segurança da Informação, é responsável pelas operações das Américas da Certificadora TrustSign e das Consultorias de Segurança e-Horus e A.