OWASP Top Ten 2017 (es)

A3:2017-Exposición de datos sensibles

Languages: en de [es]
Agente de amenaza / Vector de ataque Debilidades de seguridad Impacto
Específico
de la Apl.
Explotabilidad: 2 Prevalencia: 3 Detectabilidad: 2 Técnico: 3 ¿Negocio?
En lugar de atacar la criptografía, los atacantes roban claves, ejecutan ataques de Hombre en el Medio (Man in the Middle) o roban datos en texto plano del servidor, en tránsito, o desde el cliente. Se requiere un ataque manual pero pueden utilizase bases de datos con hashes que han sido hechas públicas para obtener las contraseñas originales utilizando GPUs.
En los últimos años, este ha sido el ataque de mayor impacto. El error más común es simplemente no cifrar los datos sensibles. Cuando se emplea criptografía, es común la generación y gestión de claves, algoritmos, cifradores y protocolos débiles. En particular algoritmos de resumen débiles para el almacenamiento de contraseñas. Para los datos en tránsito las debilidades son fáciles de detectar, mientras que para los datos almacenados es muy difícil. Ambos tienen una explotabilidad muy variable
Los fallos con frecuencia comprometen datos que deberían estar protegidos. Típicamente, esta información incluye Información Personal Sensible (PII) como registros de salud, datos personales, credenciales y tarjetas de crédito, que a menudo requieren mayor protección, según lo definido por las leyes o reglamentos como el PIBR de la UE o las leyes locales de privacidad.
¿La aplicación es vulnerable?
Lo primero es determinar las necesidades de protección de los datos en tránsito y en almacenamiento. Por ejemplo, contraseñas, números de tarjetas de crédito, registros médicos, información personal y datos sensibles del negocio requieren protección adicional, especialmente si se encuentran en el ámbito de aplicación de leyes de privacidad, como por ejemplo el Reglamento General de Protección de Datos (RGPD) o regulaciones financieras, como PCI Data Security Standard (PCI DSS). Para todos estos datos:
* ¿Se transmite datos en texto claro? Esto se refiere a protocolos como HTTP, SMTP, TELNET, FTP. El tráfico en Internet es especialmente peligroso. Verifique también todo el tráfico interno, por ejemplo, entre los balanceadores de carga, servidores web o sistemas de backend.
* ¿Se utilizan algoritmos criptográficos obsoletos o débiles, ya sea por defecto o en código heredado? Por ejemplo MD5, SHA1, etc.
* ¿Se utilizan claves criptográficas predeterminadas, se generan o reutilizan claves criptográficas débiles, o falta una gestión o rotación adecuada de las claves?
* Por defecto, ¿se aplica cifrado? ¿se han establecido las directivas de seguridad o encabezados para el navegador web?
* ¿El User-Agent del usuario (aplicación o cliente de correo), verifica que el certificado enviado por el servidor sea válido?
Véase también criptografía en el almacenamiento (V7), protección de datos (V9) y seguridad de la comunicaciones (V10) del ASVS.
Cómo se previene
Como mínimo, siga las siguientes recomendaciones y consulte las referencias:
* Clasifique los datos procesados, almacenados o transmitidos por el sistema. Identifique qué información es sensible de acuerdo a las regulaciones, leyes o requisitos del negocio y del país.
* Aplique los controles adecuados para cada clasificación.
* No almacene datos sensibles innecesariamente. Descártelos tan pronto como sea posible o utilice un sistema de tokenizacion que cumpla con PCI DSS. Los datos que no se almacenan no pueden ser robados.
* Cifre todos los datos sensibles cuando sean almacenados.
* Cifre todos los datos en tránsito utilizando protocolos seguros como TLS con cifradores que utilicen Perfect Forward Secrecy (PFS), priorizando los algoritmos en el servidor. Aplique el cifrado utilizando directivas como HTTP Strict Transport Security (HSTS).
* Utilice únicamente algoritmos y protocolos estándares y fuertes e implemente una gestión adecuada de claves. No cree sus propios algoritmos de cifrado.
* Deshabilite el almacenamiento en cache de datos sensibles.
* Almacene contraseñas utilizando funciones de hashing adaptables con un factor de trabajo (retraso) además de SALT, como Argon2, scrypt, bcrypt o PBKDF2.
• Verifique la efectividad de sus configuraciones y parámetros de forma independiente.
Ejemplos de escenarios de ataque
Escenario #1: una aplicación cifra números de tarjetas de crédito en una base de datos utilizando su cifrado automático. Sin embargo, estos datos son automáticamente descifrados al ser consultados, permitiendo que, si existe un error de inyección SQL se obtengan los números de tarjetas de crédito en texto plano.
Escenario #2: un sitio web no utiliza o fuerza el uso de TLS para todas las páginas, o utiliza cifradores débiles. Un atacante monitorea el tráfico de la red (por ejemplo en una red Wi-Fi insegura), degrada la conexión de HTTPS a HTTP e intercepta los datos, robando las cookies de sesión del usuario. El atacante reutiliza estas cookies y secuestra la sesión del usuario (ya autenticado), accediendo o modificando datos privados. También podría alterar los datos enviados.
Escenario #3: se utilizan hashes simples o hashes sin SALT para almacenar las contraseñas de los usuarios en una base de datos. Una falla en la carga de archivos permite a un atacante obtener las contraseñas. Utilizando una Rainbow Table de valores precalculados, se pueden recuperar las contraseñas originales.
Referencias