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 Cryptographic Signature: User-Controlled Key Size
Abstract
Funções de assinatura criptográfica 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, possibilitando assim a modificação de uma assinatura criptográfica que garante a integridade dos dados criptografados. Mesmo que um valor diferente de zero seja necessário, o invasor ainda pode especificar o menor valor de tamanho de chave possível, diminuindo a integridade dos dados criptografados.
Problemas de Hash Criptográfico Fraco: 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 usados como todo o parâmetro de tamanho de chave, ou como parte desse parâmetro, em uma função de assinatura criptográfica
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Hash criptográfico fraco: 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.
As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deva ser usado com os algoritmos RSA e DSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis. Se a entrada do usuário for usada até mesmo como um tamanho de chave parcial, ela poderá enfraquecer significativamente a segurança da assinatura e, portanto, a integridade dos dados criptografados.
Exemplo 1: O código a seguir gera uma chave de assinatura DSA usando um parâmetro de tamanho de chave controlado pelo usuário:
Existem alguns casos de uso nos quais os usuários devem ser capazes de determinar
Problemas de Hash Criptográfico Fraco: 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 usados como todo o parâmetro de tamanho de chave, ou como parte desse parâmetro, em uma função de assinatura criptográfica
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Hash criptográfico fraco: 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.
As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deva ser usado com os algoritmos RSA e DSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis. Se a entrada do usuário for usada até mesmo como um tamanho de chave parcial, ela poderá enfraquecer significativamente a segurança da assinatura e, portanto, a integridade dos dados criptografados.
Exemplo 1: O código a seguir gera uma chave de assinatura DSA usando um parâmetro de tamanho de chave controlado pelo usuário:
...
DSA dsa1 = new DSACryptoServiceProvider(Convert.ToInt32(TextBox1.Text));
...
Existem alguns casos de uso nos quais os usuários devem ser capazes de determinar
key_len
e, até mesmo nessas situações, é necessário que haja uma proteção apropriada para verificar que se trata de um valor numérico e também que esse valor está dentro de um intervalo de valores apropriado para um tamanho de chave. Para a maioria dos casos de uso, esse valor deve ser um número inserido em código fixo suficientemente alto.References
[1] J. Cheng 307-digit key crack endangers 1024-bit RSA
[2] Elaine Barker and Allen Roginsky NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST
[3] B. Chess and J. West, Secure Programming with Static Analysis. Boston, MA: Addison-Wesley, 2007.
[4] Standards Mapping - Common Weakness Enumeration CWE ID 326
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001188, 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 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-23 Session Authenticity (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-23 Session Authenticity
[10] 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), 6.2.7 Algorithms (L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 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 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
desc.dataflow.dotnet.weak_cryptographic_signature_user_controlled_key_size
Abstract
Funções de assinatura criptográfica que usam uma chave de tamanho 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 possibilita a modificação de uma assinatura criptográfica que garante a integridade dos dados criptografados. Mesmo que um valor diferente de zero seja necessário, o invasor ainda pode especificar o menor valor de tamanho de chave possível, diminuindo a integridade dos dados criptografados.
Os problemas de Assinatura criptográfica 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. Os dados controlados pelo usuário são usados como todo ou parte do parâmetro de tamanho da chave em uma função de assinatura criptográfica.
Assim como acontece com muitas vulnerabilidades de segurança de software, a assinatura criptográfica 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 executar a criptografia.
As diretrizes de criptografia atuais sugerem usar um comprimento de chave de pelo menos 2048 bits com os algoritmos RSA e DSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis. Se a entrada do usuário for usada até mesmo como um tamanho de chave parcial, ela poderá enfraquecer a segurança da assinatura e, portanto, a integridade dos dados criptografados.
Exemplo 1: O código a seguir gera uma chave de assinatura DSA com um parâmetro de tamanho de chave controlado pelo usuário:
Raramente os usuários exigem a capacidade de especificar o
Os problemas de Assinatura criptográfica 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. Os dados controlados pelo usuário são usados como todo ou parte do parâmetro de tamanho da chave em uma função de assinatura criptográfica.
Assim como acontece com muitas vulnerabilidades de segurança de software, a assinatura criptográfica 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 executar a criptografia.
As diretrizes de criptografia atuais sugerem usar um comprimento de chave de pelo menos 2048 bits com os algoritmos RSA e DSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis. Se a entrada do usuário for usada até mesmo como um tamanho de chave parcial, ela poderá enfraquecer a segurança da assinatura e, portanto, a integridade dos dados criptografados.
Exemplo 1: O código a seguir gera uma chave de assinatura DSA com um parâmetro de tamanho de chave controlado pelo usuário:
...
dsa.GenerateParameters(params, rand.Reader, key_len)
privatekey := new(dsa.PrivateKey)
privatekey.PublicKey.Parameters = *params
dsa.GenerateKey(privatekey, rand.Reader)
...
Raramente os usuários exigem a capacidade de especificar o
key_len
. Nestes casos, você deverá confirmar que seja um valor numérico e que esteja em um intervalo adequado para o tamanho da chave. Para a maioria dos casos de uso, selecione um tamanho de chave suficientemente grande para inserir no código.References
[1] J. Cheng 307-digit key crack endangers 1024-bit RSA
[2] Elaine Barker and Allen Roginsky NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST
[3] B. Chess and J. West, Secure Programming with Static Analysis. Boston, MA: Addison-Wesley, 2007.
[4] Standards Mapping - Common Weakness Enumeration CWE ID 326
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001188, 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 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-23 Session Authenticity (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-23 Session Authenticity
[10] 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), 6.2.7 Algorithms (L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 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 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
desc.dataflow.golang.weak_cryptographic_signature_user_controlled_key_size
Abstract
Funções de assinatura criptográfica 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, possibilitando assim a modificação de uma assinatura criptográfica que garante a integridade dos dados criptografados. Mesmo que um valor diferente de zero seja necessário, o invasor ainda pode especificar o menor valor de tamanho de chave possível, diminuindo a integridade dos dados criptografados.
Problemas de Hash Criptográfico Fraco: 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 usados como todo o parâmetro de tamanho de chave, ou como parte desse parâmetro, em uma função de assinatura criptográfica
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Hash criptográfico fraco: 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.
As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deva ser usado com os algoritmos RSA e DSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis. Se a entrada do usuário for usada até mesmo como um tamanho de chave parcial, ela poderá enfraquecer significativamente a segurança da assinatura e, portanto, a integridade dos dados criptografados.
Exemplo 1: O código a seguir gera uma chave de assinatura DSA usando um parâmetro de tamanho de chave controlado pelo usuário:
Existem alguns casos de uso nos quais os usuários devem ser capazes de determinar
Problemas de Hash Criptográfico Fraco: 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 usados como todo o parâmetro de tamanho de chave, ou como parte desse parâmetro, em uma função de assinatura criptográfica
Tal como acontece com muitas vulnerabilidades de segurança de software, a vulnerabilidades de Hash criptográfico fraco: 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.
As diretrizes de criptografia atuais sugerem que um comprimento de chave de pelo menos 2048 bits deva ser usado com os algoritmos RSA e DSA. No entanto, os avanços contínuos na capacidade computacional e em técnicas de fatoração [1] significam que aumentos futuros no tamanho de chave recomendado são inevitáveis. Se a entrada do usuário for usada até mesmo como um tamanho de chave parcial, ela poderá enfraquecer significativamente a segurança da assinatura e, portanto, a integridade dos dados criptografados.
Exemplo 1: O código a seguir gera uma chave de assinatura DSA usando um parâmetro de tamanho de chave controlado pelo usuário:
require 'openssl'
...
key_len = io.read.to_i
key = OpenSSL::PKey::DSA.new(key_len)
...
Existem alguns casos de uso nos quais os usuários devem ser capazes de determinar
key_len
e, até mesmo nessas situações, é necessário que haja uma proteção apropriada para verificar que se trata de um valor numérico e também que esse valor está dentro de um intervalo de valores apropriado para um tamanho de chave. Para a maioria dos casos de uso, esse valor deve ser um número inserido em código fixo suficientemente alto.References
[1] J. Cheng 307-digit key crack endangers 1024-bit RSA
[2] Elaine Barker and Allen Roginsky NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST
[3] B. Chess and J. West, Secure Programming with Static Analysis. Boston, MA: Addison-Wesley, 2007.
[4] Standards Mapping - Common Weakness Enumeration CWE ID 326
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001188, 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 AU-10 Non-Repudiation (P2), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-23 Session Authenticity (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-23 Session Authenticity
[10] 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), 6.2.7 Algorithms (L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 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 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.6.1, Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
desc.dataflow.ruby.weak_cryptographic_signature_user_controlled_key_size