537 itens encontrados
Vulnerabilidades
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.


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


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


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


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


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


<?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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] 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 1: O segmento de código a seguir lê a localização a partir de uma solicitação HTTP e a define no campo de localização de cabeçalho 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] 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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] 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 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.


...
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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] 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
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] 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 1: 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 Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 6.1 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.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 1: O seguinte segmento de código 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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] 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 1: O seguinte segmento de código 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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] 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 1: O seguinte segmento de código 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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] 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
[29] 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
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
O programa cria um campo de formulário oculto.
Explanation
Os programadores geralmente confiam no conteúdo de campos ocultos, esperando que os usuários não sejam capazes de visualizar esses campos ou de manipular seu conteúdo. Os invasores violarão essas suposições. Eles vão examinar os valores gravados em campos ocultos e alterá-los ou substituir o conteúdo por dados de ataque.

Exemplo 1:

HtmlInputHidden hidden = new HtmlInputHidden();


Se campos ocultos contiverem informações confidenciais, estas serão armazenadas em cache da mesma forma que o restante da página. Isso pode fazer com que informações confidenciais sejam escondidas no cache do navegador sem o conhecimento do usuário.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 472
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[5] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[7] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[8] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[32] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.hidden_field
Abstract
O programa cria um campo de formulário oculto.
Explanation
Os programadores geralmente confiam no conteúdo de campos ocultos, esperando que os usuários não sejam capazes de visualizar esses campos ou de manipular seu conteúdo. Os invasores violarão essas suposições. Eles vão examinar os valores gravados em campos ocultos e alterá-los ou substituir o conteúdo por dados de ataque.

Exemplo 1:

Hidden hidden = new Hidden(element);


Se campos ocultos contiverem informações confidenciais, estas serão armazenadas em cache da mesma forma que o restante da página. Isso pode fazer com que informações confidenciais sejam escondidas no cache do navegador sem o conhecimento do usuário.
References
[1] IDS14-J. Do not trust the contents of hidden form fields CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 472
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[6] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[7] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[8] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[9] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[10] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[33] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.hidden_field
Abstract
Um campo de formulário oculto é usado.
Explanation
Os programadores geralmente confiam no conteúdo de campos ocultos, esperando que os usuários não sejam capazes de visualizar esses campos ou de manipular seu conteúdo. Os invasores violarão essas suposições. Eles vão examinar os valores gravados em campos ocultos e alterá-los ou substituir o conteúdo por dados de ataque.

Exemplo 1: Uma tag <input> do tipo hidden indica o uso de um campo oculto.

<input type="hidden">


Se campos ocultos contiverem informações confidenciais, estas serão armazenadas em cache da mesma forma que o restante da página. Isso pode fazer com que informações confidenciais sejam escondidas no cache do navegador sem o conhecimento do usuário.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 472
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[5] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[7] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[8] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[32] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.content.html.hidden_field
Abstract
O cabeçalho X-XSS-Protection é explicitamente desabilitado, o que pode aumentar o risco de ataques de criação de scripts entre sites.
Explanation
O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.

O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] HttpResponse.AppendHeader Method
[4] How to prevent cross-site scripting security issues
[5] HOW TO: Disable the Documentation Protocol for ASP.NET Web Services
[6] Configuring Services Using Configuration Files
[7] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[15] Standards Mapping - FIPS200 CM
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[23] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] 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
[38] 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
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_xss_protection
Abstract
O cabeçalho X-XSS-Protection é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.
Explanation
O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.

O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar a proteção XSS:

<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[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.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_cross_site_scripting_protection
Abstract
O cabeçalho X-XSS-Protection é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.
Explanation
O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.
O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Node.js Security Checklist
[4] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 CM
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[18] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[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.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_cross_site_scripting_protection
Abstract
O cabeçalho X-XSS-Protection é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.
Explanation
O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.

O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] django-secure
[4] SECURE_BROWSER_XSS_FILTER
[5] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 CM
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[19] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[21] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] 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
[36] 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
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_cross_site_scripting_protection
Abstract
O método Application_BeginRequest está vazio ou não inclui uma chamada de função para definir X-Content-Type-Options como nosniff, ou tenta remover esse cabeçalho.
Explanation
Sniffing de MIME é a prática de inspecionar o conteúdo de um fluxo de bytes para tentar deduzir o formato de arquivo dos dados em seu interior.

Se o sniffing de MIME não estiver explicitamente desabilitado, alguns navegadores poderão ser manipulados para interpretar dados de maneiras não planejadas, possibilitando ataques de criação de scripts entre sites.

Para cada página que pode incluir conteúdo controlável pelo usuário, você deve usar o Cabeçalho HTTP X-Content-Type-Options: nosniff.
References
[1] Reducing MIME type security risks
[2] ASP.NET Configuration Files
[3] Global.asax Syntax
[4] IE8 Security Part V: Comprehensive Protection
[5] Custom HttpModule Example
[6] HttpResponse Class
[7] MIME types and stylesheets
[8] Standards Mapping - Common Weakness Enumeration CWE ID 554
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - FIPS200 CM
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[24] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[27] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_mime_sniffing
Abstract
O aplicativo aplica o algoritmo de MIME Sniffing ou não define X-Content-Type-Options como nosniff..
Explanation
MIME sniffing é a prática de inspecionar o conteúdo de um fluxo de bytes para tentar reduzir o formato dos dados de arquivos nele.

Se o sniffing de MIME não estiver explicitamente desabilitado, alguns navegadores poderão ser manipulados para interpretar dados de maneiras não planejadas, possibilitando ataques de criação de scripts entre sites.
Ao escrever um aplicativo Web, use o cabeçalho HTTP X-Content-Type-Options: nosniff para cada página que possa ter conteúdo controlável pelo usuário.
Ao escrever um aplicativo cliente, você não deve usar o algoritmo de MIME Sniffing para determinar a resposta do servidor Content-Type.

Exemplo 1: O código a seguir usa net.http.DetectContentType() para determinar a resposta Content-Type:


...
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)

content_type := DetectContentType(body)
...
References
[1] OWASP OWASP Secure Headers Project
[2] WHATWG MIME Sniffing
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[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 Data Security Standard Version 4.0.1 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
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.golang.html5_mime_sniffing
Abstract
O aplicativo não define X-Content-Type-Options como nosniff ou desabilita esse cabeçalho de segurança explicitamente.
Explanation
MIME Sniffing é a prática de inspecionar o conteúdo de um fluxo de bytes para deduzir o formato de arquivo dos dados nele.

Se MIME Sniffing não for desabilitado explicitamente, os invasores poderão manipular alguns navegadores para interpretar os dados de maneira inadequada, permitindo ataques de cross-site scripting. Para cada página que pode incluir conteúdo controlável pelo usuário, você deve usar o cabeçalho HTTP X-Content-Type-Options: nosniff.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar a proteção contra MIME Sniffing:

<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
References
[1] OWASP OWASP Secure Headers Project
[2] Standards Mapping - Common Weakness Enumeration CWE ID 554
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 CM
[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.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_mime_sniffing
Abstract
O aplicativo Node.js não define X-Content-Type-Options como nosniff ou desabilita esse cabeçalho de segurança explicitamente.
Explanation
MIME sniffing é a prática de inspecionar o conteúdo de um fluxo de bytes para tentar reduzir o formato dos dados de arquivos nele.

Se o sniffing de MIME não estiver explicitamente desabilitado, alguns navegadores poderão ser manipulados para interpretar dados de maneiras não planejadas, possibilitando ataques de criação de scripts entre sites.

Você deveria utilizar o cabeçalho HTTP X-Content-Type-Options: nosniff em cada página que poderia conter conteúdo controlado pelo usuário.
References
[1] Node.js Security Checklist
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[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 Data Security Standard Version 4.0.1 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
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_mime_sniffing
Abstract
O aplicativo Django não define X-Content-Type-Options como nosniff ou desabilita esse cabeçalho de segurança explicitamente.
Explanation
MIME sniffing é a prática de inspecionar o conteúdo de um fluxo de bytes para tentar reduzir o formato dos dados de arquivos nele.

Se o sniffing de MIME não estiver explicitamente desabilitado, alguns navegadores poderão ser manipulados para interpretar dados de maneiras não planejadas, possibilitando ataques de criação de scripts entre sites.

Você deveria utilizar o cabeçalho HTTP X-Content-Type-Options: nosniff em cada página que poderia conter conteúdo controlado pelo usuário.
References
[1] SECURE_CONTENT_TYPE_NOSNIFF
[2] django-secure
[3] OWASP OWASP Secure Headers Project
[4] Standards Mapping - Common Weakness Enumeration CWE ID 554
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 CM
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[18] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[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 Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_mime_sniffing
Abstract
A CSP (Política de Segurança de Conteúdo) não está configurada.
Explanation
A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativa que permite aos desenvolvedores ditar de quais domínios o local tem permissão para carregar conteúdo ou iniciar conexões durante a renderização no navegador da Web. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a verificação de lista de permissões no código.

O Spring Security e outras estruturas não adicionam cabeçalhos da Política de Segurança de Conteúdo por padrão. O autor do aplicativo Web deve declarar as políticas de segurança a serem impostas ou monitoradas para que os recursos protegidos se beneficiem dessa camada adicional de segurança.
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1173
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_missing_content_security_policy
Abstract
O aplicativo não impede os navegadores de permitir que sites de terceiros renderizem seu conteúdo.
Explanation
Se você permitir que seu site seja adicionado a um quadro, isso poderá acarretar um problema de segurança. Por exemplo, isso pode levar a vulnerabilidades de clickjacking ou permitir comunicações indesejadas entre quadros.

Por padrão, estruturas como o Spring Security incluem o cabeçalho X-Frame-Options para indicar ao navegador se o aplicativo deve ser enquadrado. Se você desabilitar ou não definir esse cabeçalho, isso poderá levar a vulnerabilidades entre quadros.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar o cabeçalho X-Frame-Options:

<http auto-config="true">
...
<headers>
...
<frame-options disabled="true"/>
</headers>
</http>
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 1021
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.7 HTTP Security Headers Requirements (L1 L2 L3)
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_missing_framing_protection
Abstract
A CSP (Política de Segurança de Conteúdo) é configurada com uma política excessivamente permissiva, que pode representar riscos à segurança.
Explanation
A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativo que permite que os desenvolvedores especifiquem o comportamento permitido relacionado à segurança no navegador, incluindo uma lista de permissões locais dos quais o conteúdo pode ser recuperado. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a verificação de lista de permissões no código. Um cabeçalho configurado incorretamente, no entanto, deixa de fornecer esta camada adicional de segurança. A política é definida com a ajuda de quinze diretivas, incluindo oito que controlam o acesso aos recursos: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. Essas oito diretivas usam uma lista de fontes como um valor que especifica domínios que o site pode acessar para um recurso abrangido por essa diretiva. Os desenvolvedores podem usar um curinga * para indicar a totalidade da fonte ou parte dela. Palavras-chave adicionais da lista de fontes, como 'unsafe-inline' e 'unsafe-eval', fornecem um controle mais granular sobre a execução do script, mas são potencialmente prejudiciais. Nenhuma das diretrizes é obrigatória. Os navegadores permitem todas as fontes para uma diretiva não listada ou derivam seu valor da diretiva opcional default-src. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP no Chrome até a versão 25. Esses dois nomes foram substituídos pelo atual nome padrão Content Security Policy. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.

Exemplo 1: O seguinte código define uma diretiva default-src excessivamente flexível e insegura:

<http auto-config="true">
...
<headers>
...
<content-security-policy policy-directives="default-src '*'" />
</headers>
</http>
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[23] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_overly_permissive_content_security_policy
Abstract
A CSP (Política de Segurança de Conteúdo) é configurada com uma política excessivamente permissiva, que pode representar riscos à segurança.
Explanation
A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativo que permite que os desenvolvedores especifiquem o comportamento permitido relacionado à segurança no navegador, incluindo uma lista de permissões com locais dos quais o conteúdo pode ser recuperado. Isso fornece uma camada adicional de segurança contra vulnerabilidades críticas, como criação de script entre sites, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a criação de uma lista de permissões no código. Um cabeçalho configurado incorretamente, no entanto, deixa de fornecer essa camada adicional de segurança. A política é definida com a ajuda de quinze diretivas, incluindo oito que controlam o acesso aos recursos: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. Essas oito diretivas usam uma lista de fontes como um valor que especifica domínios que o site pode acessar para um recurso abrangido por essa diretiva. Os desenvolvedores podem usar um curinga * para indicar a totalidade da fonte ou parte dela. Palavras-chave adicionais da lista de fontes, como 'unsafe-inline' e 'unsafe-eval', fornecem um controle mais granular sobre a execução do script, mas são potencialmente prejudiciais. Nenhuma das diretrizes é obrigatória. Os navegadores permitem todas as fontes para uma diretiva não listada ou derivam seu valor da diretiva opcional default-src. Ademais, a especificação para esse cabeçalho tem evoluído ao longo do tempo. Ela foi implementada como X-Content-Security-Policy no Firefox até a versão 23 e no IE até a versão 10, e foi implementada como X-Webkit-CSP no Chrome até a versão 25. Esses dois nomes foram substituídos pelo atual nome padrão Content Security Policy. Dada a quantidade de diretivas, dois nomes alternativos obsoletos, e a forma como várias ocorrências do mesmo cabeçalho e diretivas repetidas em um único cabeçalho são tratados, há uma alta probabilidade de que um desenvolvedor possa configurar mal esse cabeçalho.

Nesse caso, uma diretiva*-src foi configurada com uma política excessivamente permissiva, como *Exemplo 1: Esta configuração django-csp define uma diretiva default-src excessivamente permissiva e insegura:


...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Mozilla django-csp
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[8] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_overly_permissive_content_security_policy
Abstract
O programa define uma política de CORS (Compartilhamento de Recursos entre Origens) excessivamente permissiva.
Explanation
Antes do HTML5, os navegadores da Web forçavam a Política de Mesma Origem, que garante que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e, depois, comunicá-las ao invasor. O HTML5 permite que o JavaScript acesse dados entre vários domínios quando um novo cabeçalho HTTP denominado Access-Control-Allow-Origin é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: Veja a seguir um exemplo de uso de um caractere curinga para especificar programaticamente os domínios com os quais o aplicativo tem permissão para se comunicar.


Response.AppendHeader("Access-Control-Allow-Origin", "*");


O uso de * como valor do cabeçalho Access-Control-Allow-Origin indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.dotnet.html5_overly_permissive_cors_policy
Abstract
O programa define uma política excessivamente permissiva de Compartilhamento de recursos de origem cruzada (CORS).
Explanation
Antes do HTML5, os navegadores da Web forçavam a Política de Mesma Origem, que garante que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e, depois, comunicá-las ao invasor. O HTML5 permite que o JavaScript acesse dados entre vários domínios quando um novo cabeçalho HTTP denominado Access-Control-Allow-Origin está definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: Veja a seguir um exemplo de uso de um caractere curinga para especificar programaticamente os domínios com os quais o aplicativo tem permissão para se comunicar.


<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>


Usar * como o valor do cabeçalho Access-Control-Allow-Origin indica que os dados do aplicativo podem ser acessados pelo JavaScript em execução em qualquer domínio.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_overly_permissive_cors_policy
Abstract
O programa define uma política de CORS (Compartilhamento de Recursos entre Origens) excessivamente permissiva.
Explanation
Antes do HTML5, os navegadores da Web forçavam a Política de Mesma Origem, que garante que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e, depois, comunicá-las ao invasor. O HTML5 permite que o JavaScript acesse dados entre vários domínios quando um novo cabeçalho HTTP denominado Access-Control-Allow-Origin é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: Veja a seguir um exemplo de uso de um caractere curinga para especificar programaticamente os domínios com os quais o aplicativo tem permissão para se comunicar.


<?php
header('Access-Control-Allow-Origin: *');
?>


O uso de * como valor do cabeçalho Access-Control-Allow-Origin indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.php.html5_overly_permissive_cors_policy
Abstract
O programa define uma política de CORS (Compartilhamento de Recursos entre Origens) excessivamente permissiva.
Explanation
Antes do HTML5, os navegadores da Web forçavam a Política de Mesma Origem, que garante que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer um JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e depois as comunicar ao invasor. O HTML5 permite que o JavaScript acesse dados entre vários domínios quando um novo cabeçalho HTTP denominado Access-Control-Allow-Origin é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: Veja a seguir um exemplo de uso de um caractere curinga para especificar programaticamente os domínios com os quais o aplicativo tem permissão para se comunicar.


response.addHeader("Access-Control-Allow-Origin", "*")


O uso de * como valor do cabeçalho Access-Control-Allow-Origin indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.python.html5_overly_permissive_cors_policy
Abstract
O programa define uma política de CORS (Compartilhamento de Recursos entre Origens) excessivamente permissiva.
Explanation
Antes do HTML5, os navegadores da Web forçavam a Política de Mesma Origem, que garante que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer um JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e depois as comunicar ao invasor. O HTML5 permite que o JavaScript acesse dados entre vários domínios quando um novo cabeçalho HTTP denominado Access-Control-Allow-Origin é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: Veja a seguir um exemplo de uso de um caractere curinga para especificar os domínios com os quais o aplicativo tem permissão para se comunicar.


play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}


O uso de * como valor do cabeçalho Access-Control-Allow-Origin indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.scala.html5_overly_permissive_cors_policy
Abstract
O programa define uma política de CORS (Compartilhamento de Recursos entre Origens) excessivamente permissiva.
Explanation
Antes do HTML5, os navegadores da Web forçavam a Política de Mesma Origem, que garante que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto o JavaScript quanto a página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e, depois, comunicá-las ao invasor. O HTML5 permite que o JavaScript acesse dados entre vários domínios quando um novo cabeçalho HTTP denominado Access-Control-Allow-Origin é definido. Com esse cabeçalho, um servidor Web define quais outros domínios podem acessar seu domínio usando solicitações entre origens. No entanto, tenha cuidado ao definir o cabeçalho, pois uma política de CORS excessivamente flexível pode permitir que um aplicativo mal-intencionado se comunique inadequadamente com o aplicativo vítima, o que pode levar a falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: Veja a seguir um exemplo de uso de um caractere curinga para especificar programaticamente os domínios com os quais o aplicativo tem permissão para se comunicar.


Response.AddHeader "Access-Control-Allow-Origin", "*"


O uso de * como valor do cabeçalho Access-Control-Allow-Origin indica que os dados do aplicativo são acessíveis ao JavaScript em execução em qualquer domínio.
References
[1] W3C Cross-Origin Resource Sharing
[2] Enable Cross-Origin Resource Sharing
[3] Michael Schmidt HTML5 Web Security
[4] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[5] Standards Mapping - Common Weakness Enumeration CWE ID 942
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.6 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.vb.html5_overly_permissive_cors_policy
Abstract
O programa publica uma mensagem entre documentos com uma origem pretendida excessivamente permissiva.
Explanation
Um dos novos recursos do HTML5 é enviar mensagens entre documentos. O recurso permite que os scripts publiquem mensagens em outras janelas. A API correspondente permite ao usuário especificar a origem da janela de destino. No entanto, deve-se ter cautela ao especificar a origem pretendida porque caso ela seja excessivamente permissiva, permitirá que um script malicioso se comunique com a janela da vítima de forma inadequada, levando à falsificação, ao roubo de dados, a ataques de retransmissão e outros.

Exemplo 1: O exemplo a seguir usa um curinga para especificar programaticamente a origem pretendida da mensagem a ser enviada.


WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
webview.postWebMessage(message, Uri.parse("*"));


Usar o * como o valor da origem pretendida indica que o script está enviando uma mensagem a uma janela, independentemente da respectiva origem.
References
[1] Michael Schmidt HTML5 Web Security
[2] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[3] Standards Mapping - Common Weakness Enumeration CWE ID 942
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
desc.controlflow.java.html5_overly_permissive_message_posting_policy
Abstract
O programa publica uma mensagem entre documentos com uma origem pretendida excessivamente permissiva.
Explanation
Um dos novos recursos do HTML5 é enviar mensagens entre documentos. O recurso permite que os scripts publiquem mensagens em outras janelas. A API correspondente permite ao usuário especificar a origem da janela de destino. No entanto, deve-se ter cautela ao especificar a origem pretendida porque caso ela seja excessivamente permissiva, permitirá que um script malicioso se comunique com a janela da vítima de forma inadequada, levando à falsificação, ao roubo de dados, a ataques de retransmissão e outros.

Exemplo 1: O exemplo a seguir usa um curinga para especificar programaticamente a origem pretendida da mensagem a ser enviada.


o.contentWindow.postMessage(message, '*');


Usar o * como o valor da origem pretendida indica que o script está enviando uma mensagem a uma janela, independentemente da respectiva origem.
References
[1] Michael Schmidt HTML5 Web Security
[2] Philippe De Ryck, Lieven Desmet, Pieter Philippaerts, and Frank Piessens A Security Analysis of Next Generation Web Standards
[3] Standards Mapping - Common Weakness Enumeration CWE ID 942
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
desc.structural.javascript.html5_overly_permissive_message_posting_policy
Abstract
Se você definir o cabeçalho Referrer-Policy como Unsafe-URL, isso poderá fazer com que os aplicativos exponham dados confidenciais de sites e de usuários (incluindo token de sessão, nomes de usuário e senhas) a sites de terceiros.
Explanation
Os navegadores não enviam o cabeçalho do referenciador por padrão com solicitações originadas de HTTPS para links HTTP não criptografados. No entanto, quando um destino de solicitação também é HTTPS, o cabeçalho é enviado independentemente da origem. Um desenvolvedor pode deixar informações confidenciais em URLs, que são expostas a sites de terceiros por meio do cabeçalho do referenciador. O cabeçalho Referrer-Policy é introduzido para controlar o comportamento do navegador em relação ao cabeçalho do referenciador. A opção Unsafe-URL remove todas as restrições e envia o cabeçalho do referenciador com cada solicitação.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar a política de referenciador segura padrão:

<http auto-config="true">
...
<headers>
...
<referrer-policy policy="unsafe-url"/>
</headers>
</http>
References
[1] Referrer-Policy
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 942
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [18] CWE ID 863
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002418, CCI-002420, CCI-002421, CCI-002422
[7] Standards Mapping - FIPS200 CM
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3250.1 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3250.1 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3250.1 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3250.1 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3250.1 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002440 CAT I, APSC-DV-002450 CAT II, APSC-DV-002460 CAT II, APSC-DV-002470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.html5_overly_permissive_referrer_policy
Abstract
A CSP (Política de Segurança de Conteúdo) está configurada no modo de monitor, o que significa que o navegador não a impõe.
Explanation
A CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativa que permite aos desenvolvedores ditar de quais domínios o local tem permissão para carregar conteúdo ou iniciar conexões durante a renderização no navegador da Web. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking, acesso entre origens e similares, sobre a validação de entrada e a verificação de lista de permissões no código.

O cabeçalho Content-Security-Policy-Report-Only fornece a autores e administradores de aplicativos Web a capacidade de monitorar políticas de segurança, em vez de impô-las. Esse cabeçalho geralmente é usado ao serem experimentadas e/ou desenvolvidas políticas de segurança para um site. Quando uma política é considerada efetiva, você pode impô-la usando o campo de cabeçalho Content-Security-Policy.

Exemplo 1: O seguinte código define uma Política de Segurança de Conteúdo no modo Report-Only:

<http auto-config="true">
...
<headers>
...
<content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
</headers>
</http>
References
[1] Mozilla Content Security Policy
[2] W3C Content Security Policy 2.0
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_unenforced_content_security_policy
Abstract
Uma CSP (Política de Segurança de Conteúdo) é configurada no modo de monitor, o que significa que o navegador não a impõe.
Explanation
Uma CSP (Política de Segurança de Conteúdo) é um cabeçalho de segurança declarativa que permite aos desenvolvedores ditar de quais domínios o local tem permissão para carregar conteúdo ou iniciar conexões durante a renderização no navegador da Web. Ela fornece uma camada adicional de segurança contra vulnerabilidades críticas, como cross-site scripting, clickjacking e acesso entre origens, além de validação de entrada e verificação de uma lista de permissões no código.

O cabeçalho Content-Security-Policy-Report-Only fornece a autores e administradores de aplicativos Web a capacidade de monitorar políticas de segurança, em vez de impô-las. Esse cabeçalho geralmente é usado ao serem experimentadas e/ou desenvolvidas políticas de segurança para um site. Quando uma política é considerada efetiva, você pode impô-la usando o cabeçalho Content-Security-Policy.

Exemplo 1: O seguinte código define uma Política de Segurança de Conteúdo como o modo Report-Only:

response.content_security_policy_report_only = "*"
References
[1] OWASP Content Security Policy
[2] W3C Content Security Policy 1.1
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_unenforced_content_security_policy
Abstract
Concatenar entradas não validadas em uma URL pode permitir que um invasor substitua o valor de um parâmetro de solicitação. O invasor pode ser capaz de substituir valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de alcance direto.
Explanation
Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Talvez ele obtenha dados somente do primeiro parâmetro
Talvez ele obtenha dados do último parâmetro
Talvez ele obtenha dados de todos os parâmetros e os concatene


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor de aplicativos e da lógica do aplicativo propriamente dito, a seguinte solicitação pode causar confusão para o sistema de autenticação e permitir que um invasor represente outro usuário.
http://www.server.com/login.aspx?name=alice&name=hacker

Exemplo 2: O código a seguir usa a entrada de uma solicitação HTTP para produzir dois hiperlinks.

...
String lang = Request.Form["lang"];
WebClient client = new WebClient();
client.BaseAddress = url;
NameValueCollection myQueryStringCollection = new NameValueCollection();
myQueryStringCollection.Add("q", lang);
client.QueryString = myQueryStringCollection;
Stream data = client.OpenRead(url);
...


URL: http://www.host.com/election.aspx?poll_id=4567
Link1: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">English<a>
Link2: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">Spanish<a>

O programador não considerou a possibilidade de que um invasor pudesse fornecer um lang como en&poll_id=1 e, em seguida, conseguisse alterar poll_id à vontade.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.http_parameter_pollution
Abstract
Concatenar entradas não validadas em uma URL pode permitir que um invasor substitua o valor de um parâmetro de solicitação. O invasor pode ser capaz de substituir valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de alcance direto.
Explanation
Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Talvez ele obtenha dados somente do primeiro parâmetro
Talvez ele obtenha dados do último parâmetro
Talvez ele obtenha dados de todos os parâmetros e os concatene


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor de aplicativos e da lógica do aplicativo propriamente dito, a seguinte solicitação pode causar confusão para o sistema de autenticação e permitir que um invasor represente outro usuário.
http://www.example.com/login.php?name=alice&name=hacker

Exemplo 2: O código a seguir usa a entrada de uma solicitação HTTP para produzir dois hiperlinks.

...
String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.example.com");
get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
get.execute();
...


URL: http://www.example.com?poll_id=4567
Link1: <a href="001">Inglês<a>
Link2: <a href="002">Espanhol<a>

O programador não considerou a possibilidade de que um invasor pudesse fornecer um lang como en&poll_id=1 e, em seguida, fosse capaz de alterar poll_id à vontade.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.http_parameter_pollution
Abstract
Concatenar entradas não validadas em uma URL pode permitir que um invasor substitua o valor de um parâmetro de solicitação. O invasor pode ser capaz de substituir valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de alcance direto.
Explanation
Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Talvez ele obtenha dados somente do primeiro parâmetro
Talvez ele obtenha dados do último parâmetro
Talvez ele obtenha dados de todos os parâmetros e os concatene


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor de aplicativos e da lógica do aplicativo propriamente dito, a seguinte solicitação pode causar confusão para o sistema de autenticação e permitir que um invasor represente outro usuário.
http://www.server.com/login.php?name=alice&name=hacker

Exemplo 2: O código a seguir usa a entrada de uma solicitação HTTP para produzir dois hiperlinks.


<%
...
$id = $_GET["id"];
header("Location: http://www.host.com/election.php?poll_id=" . $id);
...
%>


URL: http://www.host.com/election.php?poll_id=4567
Link1: <a href="vote.php?poll_id=4567&candidate=white">Vote no Sr. White<a>
Link2: <a href="vote.php?poll_id=4567&candidate=green">Vote na Sra. Green<a>

O programador não considerou a possibilidade de que um invasor pode fornecer uma poll_id como "4567&candidate=green" e, em seguida, a página resultante conterá os seguintes links injetados e, portanto, Sra. Green será sempre votada em um servidor de aplicativo que seleciona o primeiro parâmetro.
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Vote no Sr. White<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Vote na Sra. Green<a>
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.http_parameter_pollution
Abstract
Concatenar entradas não validadas em uma URL pode permitir que um invasor substitua o valor de um parâmetro de solicitação. O invasor pode ser capaz de substituir valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de alcance direto.
Explanation
Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Ele pode obter apenas os dados do primeiro parâmetro.
Ele pode obter os dados do último parâmetro.
Ele pode obter os dados de todos os parâmetros e concatená-los.


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor do aplicativo e da lógica do próprio aplicativo, esta solicitação pode causar confusão para o sistema de autenticação e permitir a um invasor representar outro usuário.
http://www.server.com/login.php?name=alice&name=hacker

Conforme demonstrado, o invasor já especificou name=alice, mas adicionou name=alice& e, se isso estiver em uso em um servidor que obtém a primeira ocorrência, ele poderá representar alice para obter mais informações sobre a conta dela.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 API 2023 API1 Broken Object Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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 4.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.http_parameter_pollution
Abstract
As restrições de segurança que especificam verbos HTTP geralmente permitem mais acesso do que o pretendido.
Explanation
Os mecanismos de autenticação e autorização de um aplicativo podem ser contornados com adulteração dos verbos HTTP quando:
1) Ele usa um controle de segurança que lista os verbos HTTP.
2) O controle de segurança falha em bloquear verbos que não estão listados.
3) O aplicativo atualiza seu estado com base em solicitações GET ou outros verbos HTTP arbitrários.



A configuração a seguir é vulnerável a adulteração de verbo HTTP:

<authorization>
<allow verbs="GET,POST" users="admin"/>
<deny verbs="GET,POST"users="*" />
</authorization>

Por padrão, o .NET Framework permite todos os verbos HTTP e, portanto, mesmo que essa configuração negue GETs e POSTs para todos os usuários, que não impede solicitações HEAD. Talvez seja possível para um invasor usufruir de funcionalidades administrativas substituindo solicitações GET ou POST por solicitações HEAD. Em outras palavras, esse código satisfaz as condições 1 e 2 mencionadas anteriormente. Para que solicitações HEAD usufruam de funcionalidades administrativas, basta que o aplicativo realize comandos com base em solicitações que utilizam verbos diferentes de POST.

Basicamente, essa vulnerabilidade é o resultado de uma tentativa de criar uma lista de negação - uma política que especifica o que os usuários não têm permissão para fazer. Listas de negação raramente alcançam o efeito pretendido.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 288, CWE ID 302
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [25] CWE ID 306
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[13] Standards Mapping - OWASP API 2023 API5 Broken Function Level Authorization
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[48] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.config.dotnet.http_verb_tampering
Abstract
As restrições de segurança que especificam verbos HTTP geralmente permitem mais acesso do que o pretendido.
Explanation
Os mecanismos de autenticação e autorização de um aplicativo podem ser contornados com adulteração dos verbos HTTP quando:
1) Ele usa um controle de segurança que lista os verbos HTTP.
2) O controle de segurança falha em bloquear verbos que não estão listados.
3) O aplicativo atualiza seu estado com base em solicitações GET ou outros verbos HTTP arbitrários.



A maioria das implementações Java EE permite métodos HTTP que não estão explicitamente listados na configuração. Por exemplo, a seguinte restrição de segurança é aplicada ao método HTTP GET, mas não a outros verbos HTTP:


<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>


Uma vez que verbos como HEAD não são explicitamente definidos em uma tag <http-method> nessa configuração, pode ser possível exercer a funcionalidade administrativa substituindo as solicitações GET ou POST por solicitações HEAD. Para que as solicitações HEAD exerçam a funcionalidade administrativa, a condição 3 deve ser mantida - o aplicativo deve executar comandos baseados em verbos diferentes de POST. Alguns servidores web/de aplicativos aceitarão verbos HTTP não padrão arbitrários e responderão como se tivessem recebido uma solicitação GET. Se for esse o caso, um invasor poderá ver as páginas administrativas usando um verbo arbitrário em uma solicitação.

Por exemplo, uma solicitação GET típica do cliente se parece com:

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com


Em um ataque de adulteração de verbo HTTP, um invasor substituirá GET por algo como FOO

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com


Basicamente, essa vulnerabilidade é o resultado de uma tentativa de criar uma lista de negação - uma política que especifica o que os usuários não têm permissão para fazer. Listas de negação raramente alcançam o efeito pretendido.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 288, CWE ID 302
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [25] CWE ID 306
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[13] Standards Mapping - OWASP API 2023 API5 Broken Function Level Authorization
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
[48] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.config.java.http_verb_tampering
Abstract
A classe é anotada como imutável, mas um campo está alterado.
Explanation
Essa classe foi anotada com a anotação Immutable do pacote de anotações JCIP. No entanto, um dos campos mutáveis da classe tinha um método mutante chamado nele fora do construtor e do destruidor.

Exemplo 1: O código a seguir para uma classe final imutável declara um Set private e final e, em seguida, cria erroneamente um método que transforma o Set.


@Immutable
public final class ThreeStooges {
private final Set stooges = new HashSet>();
...

public void addStooge(String name) {
stooges.add(name);
}
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 471
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_field_mutation
Abstract
A classe é anotada como imutável, mas um campo não é final.
Explanation
Essa classe foi anotada com a anotação Immutable do pacote de anotações JCIP. Um campo não final viola a imutabilidade da classe permitindo que o valor seja alterado.

Exemplo 1: O código a seguir para uma classe final imutável declara erroneamente um campo public e não final.


@Immutable
public class ImmutableInteger {
public int value;

}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] OBJ58-J. Limit the extensibility of classes and methods with invariants CERT
[4] MUTABLE-1: Prefer immutability for value types Oracle
[5] Standards Mapping - Common Weakness Enumeration CWE ID 471
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_non_final_fields
Abstract
A classe é anotada como imutável, mas um campo é modificado.
Explanation
Essa classe foi anotada com a anotação Immutable do pacote de anotações JCIP. Um campo público de um tipo mutável permite que o código externo à classe modifique o conteúdo e viole a imutabilidade da classe.

Exemplo 1: O código a seguir para uma classe final imutável declara erroneamente um Set public e final.


@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 471
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_public_mutable_fields
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
DATA: r TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i,
var3 TYPE n.


GET TIME.
var1 = sy-uzeit.
r = cl_abap_random=>create( seed = var1 ).
r->int31( RECEIVING value = var2 ).
var3 = var2.
CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.


Esse código usa a função CL_ABAP_RANDOM->INT31 para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como CL_ABAP_RANDOM é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 338
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.abap.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


string GenerateReceiptURL(string baseUrl) {
Random Gen = new Random();
return (baseUrl + Gen.Next().toString() + ".html");
}


Esse código usa a função Random.Next() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Random.Next() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] RandomNumberGenerator Class Microsoft
[2] System.Security.Cryptography Namespace Microsoft
[3] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.dotnet.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


char* CreateReceiptURL() {
int num;
time_t t1;
char *URL = (char*) malloc(MAX_URL);
if (URL) {
(void) time(&t1);
srand48((long) t1); /* use time to set seed */
sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
}
return URL;
}


Esse código usa a função lrand48() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como lrand48() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis.
References
[1] B. Schneier Yarrow: A secure pseudorandom number generator
[2] CryptLib
[3] Crypto++
[4] BeeCrypt
[5] OpenSSL
[6] CryptoAPI: CryptGenRandom() Microsoft
[7] RtlGenRandom() Microsoft
[8] .NET System.Security.Cryptography: Random Number Generation Microsoft
[9] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[10] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[11] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[12] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[13] Standards Mapping - Common Weakness Enumeration CWE ID 338
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[15] Standards Mapping - FIPS200 MP
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[21] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[22] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[24] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[25] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[26] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[27] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.cpp.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.


Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>


Esse código usa a função Rand() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Rand() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] ColdFusion Java CFX Reference Adobe
[2] Java Cryptography Architecture Oracle
[3] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.cfml.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis. No entanto, têm uma saída altamente previsível e formam um fluxo numérico fácil de reproduzir, o que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O seguinte código usa um PRNG estatístico para criar uma chave RSA.


import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)


Esse código usa a função rand.New() para gerar aleatoriedade para uma chave RSA. Como rand.New() é um PRNG estatístico, é fácil para um invasor adivinhar o valor que ele gera.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 338
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.golang.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return (baseUrl + ranGen.nextInt(400000000) + ".html");
}


Esse código usa a função Random.nextInt() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Random.nextInt() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.java.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


function genReceiptURL (baseURL){
var randNum = Math.random();
var receiptURL = baseURL + randNum + ".html";
return receiptURL;
}


Esse código usa a função Math.random() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Math.random() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Crypto | Node.js documentation The OpenJS Foundation and Node.js contributors
[3] Standards Mapping - Common Weakness Enumeration CWE ID 338
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[12] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.structural.javascript.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


fun GenerateReceiptURL(baseUrl: String): String {
val ranGen = Random(Date().getTime())
return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}


Esse código usa a função Random.nextInt() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Random.nextInt() é um PRNG estatístico, é fácil para um invasor adivinhar as cadeias de caracteres que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.kotlin.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


function genReceiptURL($baseURL) {
$randNum = rand();
$receiptURL = $baseURL . $randNum . ".html";
return $receiptURL;
}


Esse código usa a função rand() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como rand() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 338
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.php.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
RETURN VARCHAR2
AS
rnum VARCHAR2(48);
time TIMESTAMP;
url VARCHAR2(MAX_URL)
BEGIN
time := SYSTIMESTAMP;
DBMS_RANDOM.SEED(time);
rnum := DBMS_RANDOM.STRING('x', 48);
url := 'http://test.com/' || rnum || '.html';
RETURN url;
END


Esse código usa a função DBMS_RANDOM.SEED() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como DBMS_RANDOM.SEED() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis.
References
[1] Oracle Database Security Guide
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 338
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[12] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.sql.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


def genReceiptURL(self,baseURL):
randNum = random.random()
receiptURL = baseURL + randNum + ".html"
return receiptURL


Esse código usa a função rand() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como rand() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 338
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.python.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


def generateReceiptURL(baseUrl) {
randNum = rand(400000000)
return ("#{baseUrl}#{randNum}.html");
}


Esse código usa a função Kernel.rand() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Kernel.rand() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 338
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[3] Standards Mapping - FIPS200 MP
[4] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[9] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[10] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[12] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[13] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.structural.ruby.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


def GenerateReceiptURL(baseUrl : String) : String {
val ranGen = new scala.util.Random()
ranGen.setSeed((new Date()).getTime())
return (baseUrl + ranGen.nextInt(400000000) + ".html")
}


Esse código usa a função Random.nextInt() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Random.nextInt() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 338
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.scala.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar um valor aleatório que é usado como um token de senha redefinido.


sqlite3_randomness(10, &reset_token)
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 338
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.swift.insecure_randomness
Abstract
Geradores de números pseudoaleatórios padrão não conseguem resistir a ataques criptográficos.
Explanation
Erros de aleatoriedade insegura ocorrem quando uma função que pode produzir valores previsíveis é usada como fonte de aleatoriedade em um contexto sensível à segurança.

Computadores são máquinas determinísticas e, como tais, são incapazes de produzir uma aleatoriedade verdadeira. PRNGs (Geradores de Números Pseudoaleatórios) aproximam a aleatoriedade algoritmicamente, começando com um propagador a partir do qual valores subsequentes são calculados.

Existem dois tipos de PRNGs: estatísticos e criptográficos. PRNGs estatísticos fornecem propriedades estatísticas úteis, mas sua saída é altamente previsível e forma um fluxo numérico fácil de reproduzir que é inadequado para uso em casos nos quais a segurança depende da imprevisibilidade dos valores gerados. PRNGs criptográficos resolvem esse problema, gerando uma saída que é mais difícil de prever. Para que um valor seja criptograficamente seguro, deve ser impossível ou altamente improvável que um invasor consiga distinguir entre o valor aleatório gerado e um valor realmente aleatório. Em geral, quando um algoritmo PRNG não é anunciado como criptograficamente seguro, é provável que ele seja um PRNG estatístico e, portanto, não deve ser usado em contextos sensíveis à segurança, nos quais sua utilização pode resultar em sérias vulnerabilidades, como senhas temporárias fáceis de adivinhar, chaves criptográficas previsíveis, sequestro de sessão e falsificação de DNS.

Exemplo 1: O código a seguir usa um PRNG estatístico para criar uma URL para um recibo que permanece ativo por um determinado período após uma compra.


...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...


Esse código usa a função Rnd() para gerar identificadores "exclusivos" para as páginas de recibo que ele gera. Como Rnd() é um PRNG estatístico, é fácil para um invasor adivinhar as strings que ele gera. Embora o design subjacente do sistema de recibos também tenha suas falhas, ele seria mais seguro se utilizasse um gerador de números aleatórios que não produzisse identificadores de recibo previsíveis, como um PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] CryptoAPI: CryptGenRandom() Microsoft
[3] Standards Mapping - Common Weakness Enumeration CWE ID 338
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 21.24
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[12] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.vb.insecure_randomness
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante.
Explanation
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como a classe CL_ABAP_RANDOM ou suas variantes) for propagado com um valor constante específico, os valores retornados por GET_NEXT, INT e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas PRNG.

Exemplo 1: No trecho a seguir, os valores produzidos pelo objeto random_gen2 são previsíveis por meio do objeto random_gen1.


DATA: random_gen1 TYPE REF TO cl_abap_random,
random_gen2 TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i.

random_gen1 = cl_abap_random=>create( seed = '1234' ).

DO 10 TIMES.
CALL METHOD random_gen1->int
RECEIVING
value = var1.

WRITE:/ var1.
ENDDO.

random_gen2 = cl_abap_random=>create( seed = '1234' ).

DO 10 TIMES.
CALL METHOD random_gen2->int
RECEIVING
value = var2.

WRITE:/ var2.
ENDDO.


Neste exemplo, os geradores de números pseudoaleatórios: random_gen1 e random_gen2 foram semeados de forma idêntica, então var1 = var2
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 336
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[4] Standards Mapping - FIPS200 MP
[5] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[9] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[10] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[12] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[13] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.structural.abap.insecure_randomness_hardcoded_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante.
Explanation
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como rand()) for propagado com um valor específico (usando uma função como srand(unsigned int)), os valores retornados por rand() e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas de PRNG.

Exemplo 1: Os valores produzidos pelo gerador de números pseudoaleatórios são previsíveis nos dois primeiros blocos, pois ambos começam com o mesmo propagador.


srand(2223333);
float randomNum = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum);
randomNum = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum);

srand(2223333);
float randomNum2 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum2);
randomNum2 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum2);

srand(1231234);
float randomNum3 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum3);
randomNum3 = (rand() % 100);
syslog(LOG_INFO, "Random: %1.2f", randomNum3);


Nesse exemplo, os resultados para randomNum1 e randomNum2 foram identicamente propagados e, portanto, cada chamada para rand() após a chamada que propaga o gerador de números pseudoaleatórios srand(2223333) resultará nas mesmas saídas, na mesma ordem de chamada. Por exemplo, a saída pode ser semelhante à seguinte:


Random: 32.00
Random: 73.00
Random: 32.00
Random: 73.00
Random: 15.00
Random: 75.00


Esses resultados estão longe de serem aleatórios.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.cpp.insecure_randomness_hardcoded_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante.
Explanation
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (PRNG) for propagado com um valor específico (usando uma função como math.Rand.New(Source)), os valores retornados por math.Rand.Int() e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas do PRNG.

Exemplo 1: Os valores produzidos pelo gerador de números pseudoaleatórios são previsíveis nos dois primeiros blocos, pois ambos começam com o mesmo propagador.


randomGen := rand.New(rand.NewSource(12345))
randomInt1 := randomGen.nextInt()

randomGen.Seed(12345)
randomInt2 := randomGen.nextInt()


Neste exemplo, os PRNGs foram propagados com o mesmo valor. Assim, cada chamada denextInt() após a chamada que iniciou a propagação do gerador de números pseudoaleatórios (randomGen.Seed(12345)) resultará nas mesmas saídas, na mesma ordem.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] MSC02-J. Generate strong random numbers CERT
[3] MSC03-J. Never hard code sensitive information CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 336
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[11] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[12] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.golang.insecure_randomness_hardcoded_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante.
Explanation
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como Random) for propagado com um valor específico (usando uma função como Random.setSeed()), os valores retornados por Random.nextInt()e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas de PRNG.

Exemplo 1: Os valores produzidos pelo objeto RandomrandomGen2 são previsíveis com base no objeto RandomrandomGen1.


Random randomGen1 = new Random();
randomGen1.setSeed(12345);
int randomInt1 = randomGen1.nextInt();
byte[] bytes1 = new byte[4];
randomGen1.nextBytes(bytes1);

Random randomGen2 = new Random();
randomGen2.setSeed(12345);
int randomInt2 = randomGen2.nextInt();
byte[] bytes2 = new byte[4];
randomGen2.nextBytes(bytes2);


Neste exemplo, os geradores de números pseudoaleatórios: randomGen1 e randomGen2 foram propagados de forma idêntica e, portanto, randomInt1 == randomInt2 e os valores correspondentes dos arrays bytes1[] e bytes2[] são iguais.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] MSC03-J. Never hard code sensitive information CERT
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.java.insecure_randomness_hardcoded_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante.
Explanation
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como Random) for propagado com um valor específico (usando uma função como Random(Int)), os valores retornados por Random.nextInt() e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas de PRNG.

Exemplo 1: Os valores produzidos pelo objeto RandomrandomGen2 são previsíveis com base no objeto RandomrandomGen1.


val randomGen1 = Random(12345)
val randomInt1 = randomGen1.nextInt()
val byteArray1 = ByteArray(4)
randomGen1.nextBytes(byteArray1)

val randomGen2 = Random(12345)
val randomInt2 = randomGen2.nextInt()
val byteArray2 = ByteArray(4)
randomGen2.nextBytes(byteArray2)


Neste exemplo, os geradores de números pseudoaleatórios: randomGen1 e randomGen2 foram propagados de forma idêntica e, portanto, randomInt1 == randomInt2 e os valores correspondentes dos arrays byteArray1 e byteArray2 são iguais.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] MSC03-J. Never hard code sensitive information CERT
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.kotlin.insecure_randomness_hardcoded_seed
Abstract
As funções que geram valores aleatórios ou pseudoaleatórios, que são passados a uma semente, não devem ser chamadas com um argumento inteiro constante.
Explanation
As funções que geram valores pseudoaleatórios, que são passados a uma semente, não devem ser chamadas com um argumento inteiro constante. Se um gerador de números pseudoaleatórios for semeado com um valor específico, os valores devolvidos serão previsíveis.

Exemplo 1: Os valores produzidos pelo gerador de números pseudoaleatórios são previsíveis nos dois primeiros blocos, pois ambos começam com o mesmo propagador.


...
import random
random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)

random.seed(123456)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
print "Random: %d" % random.randint(1,100)
...


Nesse exemplo, os PRNGs foram semeados de maneira idêntica, para que cada chamada de randint() feita depois da chamada que semeou o gerador de números pseudoaleatórios (random.seed(123456)), resulte nas mesmas saídas na mesma ordem. Por exemplo, a saída pode ser semelhante à seguinte:


Random: 81
Random: 80
Random: 3
Random: 81
Random: 80
Random: 3


Esses resultados estão longe de serem aleatórios.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.python.insecure_randomness_hardcoded_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante.
Explanation
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento constante. Se um gerador de números pseudoaleatórios (como Random) for propagado com um valor específico (usando uma função como Random.setSeed()), os valores retornados por Random.nextInt() e métodos semelhantes que retornam ou atribuem valores serão previsíveis para um invasor, que poderá coletar várias saídas de PRNG.

Exemplo 1: Os valores produzidos pelo objeto RandomrandomGen2 são previsíveis com base no objeto RandomrandomGen1.


val randomGen1 = new Random()
randomGen1.setSeed(12345)
val randomInt1 = randomGen1.nextInt()
val bytes1 = new byte[4]
randomGen1.nextBytes(bytes1)

val randomGen2 = new Random()
randomGen2.setSeed(12345)
val randomInt2 = randomGen2.nextInt()
val bytes2 = new byte[4]
randomGen2.nextBytes(bytes2)


Neste exemplo, os geradores de números pseudoaleatórios: randomGen1 e randomGen2 foram propagados de forma idêntica e, portanto, randomInt1 == randomInt2 e os valores correspondentes dos arrays bytes1[] e bytes2[] são iguais.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] MSC03-J. Never hard code sensitive information CERT
[5] Standards Mapping - Common Weakness Enumeration CWE ID 336
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.scala.insecure_randomness_hardcoded_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento corrompido.
Explanation
A classe CL_ABAP_RANDOM (ou suas variantes) não deve ser inicializada com um argumento corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores produzidos por chamadas para métodos, incluindo, sem limitações: GET_NEXT, INT, FLOAT, PACKED.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 335
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.abap.insecure_randomness_user_controlled_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento corrompido.
Explanation
Funções que geram valores aleatórios ou pseudoaleatórios (como rand()), que são transmitidos para um propagador (como srand()), não devem ser chamadas com um argumento corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores (geralmente números inteiros) produzidos por chamadas para esse gerador.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 335
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.cpp.insecure_randomness_user_controlled_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios após receber um propagador não devem ser chamadas com um argumento impróprio.
Explanation
Funções que geram valores pseudoaleatórios, como ed25519.NewKeyFromSeed(), não devem ser chamadas com um argumento impróprio. Caso contrário, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e prever a sequência de valores produzidos por esse gerador.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] MSC02-J. Generate strong random numbers CERT
[6] Standards Mapping - Common Weakness Enumeration CWE ID 335
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 MP
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.golang.insecure_randomness_user_controlled_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento de número inteiro corrompido.
Explanation
Random.setSeed() não devem ser chamadas com um argumento de número inteiro corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores (geralmente números inteiros) produzidos por chamadas para Random.nextInt(), Random.nextShort(), Random.nextLong(), retornadas por Random.nextBoolean() ou definidas em Random.nextBytes(byte[]).
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[4] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[5] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[6] MSC02-J. Generate strong random numbers CERT
[7] Standards Mapping - Common Weakness Enumeration CWE ID 335
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.java.insecure_randomness_user_controlled_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento de número inteiro corrompido.
Explanation
Random.setSeed() não devem ser chamadas com um argumento de número inteiro corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores (geralmente números inteiros) produzidos por chamadas para Random.nextInt(), Random.nextLong(), Random.nextDouble(), retornadas por Random.nextBoolean() ou definidas em Random.nextBytes(ByteArray).
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[4] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[5] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[6] MSC02-J. Generate strong random numbers CERT
[7] Standards Mapping - Common Weakness Enumeration CWE ID 335
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.kotlin.insecure_randomness_user_controlled_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento corrompido.
Explanation
Funções que geram valores de pseudoaleatórios (tais como random.randint()); não deve ser chamado com um argumento contaminado. Isso permite a um invasor controlar o valor usado para semear o gerador de números pseudoaleatórios, e, portanto, ser capaz de prever a sequência de valores (geralmente inteiros) produzida pelas chamadas do gerador de números pseudoaleatórios.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - Common Weakness Enumeration CWE ID 335
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[7] Standards Mapping - FIPS200 MP
[8] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[12] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[13] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.python.insecure_randomness_user_controlled_seed
Abstract
Funções que geram valores aleatórios ou pseudoaleatórios, que são transmitidos para um propagador, não devem ser chamadas com um argumento de número inteiro corrompido.
Explanation
Random.setSeed() não devem ser chamadas com um argumento de número inteiro corrompido. Se isso for feito, um invasor poderá controlar o valor usado para propagar o gerador de números pseudoaleatórios e, portanto, prever a sequência de valores (geralmente números inteiros) produzidos por chamadas para Random.nextInt(), Random.nextShort(), Random.nextLong(), retornadas por Random.nextBoolean() ou definidas em Random.nextBytes(byte[]).
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[4] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[5] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[6] MSC02-J. Generate strong random numbers CERT
[7] Standards Mapping - Common Weakness Enumeration CWE ID 335
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 6.3.3 Random Values (L3)
[14] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[15] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.dataflow.scala.insecure_randomness_user_controlled_seed