Reino: Security Features
La seguridad de un software no es un software de seguridad. Nos preocupamos de cuestiones como la autenticación, el control de acceso, la confidencialidad, la criptografía y la gestión de privilegios.
Weak Encryption: User-Controlled Key Size
Abstract
A las funciones de cifrado que toman un parámetro de tamaño de clave no se les debe pasar un valor de tamaño de clave contaminado.
Explanation
Permitir un valor controlado por el usuario para determinar el tamaño de clave puede hacer que un usuario malintencionado pueda especificar una clave vacía y pueda descifrar con relativa facilidad cualquier dato que se haya cifrado con la clave vacía. Incluso si se requiere un valor distinto de cero, un usuario malintencionado podría especificar el valor más bajo posible, reduciendo así la seguridad del cifrado.
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado transfiere datos malintencionados a una aplicación y, a continuación, los datos se usan como valor de tamaño de clave, o como parte de dicho valor, al realizar el cifrado.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: el siguiente código realiza el cifrado RSA con un parámetro de tamaño de clave controlado por el usuario:
El código en el
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado transfiere datos malintencionados a una aplicación y, a continuación, los datos se usan como valor de tamaño de clave, o como parte de dicho valor, al realizar el cifrado.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: el siguiente código realiza el cifrado RSA con un parámetro de tamaño de clave controlado por el usuario:
...
RSACryptoServiceProvider rsa1 = new RSACryptoServiceProvider(Convert.ToInt32(tx.Text));
...
El código en el
Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta funcionalidad podrá manipular el parámetro de tamaño de clave en el algoritmo de cifrado modificando el valor del cuadro de texto tx.Text. Una vez lanzado el programa, puede resultar muy difícil deshacer un problema relacionado con tamaños de clave controlados por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado el tamaño de clave de una operación de cifrado concreta.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 Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] 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
Las funciones de cifrado que toman un tamaño de clave pueden recibir un valor de tamaño de clave contaminado.
Explanation
Al permitir un valor controlado por el usuario para determinar el tamaño de clave, un atacante puede especificar una clave vacía, lo que permite descifrar con relativa facilidad cualquier dato que se haya cifrado con la clave vacía. Incluso si se requiere un valor distinto de cero, un atacante podría especificar el valor más bajo posible, reduciendo así la seguridad del cifrado.
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando ocurre lo siguiente:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave en una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación, que a continuación se utilizan como valor, total o parcial, de tamaño de clave para el cifrado.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante puede utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado empleada en la aplicación. Esto podría facilitar descifrar los datos cifrados de otros usuarios, ya que el atacante podría centrarse únicamente en algoritmos concretos.
2. El atacante puede manipular los tamaños de clave de cifrado de otros usuarios o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (u otro número bajo), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usó).
Ejemplo 1: El código siguiente genera una clave RSA con una longitud de clave derivada controlada por el usuario:
El código del
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando ocurre lo siguiente:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave en una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación, que a continuación se utilizan como valor, total o parcial, de tamaño de clave para el cifrado.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante puede utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado empleada en la aplicación. Esto podría facilitar descifrar los datos cifrados de otros usuarios, ya que el atacante podría centrarse únicamente en algoritmos concretos.
2. El atacante puede manipular los tamaños de clave de cifrado de otros usuarios o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (u otro número bajo), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usó).
Ejemplo 1: El código siguiente genera una clave RSA con una longitud de clave derivada controlada por el usuario:
...
rsa.GenerateKey(random, user_input)
...
El código del
Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta funcionalidad podrá manipular el parámetro de tamaño de clave para el algoritmo de cifrado, dado que el usuario puede controlar la variable user_input. Tras un lanzamiento de software, puede resultar complicado deshacer un problema relacionado con los tamaños de clave controlados por el usuario. Es extremadamente difícil saber si un usuario malintencionado controló el tamaño de clave de una operación de cifrado determinada.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 Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] 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
A las funciones de cifrado que toman un parámetro de tamaño de clave no se les debe pasar un valor de tamaño de clave contaminado.
Explanation
Permitir un valor controlado por el usuario para determinar el tamaño de clave puede hacer que un usuario malintencionado pueda especificar una clave vacía y pueda descifrar con relativa facilidad cualquier dato que se haya cifrado con la clave vacía. Incluso si se requiere un valor distinto de cero, un usuario malintencionado podría especificar el valor más bajo posible, reduciendo así la seguridad del cifrado.
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como valor de tamaño de clave durante el cifrado, total o parcialmente.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: el código siguiente realiza el cifrado AES con un parámetro de tamaño de clave controlado por el usuario:
El código
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como valor de tamaño de clave durante el cifrado, total o parcialmente.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: el código siguiente realiza el cifrado AES con un parámetro de tamaño de clave controlado por el usuario:
...
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");
...
El código
Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular el parámetro de tamaño de clave en el algoritmo de cifrado modificando la propiedad keySize. Una vez lanzado el programa, puede resultar muy difícil deshacer un problema relacionado con tamaños de clave controlados por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado el tamaño de clave de una operación de cifrado concreta.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 Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] 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
A las funciones de cifrado que toman un parámetro de tamaño de clave no se les debe pasar un valor de tamaño de clave contaminado.
Explanation
Permitir un valor controlado por el usuario para determinar el tamaño de clave puede hacer que un usuario malintencionado pueda especificar una clave vacía y pueda descifrar con relativa facilidad cualquier dato que se haya cifrado con la clave vacía. Incluso si se requiere un valor distinto de cero, un usuario malintencionado podría especificar el valor más bajo posible, reduciendo así la seguridad del cifrado.
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como valor de tamaño de clave durante el cifrado, total o parcialmente.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: el código siguiente realiza el cifrado AES con un parámetro de tamaño de clave controlado por el usuario:
El código en
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como valor de tamaño de clave durante el cifrado, total o parcialmente.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: el código siguiente realiza el cifrado AES con un parámetro de tamaño de clave controlado por el usuario:
...
@property (strong, nonatomic) IBOutlet UITextField *inputTextField;
...
CCCrypt(kCCEncrypt,
kCCAlgorithmAES,
kCCOptionPKCS7Padding,
key,
sizeof(_inputTextField.text),
iv,
plaintext,
sizeof(plaintext),
ciphertext,
sizeof(ciphertext),
&numBytesEncrypted);
...
El código en
Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular el parámetro de tamaño de clave en el algoritmo de cifrado modificando el texto en el UITextField inputTextField. Una vez lanzado el programa, puede resultar muy difícil deshacer un problema relacionado con tamaños de clave controlados por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado el tamaño de clave de una operación de cifrado concreta.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 Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] 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
A las funciones de cifrado que toman un parámetro de tamaño de clave no se les debe pasar un valor de tamaño de clave contaminado.
Explanation
Permitir un valor controlado por el usuario para determinar el tamaño de clave puede hacer que un usuario malintencionado pueda especificar una clave vacía y pueda descifrar con relativa facilidad cualquier dato que se haya cifrado con la clave vacía. Incluso si se requiere un valor distinto de cero, un usuario malintencionado podría especificar el valor más bajo posible, reduciendo así la seguridad del cifrado.
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado transfiere datos malintencionados a una aplicación y, a continuación, los datos se usan como valor de tamaño de clave, o como parte de dicho valor, al realizar el cifrado.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: El siguiente código deriva una clave de una contraseña, pero utiliza una longitud de clave derivada controlada por el usuario:
El código del
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado transfiere datos malintencionados a una aplicación y, a continuación, los datos se usan como valor de tamaño de clave, o como parte de dicho valor, al realizar el cifrado.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: El siguiente código deriva una clave de una contraseña, pero utiliza una longitud de clave derivada controlada por el usuario:
...
$hash = hash_pbkdf2('sha256', $password, $random_salt, 100000, strlen($password));
...
El código del
Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular el parámetro de tamaño de clave para el algoritmo de cifrado dado que la variable user_input puede ser controlada por el usuario. Una vez lanzado el programa, puede resultar muy difícil deshacer un problema relacionado con tamaños de clave controlados por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado el tamaño de clave de una operación de cifrado concreta.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 Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] 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
A las funciones de cifrado que toman un parámetro de tamaño de clave no se les debe pasar un valor de tamaño de clave contaminado.
Explanation
Permitir un valor controlado por el usuario para determinar el tamaño de clave puede hacer que un usuario malintencionado pueda especificar una clave vacía y pueda descifrar con relativa facilidad cualquier dato que se haya cifrado con la clave vacía. Incluso si se requiere un valor distinto de cero, un usuario malintencionado podría especificar el valor más bajo posible, reduciendo así la seguridad del cifrado.
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como valor de tamaño de clave durante el cifrado, total o parcialmente.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: El siguiente código deriva una clave de una contraseña, pero utiliza una longitud de clave derivada controlada por el usuario:
El código del
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como valor de tamaño de clave durante el cifrado, total o parcialmente.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: El siguiente código deriva una clave de una contraseña, pero utiliza una longitud de clave derivada controlada por el usuario:
...
dk = hashlib.pbkdf2_hmac('sha256', password, random_salt, 100000, dklen=user_input)
...
El código del
Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular el parámetro de tamaño de clave para el algoritmo de cifrado dado que la variable user_input puede ser controlada por el usuario. Una vez lanzado el programa, puede resultar muy difícil deshacer un problema relacionado con tamaños de clave controlados por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado el tamaño de clave de una operación de cifrado concreta.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 Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] 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
A las funciones de cifrado que toman un parámetro de tamaño de clave no se les debe pasar un valor de tamaño de clave contaminado.
Explanation
Permitir un valor controlado por el usuario para determinar el tamaño de clave puede hacer que un usuario malintencionado pueda especificar una clave vacía y pueda descifrar con relativa facilidad cualquier dato que se haya cifrado con la clave vacía. Incluso si se requiere un valor distinto de cero, un usuario malintencionado podría especificar el valor más bajo posible, reduciendo así la seguridad del cifrado.
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como valor de tamaño de clave durante el cifrado, total o parcialmente.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: El siguiente código deriva una clave de una contraseña, pero utiliza una longitud de clave derivada controlada por el usuario:
El código del
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como valor de tamaño de clave durante el cifrado, total o parcialmente.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: El siguiente código deriva una clave de una contraseña, pero utiliza una longitud de clave derivada controlada por el usuario:
...
dk = OpenSSL::PKCS5.pbkdf2_hmac(password, random_salt, 100000, user_input, digest)
...
El código del
Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular el parámetro de tamaño de clave para el algoritmo de cifrado dado que la variable user_input puede ser controlada por el usuario. Una vez lanzado el programa, puede resultar muy difícil deshacer un problema relacionado con tamaños de clave controlados por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado el tamaño de clave de una operación de cifrado concreta.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 Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] 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
A las funciones de cifrado que toman un parámetro de tamaño de clave no se les debe pasar un valor de tamaño de clave contaminado.
Explanation
Permitir un valor controlado por el usuario para determinar el tamaño de clave puede hacer que un usuario malintencionado pueda especificar una clave vacía y pueda descifrar con relativa facilidad cualquier dato que se haya cifrado con la clave vacía. Incluso si se requiere un valor distinto de cero, un usuario malintencionado podría especificar el valor más bajo posible, reduciendo así la seguridad del cifrado.
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado transfiere datos malintencionados a una aplicación y, a continuación, los datos se usan como valor de tamaño de clave, o como parte de dicho valor, al realizar el cifrado.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: El siguiente código realiza el cifrado AES con un parámetro de tamaño de clave controlado por el usuario:
El código en
Los problemas de Cifrado débil: tamaño de clave controlado por el usuario se producen cuando:
1. Los datos entran en un programa a través de un origen que no es de confianza.
2. Los datos controlados por el usuario se incluyen en el parámetro de tamaño de clave o se utilizan completamente como el parámetro de tamaño de clave de una función de cifrado.
Al igual que muchas vulnerabilidades de seguridad de software, Cifrado débil: tamaño de clave controlado por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado transfiere datos malintencionados a una aplicación y, a continuación, los datos se usan como valor de tamaño de clave, o como parte de dicho valor, al realizar el cifrado.
El problema de tener un tamaño de clave controlado por el usuario es que puede posibilitar diversos ataques:
1. El atacante podría utilizar esta vulnerabilidad para especificar un tamaño de clave de cero para las operaciones de cifrado en las que se utilicen datos a los que tenga acceso. A continuación, sería muy sencillo intentar descifrar sus propios datos utilizando distintos algoritmos y claves vacías para filtrar información sobre la implementación del cifrado que se emplea en la aplicación. De esta forma, sería muy sencillo descifrar los datos cifrados de otros usuarios, ya que el usuario malintencionado podría centrarse únicamente en algoritmos concretos.
2. El atacante podría manipular los tamaños de clave de cifrado de otros usuarios, o engañar a otros usuarios para que utilicen una clave de cifrado de tamaño cero (o el más bajo posible), con el fin de poder leer los datos cifrados de otros usuarios (después de que haya determinado el algoritmo de cifrado que se usa).
Ejemplo 1: El siguiente código realiza el cifrado AES con un parámetro de tamaño de clave controlado por el usuario:
...
@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)
...
El código en
Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular el parámetro de tamaño de clave en el algoritmo de cifrado modificando el texto en el UITextField inputTextField. Una vez lanzado el programa, puede resultar muy difícil deshacer un problema relacionado con tamaños de clave controlados por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado el tamaño de clave de una operación de cifrado concreta.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 Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] 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