Header Manipulation: Cookies

A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.

Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.

String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
     cookie.setMaxAge(cookieExpiration);
     response.addCookie(cookie);

Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas de aplicativos Web, como manipulação de cabeçalhos e cookies, não fazem sentido -- por que um usuário atacaria ele próprio? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 2: O código a seguir adapta o Example 1 à plataforma Android.

...
	CookieManager webCookieManager = CookieManager.getInstance();
        String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
	String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
        webCookieManager.setCookie(url, setCookie);

...

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.