Reino: Security Features
Segurança de software não é o mesmo que software de segurança. Aqui, estamos interessados em tópicos como autenticação, controle de acesso, confidencialidade, criptografia e gestão de privilégios.
Weak Encryption: User-Controlled Key Size
Abstract
Funções de criptografia que usam um parâmetro de tamanho de chave não devem ser transmitidas com um valor de tamanho de chave comprometido.
Explanation
Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir realiza uma criptografia RSA com um parâmetro de tamanho de chave controlado pelo usuário:
O código no
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir realiza uma criptografia RSA com um parâmetro de tamanho de chave controlado pelo usuário:
...
RSACryptoServiceProvider rsa1 = new RSACryptoServiceProvider(Convert.ToInt32(tx.Text));
...
O código no
Example 1 será executado com êxito, mas qualquer pessoa que possa chegar a essa funcionalidade conseguirá manipular o parâmetro de tamanho de chave do algoritmo de criptografia modificando a o valor da caixa de texto tx.Text. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 326
[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 - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.dataflow.dotnet.weak_encryption_user_controlled_key_size
Abstract
Funções de criptografia que usam tamanho de chave podem receber um valor de tamanho de chave comprometido.
Explanation
Ao permitir que um valor controlado pelo usuário determine o tamanho da chave, um invasor pode especificar uma chave vazia, o que permite com relativa facilidade a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave para realizar a criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Seria simples tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias para vazar informações da implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou outro número menor), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (depois que ele tiver conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir gera uma chave RSA com um tamanho de chave controlado pelo usuário:
O código no
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave para realizar a criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Seria simples tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias para vazar informações da implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou outro número menor), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (depois que ele tiver conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir gera uma chave RSA com um tamanho de chave controlado pelo usuário:
...
rsa.GenerateKey(random, user_input)
...
O código no
Example 1 será executado com êxito, mas qualquer um que possa chegar a essa funcionalidade será capaz de manipular o parâmetro chave de tamanho para o algoritmo de criptografia, uma vez que a variável user_input pode ser controlada pelo usuário. Após a liberação do software, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário. É extremamente difícil saber se um usuário mal-intencionado controlava o tamanho da chave de uma determinada operação de criptografia.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 326
[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 - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.dataflow.golang.weak_encryption_user_controlled_key_size
Abstract
Funções de criptografia que usam um parâmetro de tamanho de chave não devem ser transmitidas com um valor de tamanho de chave comprometido.
Explanation
Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir realiza uma criptografia AES com um parâmetro de tamanho de chave controlado pelo usuário:
O código no
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir realiza uma criptografia AES com um parâmetro de tamanho de chave controlado pelo usuário:
...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String keySize = prop.getProperty("keySize");
...
PBEKeySpec spec = new PBEKeySpec(
password.toCharArray(),
saltBytes,
pswdIterations,
Integer.parseInt(keySize)
);
SecretKey secretKey = factory.generateSecret(spec);
SecretKeySpec secret = new SecretKeySpec(secretKey.getEncoded(), "AES");
...
O código no
Example 1 será executado com êxito, qualquer pessoa que puder acessar essa funcionalidade conseguirá manipular o parâmetro de tamanho de chave do algoritmo de criptografia modificando a propriedade keySize. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 326
[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 - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.dataflow.java.weak_encryption_user_controlled_key_size
Abstract
Funções de criptografia que usam um parâmetro de tamanho de chave não devem ser transmitidas com um valor de tamanho de chave comprometido.
Explanation
Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir realiza uma criptografia AES com um parâmetro de tamanho de chave controlado pelo usuário:
O código no
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir realiza uma criptografia AES com um parâmetro de tamanho de chave controlado pelo usuário:
...
@property (strong, nonatomic) IBOutlet UITextField *inputTextField;
...
CCCrypt(kCCEncrypt,
kCCAlgorithmAES,
kCCOptionPKCS7Padding,
key,
sizeof(_inputTextField.text),
iv,
plaintext,
sizeof(plaintext),
ciphertext,
sizeof(ciphertext),
&numBytesEncrypted);
...
O código no
Example 1 será executado com êxito, qualquer pessoa que puder acessar essa funcionalidade conseguirá manipular o parâmetro de tamanho de chave para o algoritmo de criptografia modificando o texto no UITextField inputTextField. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 326
[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 - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.dataflow.objc.weak_encryption_user_controlled_key_size
Abstract
Funções de criptografia que usam um parâmetro de tamanho de chave não devem ser transmitidas com um valor de tamanho de chave comprometido.
Explanation
Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1:Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:
O código no
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1:Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:
...
$hash = hash_pbkdf2('sha256', $password, $random_salt, 100000, strlen($password));
...
O código no
Example 1 será executado com êxito, mas qualquer um que possa chegar a essa funcionalidade será capaz de manipular o parâmetro chave de tamanho para o algoritmo de criptografia, uma vez que a variável user_input pode ser controlada pelo usuário. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 326
[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 - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.dataflow.php.weak_encryption_user_controlled_key_size
Abstract
Funções de criptografia que usam um parâmetro de tamanho de chave não devem ser transmitidas com um valor de tamanho de chave comprometido.
Explanation
Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:
O código no
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:
...
dk = hashlib.pbkdf2_hmac('sha256', password, random_salt, 100000, dklen=user_input)
...
O código no
Example 1 será executado com êxito, mas qualquer um que possa chegar a essa funcionalidade será capaz de manipular o parâmetro chave de tamanho para o algoritmo de criptografia, uma vez que a variável user_input pode ser controlada pelo usuário. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 326
[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 - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.dataflow.python.weak_encryption_user_controlled_key_size
Abstract
Funções de criptografia que usam um parâmetro de tamanho de chave não devem ser transmitidas com um valor de tamanho de chave comprometido.
Explanation
Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:
O código no
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: Este código deriva uma chave de uma senha, mas usa um tamanho de chave derivada controlado pelo usuário:
...
dk = OpenSSL::PKCS5.pbkdf2_hmac(password, random_salt, 100000, user_input, digest)
...
O código no
Example 1 será executado com êxito, mas qualquer um que possa chegar a essa funcionalidade será capaz de manipular o parâmetro chave de tamanho para o algoritmo de criptografia, uma vez que a variável user_input pode ser controlada pelo usuário. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 326
[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 - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.dataflow.ruby.weak_encryption_user_controlled_key_size
Abstract
Funções de criptografia que usam um parâmetro de tamanho de chave não devem ser transmitidas com um valor de tamanho de chave comprometido.
Explanation
Permitir que um valor controlado pelo usuário determine o tamanho da chave pode fazer com que o invasor seja capaz de especificar uma chave vazia, facilitando assim a descriptografia de quaisquer dados que tenham sido criptografados com essa chave vazia. Mesmo que um valor diferente de zero seja necessário, um invasor ainda pode especificar o menor valor possível, diminuindo a segurança da criptografia.
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir realiza uma criptografia AES com um parâmetro de tamanho de chave controlado pelo usuário:
O código no
Problemas de Criptografia Fraca: Tamanho de Chave Controlado pelo Usuário ocorrem quando:
1. Dados entram em um programa através de uma fonte não confiável
2. Dados controlados pelo usuário são incluídos no parâmetro de tamanho de chave, ou usados inteiramente como o parâmetro de tamanho de chave dentro de uma função de criptografia.
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Criptografia fraca: Um tamanho de chave controlado pelo usuário é um meio para um fim, e não um fim em si mesmo. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados para um aplicativo, e esses dados são então usados como todo ou parte do valor de tamanho da chave durante a realização da criptografia.
O problema em se ter um tamanho de chave controlado pelo usuário é que ele pode permitir vários ataques:
1. O invasor pode usar essa vulnerabilidade para especificar um tamanho de chave igual a zero para as operações de criptografia que envolvem dados que ele pode acessar. Desse ponto em diante, seria simples para ele tentar descriptografar seus próprios dados usando vários algoritmos diferentes junto com chaves vazias a fim de deixar vazar informações sobre a implementação da criptografia utilizada no aplicativo. Isto pode facilitar a descriptografia dos dados criptografados de outros usuários, permitindo que o invasor se concentre apenas em algoritmos específicos durante seus esforços de cracking.
2. O invasor pode manipular tamanhos de chaves de criptografia de outros usuários ou enganar esses usuários a ponto de levá-los a usar um tamanho de chave de criptografia igual a zero (ou o mais baixo possível), potencialmente permitindo que o invasor leia os dados criptografados de outros usuários (já que ele tem conhecimento do algoritmo de criptografia utilizado).
Exemplo 1: O código a seguir realiza uma criptografia AES com um parâmetro de tamanho de chave controlado pelo usuário:
...
@IBOutlet weak var inputTextField : UITextField!
...
let key = (inputTextField.text as NSString).dataUsingEncoding(NSUTF8StringEncoding)
let keyPointer = UnsafePointer<UInt8>(key.bytes)
let keyLength = size_t(key.length)
...
let operation : CCOperation = UInt32(kCCEncrypt)
let algoritm : CCAlgorithm = UInt32(kCCAlgorithmAES128)
let options : CCOptions = UInt32(kCCOptionPKCS7Padding)
var numBytesEncrypted :size_t = 0
CCCrypt(operation,
algorithm,
options,
keyPointer,
keyLength,
iv,
plaintextPointer,
plaintextLength,
ciphertextPointer,
ciphertextLength,
&numBytesEncrypted)
...
O código no
Example 1 será executado com êxito, qualquer pessoa que puder acessar essa funcionalidade conseguirá manipular o parâmetro de tamanho de chave para o algoritmo de criptografia modificando o texto no UITextField inputTextField. Após a distribuição do programa, pode ser difícil desfazer um problema com tamanhos de chave controlados pelo usuário, pois seria extremamente difícil saber se um usuário mal-intencionado determinou o tamanho da chave de uma determinada operação de criptografia.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 326
[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 - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.dataflow.swift.weak_encryption_user_controlled_key_size