8 itens encontrados
Vulnerabilidades
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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. 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: 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.


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, cross-site scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou Open Redirect.
Explanation
Vulnerabilidades de Header Manipulation ocorrem quando:

1. Os dados entram em um aplicativo Web por meio de uma fonte não confiável, mais frequentemente em uma solicitação HTTP.


2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, Header Manipulation é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Header Manipulation é 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 (alimentaçã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 servidores de aplicativos modernos de hoje impedem a injeção de caracteres mal-intencionados nos 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 seguinte código define um cabeçalho HTTP cujo nome e valor podem ser controlados por um invasor:


@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();

RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}


Supondo que um par nome/valor consista em author e Jane Smith, a resposta HTTP incluindo este cabeçalho pode ter o seguinte formato:


HTTP/1.1 200 OK
...
author:Jane Smith
...


No entanto, como o valor do cabeçalho é formado com base em entrada de usuário não validada, um invasor pode enviar um par nome/valor mal-intencionado, como HTTP/1.1 200 OK\r\n...foo e bar, e a resposta HTTP seria dividida em duas respostas da seguinte forma:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


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.

Desfiguração entre Usuários: Um invasor pode fazer uma única solicitação a um servidor vulnerável que faz com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como 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 capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

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, ele continuará recebendo o conteúdo mal-intencionado até que a entrada do cache seja removida, embora apenas o usuário da instância do navegador local será 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 (a resposta pretendida do servidor e a resposta gerada pelo invasor), um invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, direcione indevidamente 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.

Manipulação de Cookie: Em combinação com ataques como Cross-Site Request Forgery, os invasores podem alterar, acrescentar ou até mesmo sobrescrever os cookies de um usuário legítimo.

Open Redirect: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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 e estruturas de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Microsoft .NET Framework converterão caracteres CR, LF e NULL em %0d, %0a e %00 quando estes forem enviados ao método HttpResponse.AddHeader(). Se você estiver usando o .NET Framework mais recente que impede a definição de cabeçalhos com caracteres de nova linha, talvez o seu aplicativo não seja 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: 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.


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


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.Text 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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation
Abstract
Incluir dados não validados em um cabeçalho de resposta HTTP pode possibilitar ataques de envenenamento de cache, cross-site scripting, desfiguração entre usuários ou sequestro de página.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado contra caracteres mal-intencionados.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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. 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: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, de um formulário HTML e o define no cabeçalho de um cookie de uma resposta HTTP.


...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.

EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...


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 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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cobol.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

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

2. Os dados são incluídos em um cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de um formulário da Web e o define em um cabeçalho de cookie de uma resposta HTTP.


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, cross-site scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou Open Redirect.
Explanation
Vulnerabilidades de Header Manipulation 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 cabeçalho de resposta HTTP enviado para um usuário da Web sem validação.

Tal como acontece com muitas vulnerabilidades de segurança de software, Header Manipulation é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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 (alimentaçã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 servidores de aplicativos modernos de hoje impedirão a injeção de caracteres mal-intencionados nos 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: O segmento de código a seguir lê o 'content-type' de uma solicitação HTTP e o define no cabeçalho de uma nova solicitação HTTP.


final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});


Como o valor do cabeçalho 'Content-Type' é formado por entrada de usuário não validada, ele pode ser manipulado por agentes mal-intencionados para explorar vulnerabilidades, executar ataques de injeção de código, expor dados confidenciais, permitir a execução de arquivos maliciosos ou acionar situações de negação de serviço, apresentando riscos significativos à segurança e à estabilidade do aplicativo.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dart.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, cross-site scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou Open Redirect.
Explanation
Vulnerabilidades de Header Manipulation 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta HTTP.


Exemplo: 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.


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...


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.

Desfiguração entre Usuários: Um invasor pode fazer uma única solicitação a um servidor vulnerável que faz com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como 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 capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

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, ele continuará recebendo o conteúdo mal-intencionado até que a entrada do cache seja removida, embora apenas o usuário da instância do navegador local 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 da 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 (a resposta pretendida do servidor e a resposta gerada pelo invasor), um invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, direcione indevidamente 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.

Manipulação de Cookie: Em combinação com ataques como a Falsificação de Solicitações entre Sites, os invasores podem alterar, acrescentar ou até mesmo sobrescrever os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Standards Mapping - Common Weakness Enumeration CWE ID 113
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[50] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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: 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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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. 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: 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.


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


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 de criação de respostas HTTP arbitrárias do invasor permite uma variedade de ataques resultantes, incluindo: envenenamento de cache da Web e do navegador, cross-site scripting e sequestro de página.


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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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 (alimentaçã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: O segmento de código a seguir considera que name e value podem ser controlados por um invasor. O código define um cabeçalho HTTP cujo nome e valor podem ser controlados por um invasor:


...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...


Considerando um par de nome/valor que consiste em author e Jane Smith, a resposta HTTP que inclui esse cabeçalho pode ter o seguinte formato:


HTTP/1.1 200 OK
...
author:Jane Smith
...


No entanto, como o valor do cabeçalho é formado com base na entrada de usuário não validada, um invasor pode enviar um par de nome/valor mal-intencionado, como HTTP/1.1 200 OK\r\n...foo e bar, e a resposta HTTP seria dividida em duas respostas no seguinte formato:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.objc.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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, as versões recentes de PHP gerarão a criação de um cabeçalho e de um aviso e de interrupção quando novas linhas são passadas para a função header(). Se a sua versão de PHP impedir a definição de cabeçalhos com novos caracteres de linha, seu aplicativo não estará vulnerável à Divisão de resposta 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: O segmento de código a seguir lê a localização a partir de uma solicitação HTTP e define-a no campo de localização de cabeçalho de uma resposta HTTP.


<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>


Supondo que uma cadeia de caracteres que consiste em caracteres alfanuméricos padrão, como "index.html", seja enviada na solicitação, a resposta HTTP, incluindo este cookie, pode ter a seguinte forma:


HTTP/1.1 200 OK
...
location: index.html
...


No entanto, como o valor da localização é formado por entrada de usuário não validada, a resposta só manterá essa forma se o valor enviado para some_location não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:


HTTP/1.1 200 OK
...
location: index.html

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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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. 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: 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.


...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...


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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.sql.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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. 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: Este segmento de código lê o local a partir de uma solicitação HTTP e o define como o cabeçalho do campo de localização de uma resposta HTTP.


location = req.field('some_location')
...
response.addHeader("location",location)


Supondo que uma cadeia de caracteres que consiste em caracteres alfanuméricos padrão, como "index.html", seja enviada na solicitação, a resposta HTTP, incluindo este cookie, pode ter a seguinte forma:


HTTP/1.1 200 OK
...
location: index.html
...


No entanto, como o valor da localização é formado por entrada de usuário não validada, a resposta só manterá essa forma se o valor enviado para some_location não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:


HTTP/1.1 200 OK
...
location: index.html

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.

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. No pior dos casos, um invasor pode fornecer conteúdo especialmente concebido a fim de imitar o comportamento do aplicativo, mas, redirecionando informações privadas, como números de conta e senhas para o invasor.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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: Este segmento de código lê o nome do autor de um blog, author, a partir de uma solicitação HTTP e o usa em uma solicitação GET em outra parte do site.


author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")


Supondo que uma cadeia composta por caracteres alfanuméricos, como "Jane Smith", seja enviada na solicitação, a resposta HTTP pode assumir esta forma:


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...


No entanto, uma vez que o valor da URL é formado por entradas de usuário inválidas, a resposta só manterá esta forma se o valor enviado para AUTHOR_PARAM não contiver quaisquer caracteres CR e LF. Se um invasor enviar uma cadeia maliciosa, como "Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...", então a resposta HTTP seria dividida em duas respostas neste formato:


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker

POST /index.php HTTP/1.1
...


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.

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 a 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 malicioso até que a entrada de 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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.ruby.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation ou open redirect.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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, o Play Framework lançará uma exceção se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impedir a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não será vulnerável à HTTP Response Splitting. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Cookie Manipulation ou Open Redirects e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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 (alimentaçã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: O segmento de código a seguir considera que name e value podem ser controlados por um invasor. O código define um cabeçalho HTTP cujo nome e valor podem ser controlados por um invasor:


...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...


Considerando um par de nome/valor que consiste em author e Jane Smith, a resposta HTTP que inclui esse cabeçalho pode ter o seguinte formato:


HTTP/1.1 200 OK
...
author:Jane Smith
...


No entanto, como o valor do cabeçalho é formado com base na entrada de usuário não validada, um invasor pode enviar um par de nome/valor mal-intencionado, como HTTP/1.1 200 OK\r\n...foo e bar, e a resposta HTTP seria dividida em duas respostas no seguinte formato:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.swift.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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 servidores de aplicativos modernos impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. No entanto, os servidores que dão suporte ao ASP clássico muitas vezes não têm esse mecanismo de proteção.

Exemplo: 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.


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


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.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation
Abstract
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.
Explanation
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: 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.


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


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.

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.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation_cookies
Abstract
A inclusão de dados não validados nos cookies pode levar a Header Manipulation de resposta HTTP e permitir envenenamento de cache, cross-site scripting, desfiguração entre usuários, invasão de página, manipulação de cookie ou Open Redirect.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Os dados entram em um aplicativo Web por meio de uma fonte não confiável, mais frequentemente em 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.



Assim como ocorre com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, não um fim em si. 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 Cross-Site Request Forgery, os invasores podem alterar, acrescentar ou até mesmo sobrescrever 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 (alimentaçã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 servidores de aplicativos modernos de hoje impedirão a injeção de caracteres mal-intencionados nos 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, de uma solicitação HTTP, e o define em um cabeçalho de cookie de uma resposta HTTP.


...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {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 só manterá esse formato se o valor enviado para author não contiver caracteres de CR e LF. Se um invasor enviar uma cadeia de caracteres 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.

Desfiguração entre Usuários: Um invasor pode fazer uma única solicitação a um servidor vulnerável que fará com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como 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 capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

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, ele continuará recebendo o conteúdo mal-intencionado até que a entrada do cache seja removida, embora apenas o usuário da instância do navegador local será 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. Enviando uma solicitação que resulta em duas respostas (a resposta pretendida do servidor e a resposta gerada pelo invasor), um invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, direcione indevidamente 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.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation_cookies
Abstract
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.
Explanation
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: 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.


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


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.

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.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation_cookies
Abstract
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.
Explanation
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: 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.


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


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.

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.
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation_cookies
Abstract
A inclusão de dados não validados nos cookies pode levar a Header Manipulation de resposta HTTP e permitir envenenamento de cache, cross-site scripting, desfiguração entre usuários, invasão de página, manipulação de cookie ou Open Redirect.
Explanation
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.

Assim como ocorre com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, não um fim em si. 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 a Falsificação de Solicitações entre Sites, os invasores podem alterar, acrescentar ou até mesmo sobrescrever 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 (alimentaçã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 servidores de aplicativos modernos de hoje impedem a injeção de caracteres mal-intencionados nos 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: 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.


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &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 só manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma cadeia de caracteres 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.

Desfiguração entre Usuários: Um invasor pode fazer uma única solicitação a um servidor vulnerável que faz com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como 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 capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

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, ele continuará recebendo o conteúdo mal-intencionado até que a entrada do cache seja removida, embora apenas o usuário da instância do navegador local seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, há grande variedade de conteúdo mal-intencionado que eles podem 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 da 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, um invasor pode aproveitar a mesma vulnerabilidade raiz para redirecionar ao invasor 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.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation_cookies
Abstract
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.
Explanation
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.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation_cookies
Abstract
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.
Explanation
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: 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.


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


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.

Cross-User Defacement: Um invasor pode fazer uma única solicitação a um servidor vulnerável que fará com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como 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 capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

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.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation_cookies
Abstract
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.
Explanation
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: 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.


<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>


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.

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.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation_cookies
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode 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.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho 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 cabeçalho de resposta 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 Cabeçalho é um meio para um fim, e não um fim por si só. 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 cabeçalho de resposta 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. 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: Este segmento de código lê o local a partir de uma solicitação HTTP e o define como o cabeçalho do campo de localização de uma resposta HTTP.


location = req.field('some_location')
...
response.addHeader("location",location)


Supondo que uma cadeia de caracteres que consiste em caracteres alfanuméricos padrão, como "index.html", seja enviada na solicitação, a resposta HTTP, incluindo este cookie, pode ter a seguinte forma:


HTTP/1.1 200 OK
...
location: index.html
...


No entanto, como o valor da localização é formado por entrada de usuário não validada, a resposta só manterá essa forma se o valor enviado para some_location não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:


HTTP/1.1 200 OK
...
location: index.html

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.

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. No pior dos casos, um invasor pode fornecer conteúdo especialmente concebido a fim de imitar o comportamento do aplicativo, mas, redirecionando informações privadas, como números de conta e senhas para o invasor.

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.

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.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
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 cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation ou open redirect.
Explanation
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 cookie manipulation é 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 cookie manipulation 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 impedir a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não será vulnerável à HTTP Response Splitting. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Cookie Manipulation ou Open Redirects e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation_cookies
Abstract
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.
Explanation
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: 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.


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


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.

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.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation_cookies
Abstract
Incluir dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para vazar o conteúdo do e-mail para eles mesmos ou usar o servidor de correio como um bot de spam.
Explanation
As vulnerabilidades de SMTP Header Manipulation ocorrem quando:

1. Os dados entram em um aplicativo por meio de uma fonte não confiável, mais frequentemente, uma solicitação HTTP em um aplicativo Web.

2. Os dados são incluídos em um cabeçalho SMTP enviado a um servidor de correio sem validação.

Como acontece com muitas vulnerabilidades de segurança de software, SMTP Header Manipulation é um meio para um fim, não um fim por si só. Em sua raiz, a vulnerabilidade é direta: um invasor passa dados mal-intencionados para um aplicativo vulnerável e o aplicativo inclui os dados em um cabeçalho SMTP.

Um dos ataques de SMTP Header Manipulation mais comuns é distribuir e-mails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo: O seguinte segmento de código lê o assunto e o corpo de um formulário "Fale conosco":


func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}


Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


...
subject: [Contact us query] Page not working
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta só manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Parabéns!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP serão:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


De fato, isso permite que um invasor crie mensagens de spam ou envie e-mails anônimos entre outros ataques.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 93
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
A inclusão de dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho SMTP ocorrem quando:

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

2. Os dados são incluídos em um cabeçalho SMTP enviado para um servidor de e-mail sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho SMTP é 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 cabeçalho SMTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho SMTP é usado para distribuir emails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo: O segmento de código a seguir lê o assunto e o corpo de um formulário "Fale conosco":


String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);


Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


...
subject: [Contact us query] Page not working
...


No entanto, como o valor do cabeçalho é construído a partir de uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


Isso permitirá efetivamente que um invasor elabore mensagens de spam ou envie e-mails anônimos entre outros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
A inclusão de dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho SMTP ocorrem quando:

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

2. Os dados são incluídos em um cabeçalho SMTP enviado para um servidor de e-mail sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho SMTP é 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 cabeçalho SMTP.

Um dos ataques mais comuns de Manipulação de cabeçalho SMTP é para o uso da distribuição de e-mails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo: O segmento de código a seguir lê o assunto e o corpo de um formulário "Fale conosco":


$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);


Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


...
subject: [Contact us query] Page not working
...


No entanto, como o valor do cabeçalho é construído a partir de uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


Isso permitirá efetivamente que um invasor elabore mensagens de spam ou envie e-mails anônimos entre outros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
A inclusão de dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho SMTP ocorrem quando:

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

2. Os dados são incluídos em um cabeçalho SMTP enviado para um servidor de e-mail sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho SMTP é 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 cabeçalho SMTP.

Um dos ataques mais comuns de Manipulação de cabeçalho SMTP é para o uso da distribuição de e-mails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo: O segmento de código a seguir lê o assunto e o corpo de um formulário "Fale conosco":


body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)


Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


...
subject: [Contact us query] Page not working
...


No entanto, como o valor do cabeçalho é construído a partir de uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


Isso permitirá efetivamente que um invasor elabore mensagens de spam ou envie e-mails anônimos entre outros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
A utilização incorreta de informações privadas, como senhas ou números de segurança social de clientes, pode comprometer a privacidade dos usuários e em muitos casos é um procedimento ilegal.
Explanation
Violações de privacidade ocorrem quando:

1. Informações privadas de usuários entram no programa.

2. Os dados são gravados em um local externo, como o console, o sistema de arquivos ou a rede.
Exemplo 1: O código a seguir contém uma instrução de log que rastreia os registros adicionados a um banco de dados, armazenando o conteúdo em um arquivo de log.


pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);


O código no Example 1 registra uma senha de texto sem formatação no sistema de arquivos. Embora muitos desenvolvedores confiem no log de eventos como um local de armazenamento seguro para os dados, ele não deve ser confiado de forma implícita, especialmente quando a privacidade é uma preocupação.

A privacidade é uma das maiores preocupações no mundo móvel por alguns motivos. Um deles é uma chance muito maior de perda do dispositivo. O outro tem a ver com a comunicação entre processos de aplicativos móveis. Com plataformas móveis, os aplicativos são baixados de várias fontes e são executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta e é por isso que os autores de aplicativos precisam ser cuidadosos a respeito de quais informações eles incluem em mensagens endereçadas a outros aplicativos em execução no dispositivo. Informações confidenciais nunca devem fazer parte da comunicação entre processos de aplicativos móveis.

Exemplo 2: O código a seguir lê o nome de usuário e a senha de um determinado site em um repositório WebView do Android e os transmite a todos os receptores registrados.

...
webview.setWebViewClient(new WebViewClient() {
public void onReceivedHttpAuthRequest(WebView view,
HttpAuthHandler handler, String host, String realm) {
String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
String username = credentials[0];
String password = credentials[1];
Intent i = new Intent();
i.setAction("SEND_CREDENTIALS");
i.putExtra("username", username);
i.putExtra("password", password);
view.getContext().sendBroadcast(i);
}
});
...


Esse exemplo demonstra vários problemas. Em primeiro lugar, por padrão, credenciais WebView são armazenadas em texto sem formatação e não estão em hash. Se um usuário tiver um dispositivo raiz (ou usar um emulador), ele poderá ler senhas armazenadas para sites específicos. Em segundo lugar, credenciais de texto sem formatação são transmitidas para todos os receptores registrados, o que significa que qualquer receptor registrado para ouvir intenções com a ação SEND_CREDENTIALS receberá a mensagem. A transmissão nem mesmo é protegida com uma permissão para limitar o número de destinatários, embora, neste caso, não recomendemos o uso de permissões como correção.

Dados privados podem entrar em um programa de várias maneiras:

- Diretamente do usuário em formato de senha ou informações pessoais

- Acessados a partir de um banco de dados ou outro repositório de dados pelo aplicativo

- Indiretamente de um parceiro ou de terceiros

Normalmente, no contexto do ambiente móvel, essas informações privadas incluem (juntamente com senhas, SSNs e outras informações pessoais gerais):

- Localização

- Número do celular

- Números de série e IDs de dispositivo

- Informações sobre a operadora de rede

- Informações de correio de voz


Às vezes, dados não rotulados como privados podem ter uma implicação de privacidade em um contexto diferente. Por exemplo, números de identificação de aluno geralmente não são considerados privados, pois não há um mapeamento explícito e publicamente disponível para as informações pessoais de um aluno individual. No entanto, se uma escola gerar números de identificação com base em números de segurança social de alunos, esses números de identificação deverão ser considerados privados.

Preocupações de segurança e privacidade muitas vezes parecem competir umas com as outras. Sob o ponto de vista da segurança, você deve registrar todas as operações importantes para que qualquer atividade anormal possa ser identificada mais tarde. No entanto, quando dados privados estão envolvidos, essa prática pode gerar riscos.

Embora existam muitas maneiras de manipular dados privados sem segurança, um risco comum está relacionado a equívocos de confiança. Os programadores muitas vezes confiam no ambiente operacional em que um programa é executado e, portanto, julgam aceitável armazenar informações privadas no sistema de arquivos, no registro ou em outros recursos localmente controlados. No entanto, mesmo se o acesso a determinados recursos for restrito, isso não garante que os indivíduos que possuem esse acesso possam ser confiáveis. Por exemplo, em 2004, um funcionário sem escrúpulos da AOL vendeu cerca de 92 milhões de endereços de email privados de clientes para um remetente de spam que comercializava um site de jogatina em atividade fora do país [1].

Em resposta a tais explorações notórias, a coleta e o gerenciamento de dados privados estão se tornando cada vez mais regulamentados. Dependendo da sua localização, do tipo de negócios administrado e da natureza de quaisquer dados privados que ela manipule, uma organização pode ser obrigada a cumprir uma ou mais das seguintes normas federais e estaduais:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Apesar dessas normas, violações de privacidade continuam a ocorrer com uma frequência alarmante.
References
[1] J. Oates AOL man pleads guilty to selling 92m email addies The Register
[2] Privacy Initiatives U.S. Federal Trade Commission
[3] Safe Harbor Privacy Framework U.S. Department of Commerce
[4] Financial Privacy: The Gramm-Leach Bliley Act (GLBA) Federal Trade Commission
[5] Health Insurance Portability and Accountability Act (HIPAA) U.S. Department of Human Services
[6] California SB-1386 Government of the State of California
[7] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[8] SQLCipher.
[9] FUNDAMENTALS-4: Establish trust boundaries Oracle
[10] CONFIDENTIAL-2: Do not log highly sensitive information Oracle
[11] Standards Mapping - Common Weakness Enumeration CWE ID 359
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[14] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000169
[16] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1), AU-12 Audit Generation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement, AU-12 Audit Record Generation
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[22] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[24] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[25] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 6.5.5, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 8.3.1
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000650 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000650 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000650 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000650 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000650 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000650 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000650 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000650 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000650 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000650 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000650 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000650 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000650 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000650 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.java.pci_privacy_violation
Abstract
Construir uma instrução de seleção SimpleDB que contém entradas do usuário pode permitir que um invasor visualize registros não autorizados.
Explanation
Vulnerabilidades de injeção de string de consulta ocorrem quando:
1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma string de consulta SimpleDB.

Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta select() SimpleDB que procura faturas correspondentes a uma categoria de produto especificada pelo usuário. O usuário também pode especificar a coluna pela qual os resultados são classificados. Suponha que o aplicativo já tenha sido devidamente autenticado e defina o valor de customerID antes desse segmento de código.


...
String customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
...
AmazonSimpleDBClient sdbc = new AmazonSimpleDBClient(appAWSCredentials);
String query = "select * from invoices where productCategory = '"
+ productCategory + "' and customerID = '"
+ customerID + "' order by '"
+ sortColumn + "' asc";
SelectResult sdbResult = sdbc.select(new SelectRequest(query));
...


A consulta que esse código pretende executar se parece com a seguinte:


select * from invoices
where productCategory = 'Fax Machines'
and customerID = '12345678'
order by 'price' asc


No entanto, como a consulta é construída dinamicamente por meio da concatenação de uma string de consulta base constante e de uma string de entrada do usuário, ela apenas se comportará corretamente se productCategory e price não contiverem caracteres de aspas simples. Porém, se um invasor fornecer a string "Fax Machines' or productCategory = \"" para productCategory e a string "\" order by 'price" para sortColumn, a consulta se tornará a seguinte:


select * from invoices
where productCategory = 'Fax Machines' or productCategory = "'
and customerID = '12345678'
order by '" order by 'price' asc


ou, de uma forma mais legível,


select * from invoices
where productCategory = 'Fax Machines'
or productCategory = "' and customerID = '12345678' order by '"
order by 'price' asc


Essas entradas permitem que um invasor ignore a autenticação necessária para customerID e permite que ele veja registros de faturas correspondentes a 'Fax Machines' para todos os clientes.
References
[1] Secure Use of Cloud Storage
[2] Standards Mapping - Common Weakness Enumeration CWE ID 89
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.java.query_string_injection_amazon_web_services
Abstract
Construir uma instrução de consulta SQLite que contém entradas do usuário pode permitir que um invasor visualize registros não autorizados.
Explanation
Vulnerabilidades de injeção de string de consulta ocorrem quando:
1. Os dados entram em um programa por uma fonte não confiável.



Nesse caso, o Fortify Static Code Analyzer não conseguiu determinar se a fonte dos dados é confiável.

2. Os dados são usados para construir dinamicamente uma consulta SQLite.

A injeção de strings de consulta SQLite permite que usuários mal-intencionados visualizem registros não autorizados, mas não permite que eles alterem o estado do banco de dados de qualquer maneira.

Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta SQLite que procura faturas associadas a um cliente e uma categoria de produto especificada pelo usuário. O usuário também pode especificar a coluna pela qual os resultados devem ser classificados. Suponha que o programa já tenha sido devidamente autenticado e defina o valor de customerID antes desse segmento de código.


...
productCategory = this.getIntent().getExtras().getString("productCategory");
sortColumn = this.getIntent().getExtras().getString("sortColumn");
customerID = getAuthenticatedCustomerID(customerName, customerCredentials);
c = invoicesDB.query(Uri.parse(invoices), columns, "productCategory = '" + productCategory + "' and customerID = '" + customerID + "'", null, null, null, "'" + sortColumn + "'asc", null);
...


A consulta que esse código pretende executar se parece com a seguinte:


select * from invoices
where productCategory = 'Fax Machines'
and customerID = '12345678'
order by 'price' asc


No entanto, a consulta é construída dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário productCategory. Portanto, ela se comportará corretamente somente se productCategory e sortColumn não contiverem caracteres de aspas simples. Se um invasor fornecer a string "Fax Machines' or productCategory = \"" para productCategory e a string "\" order by 'price" para sortColumn, a consulta se tornará:


select * from invoices
where productCategory = 'Fax Machines' or productCategory = "'
and customerID = '12345678'
order by '" order by 'price' asc


ou, de maneira mais legível,


select * from invoices
where productCategory = 'Fax Machines'
or productCategory = "' and customerID = '12345678' order by '"
order by 'price' asc


Essas entradas permitem que um invasor ignore a autenticação necessária para customerID e permite que ele veja registros de faturas correspondentes a 'Fax Machines' para todos os clientes.
References
[1] Android Developers-Reference: SQLite Database
[2] SQL as Understood by SQLite
[3] Standards Mapping - Common Weakness Enumeration CWE ID 89
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[60] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.semantic.java.query_string_injection_android_provider
Abstract
O programa acessa uma variável de forma ambígua, o que pode deixá-lo aberto a ataques.
Explanation
A classe HttpRequest fornece acesso programático a variáveis das coleções QueryString, Form, Cookies ou ServerVariables sob a forma de um acesso de array (por exemplo, Request["myParam"]). Quando há mais de uma variável com o mesmo nome, o .NET Framework retorna o valor da variável que aparece primeiro quando as coleções são pesquisadas, na ordem seguinte: QueryString, Form, Cookies e depois ServerVariables. Como QueryString vem em primeiro lugar na ordem de pesquisa, é possível que parâmetros QueryString substituam valores de formulários, cookies e variáveis de servidor. Da mesma forma, valores de formulário podem substituir variáveis nas coleções Cookies e ServerVariables, enquanto variáveis da coleção Cookies podem substituir as de ServerVariables.
Exemplo 1: Imagine que um aplicativo de operações bancários armazena temporariamente o endereço de e-mail de um usuário em um cookie e lê esse valor quando deseja entrar em contato com o usuário. O código a seguir lê o valor do cookie e envia um saldo de conta ao endereço de e-mail especificado.

...
String toAddress = Request["email"]; //Expects cookie value
Double balance = GetBalance(userID);
SendAccountBalance(toAddress, balance);
...

Suponha que o código no Example 1 seja executado durante uma visita a http://www.example.com/GetBalance.aspx. Se um invasor puder fazer com que um usuário autenticado clique em um link que solicita http://www.example.com/GetBalance.aspx?email=evil%40evil.com, um e-mail com o saldo da conta desse usuário será enviado para evil@evil.com.
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[2] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[3] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[11] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[12] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
desc.semantic.dotnet.value_shadowing
Abstract
O programa acessa uma variável do servidor de forma ambígua, o que pode deixá-lo aberto a ataques.
Explanation
A classe HttpRequest fornece acesso programático a variáveis das coleções QueryString, Form, Cookies ou ServerVariables sob a forma de um acesso de array (por exemplo, Request["myParam"]). Quando há mais de uma variável com o mesmo nome, o .NET Framework retorna o valor da variável que aparece primeiro quando as coleções são pesquisadas, na ordem seguinte: QueryString, Form, Cookies e depois ServerVariables. Como QueryString vem em primeiro lugar na ordem de pesquisa, é possível que parâmetros QueryString substituam valores de formulários, cookies e variáveis de servidor. Da mesma forma, valores de formulário podem substituir variáveis nas coleções Cookies e ServerVariables, enquanto variáveis da coleção Cookies podem substituir as de ServerVariables.
Exemplo 1: O código a seguir verifica a variável de servidor do cabeçalho HTTP Referer para ver se a solicitação é proveniente de www.example.com antes de apresentar o conteúdo.

...
if (Request["HTTP_REFERER"].StartsWith("http://www.example.com"))
ServeContent();
else
Response.Redirect("http://www.example.com/");
...


Suponha que o código no Example 1 seja executado durante uma visita a http://www.example.com/ProtectedImages.aspx. Se um invasor realizar uma solicitação direta para a URL, o cabeçalho de referência adequado não será definido e a solicitação falhará. No entanto, se o invasor enviar um parâmetro HTTP_REFERER artificial com o valor necessário, como http://www.example.com/ProtectedImages.aspx?HTTP_REFERER=http%3a%2f%2fwww.example.com, a pesquisa retornará esse valor de QueryString em vez de ServerVariables, e a verificação será bem-sucedida.
References
[1] Microsoft IIS Server Variables
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[11] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[12] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[13] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II
desc.semantic.dotnet.value_shadowing_server_variable