Subiendo una posición al n.° 2, anteriormente conocido como Exposición de datos confidenciales , que es más un síntoma amplio que una causa raíz, el enfoque se centra en las fallas relacionadas con la criptografía (o la falta de esta). Lo que a menudo conduce a la exposición de datos confidenciales. Las enumeraciones de debilidades comunes (CWE) notables incluidas son CWE-259: Uso de contraseña codificada , CWE-327: Algoritmo criptográfico roto o riesgoso y CWE-331 Entropía insuficiente .
Descripción
Lo primero es determinar las necesidades de protección de los datos en tránsito y en reposo. Por ejemplo, las contraseñas, los números de tarjetas de crédito, los registros de salud, la información personal y los secretos comerciales requieren protección adicional, principalmente si esos datos están sujetos a las leyes de privacidad, por ejemplo, el Reglamento General de Protección de Datos (GDPR) de la UE, o regulaciones, por ejemplo, la protección de datos financieros. como el estándar de seguridad de datos PCI (PCI DSS). Para todos estos datos:
-
¿Se transmite algún dato en texto claro? Esto se refiere a protocolos como HTTP, SMTP, FTP que también usan actualizaciones de TLS como STARTTLS. El tráfico de Internet externo es peligroso. Verifique todo el tráfico interno, por ejemplo, entre balanceadores de carga, servidores web o sistemas back-end.
-
¿Se utilizan protocolos o algoritmos criptográficos antiguos o débiles de forma predeterminada o en código antiguo?
-
¿Están en uso las claves criptográficas predeterminadas, se generan o reutilizan claves criptográficas débiles, o falta una gestión o rotación de claves adecuada? ¿Se registran las claves criptográficas en los repositorios de código fuente?
-
¿No se aplica el cifrado, por ejemplo, faltan directivas de seguridad o encabezados de encabezados HTTP (navegador)?
-
¿El certificado del servidor recibido y la cadena de confianza están debidamente validados?
-
¿Se ignoran, reutilizan o no se generan los vectores de inicialización lo suficientemente seguros para el modo criptográfico de operación? ¿Se está utilizando un modo de operación inseguro como ECB? ¿Se usa el cifrado cuando el cifrado autenticado es más apropiado?
-
¿Se utilizan contraseñas como claves criptográficas en ausencia de una función de derivación de clave base de contraseña?
-
¿Se utiliza la aleatoriedad con fines criptográficos que no fueron diseñados para cumplir con los requisitos criptográficos? Incluso si se elige la función correcta, ¿debe ser sembrada por el desarrollador y, de no ser así, el desarrollador ha sobrescrito la funcionalidad de siembra fuerte integrada con una semilla que carece de suficiente entropía/imprevisibilidad?
-
¿Se utilizan funciones hash en desuso, como MD5 o SHA1, o se utilizan funciones hash no criptográficas cuando se necesitan funciones hash criptográficas?
-
¿Están en uso métodos de relleno criptográfico en desuso, como PKCS número 1 v1.5?
-
¿Son explotables los mensajes de error criptográficos o la información del canal lateral, por ejemplo, en forma de ataques de oráculo de relleno?
Consulte ASVS Crypto (V7), Protección de datos (V9) y SSL/TLS (V10)
Como prevenir
Haga lo siguiente, como mínimo, y consulte las referencias:
-
Clasificar los datos procesados, almacenados o transmitidos por una aplicación. Identifique qué datos son confidenciales de acuerdo con las leyes de privacidad, los requisitos reglamentarios o las necesidades comerciales.
-
No almacene datos confidenciales innecesariamente. Deséchelo lo antes posible o use tokenización compatible con PCI DSS o incluso truncamiento. Los datos que no se retienen no se pueden robar.
-
Asegúrese de cifrar todos los datos confidenciales en reposo.
-
Asegúrese de que se implementen algoritmos, protocolos y claves estándar sólidos y actualizados; utilizar una gestión de claves adecuada.
-
Cifre todos los datos en tránsito con protocolos seguros como TLS con cifrado de confidencialidad directa (FS), priorización de cifrado por parte del servidor y parámetros seguros. Aplique el cifrado mediante directivas como HTTP Strict Transport Security (HSTS).
-
Deshabilite el almacenamiento en caché para las respuestas que contienen datos confidenciales.
-
Aplicar los controles de seguridad requeridos según la clasificación de datos.
-
No utilice protocolos heredados como FTP y SMTP para transportar datos confidenciales.
-
Almacene contraseñas utilizando funciones de hashing saladas y adaptables sólidas con un factor de trabajo (factor de demora), como Argon2, scrypt, bcrypt o PBKDF2.
-
Los vectores de inicialización deben elegirse de forma adecuada para el modo de operación. Para muchos modos, esto significa usar un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Para los modos que requieren un nonce, el vector de inicialización (IV) no necesita un CSPRNG. En todos los casos, el IV nunca debe usarse dos veces para una clave fija.
-
Utilice siempre cifrado autenticado en lugar de solo cifrado.
-
Las claves deben generarse criptográficamente al azar y almacenarse en la memoria como matrices de bytes. Si se utiliza una contraseña, debe convertirse en una clave a través de una función de derivación de clave base de contraseña adecuada.
-
Asegúrese de que se utilice la aleatoriedad criptográfica cuando corresponda y de que no se haya sembrado de forma predecible o con baja entropía. La mayoría de las API modernas no requieren que el desarrollador genere CSPRNG para obtener seguridad.
-
Evite las funciones criptográficas obsoletas y los esquemas de relleno, como MD5, SHA1, PKCS número 1 v1.5.
-
Verifique de forma independiente la eficacia de la configuración y los ajustes.
Ejemplos de escenarios de ataque
Escenario n.º 1 : una aplicación cifra los números de tarjetas de crédito en una base de datos mediante el cifrado automático de la base de datos. Sin embargo, estos datos se descifran automáticamente cuando se recuperan, lo que permite que una falla de inyección SQL recupere números de tarjetas de crédito en texto claro.
Escenario n.º 2 : un sitio no usa ni impone TLS para todas las páginas o admite un cifrado débil. Un atacante supervisa el tráfico de la red (por ejemplo, en una red inalámbrica insegura), degrada las conexiones de HTTPS a HTTP, intercepta solicitudes y roba la cookie de sesión del usuario. Luego, el atacante reproduce esta cookie y secuestra la sesión del usuario (autenticado), accediendo o modificando los datos privados del usuario. En lugar de lo anterior, podrían alterar todos los datos transportados, por ejemplo, el destinatario de una transferencia de dinero.
Escenario n.º 3 : la base de datos de contraseñas utiliza hashes simples o sin sal para almacenar las contraseñas de todos. Una falla en la carga de archivos permite que un atacante recupere la base de datos de contraseñas. Todos los hashes sin sal se pueden exponer con una tabla de arcoíris de hashes precalculados. Los hashes generados por funciones hash simples o rápidas pueden ser descifrados por GPU, incluso si estuvieran salados.
Referencias
Lista de CWE mapeados