Buenas prácticas de desarrollo seguro: A3 Exposición de datos sensibles

En nuestro post semanal de prácticas de desarrollo seguro, del OWASP Top 10, hablaremos del tercer punto: Exposición de datos sensibles, los que muchas aplicaciones web y APIs no protegen adecuadamente. Los atacantes buscan información bancaria, de salud, datos de identificación personal y contraseñas y ¡es tu deber como desarrollador proteger esos datos! En la época […]

En nuestro post semanal de prácticas de desarrollo seguro, del OWASP Top 10, hablaremos del tercer punto: Exposición de datos sensibles, los que muchas aplicaciones web y APIs no protegen adecuadamente. Los atacantes buscan información bancaria, de salud, datos de identificación personal y contraseñas y ¡es tu deber como desarrollador proteger esos datos!

En la época del Big Data, los datos toman cada vez más valor. El desarrollo seguro debe considerar la importancia de proteger estos datos, que al ser recabados, pasan a ser responsabilidad de quien los almacena. Una vez almacenados, estos datos requieren protección especial, y las leyes se han adaptado hacia la protección de los mismos. Los atacantes buscan acceder a los datos mediante diversos ataques. Cada vez se crean nuevos métodos para saltarse los mecanismos de control. Es por esto que uno de los peores errores que aún se suelen cometer es dejar estos datos sin cifrar. El cifrado de los datos debe ser mandatorio, tanto para cuando éstos estén en tránsito como para cuando estén almacenados.

Para comenzar, se debe determinar qué datos son los que más protección requerirán, y para esto hay una serie de directrices legales y de compliance que los han, ya, determinado.

Se debe comprender que un atacante intentará:

• desencriptar los datos almacenados a los cuales haya tenido acceso
• interceptar los datos que transiten entre el servidor y el navegador (o entre servidores)
• engañar a tu aplicación web para elevar privilegios, cambiar contenidos en los carritos de compra, etc

Entonces, caeremos en este tipo de vulnerabilidades tanto si los datos almacenados o transmitidos se encuentran en «texto plano» y si se transmiten bajo protocolos inseguros (HTTP, FTP, TELNET o SMTP), incluso de manera interna (entre servidores, balanceadores de carga o cualquier sistema backend). También se encuentran en riesgo los datos que se encuentren encriptados o hasheados con un algoritmo débil u obsoleto, como MD5, SHA1, etc. Es por esto que se debe ser especialmente cuidadosos, además, al gestionar la rotación de claves criptográficas, pues éstas no pueden ser reutilizadas ni debieran ser débiles.

Y para protegernos ante estas vulnerabilidades, siempre debemos:

• No almacenar datos sensibles que sean innecesarios. Aunque parezca básico, los datos que no están almacenados no pueden ser robados
• Clasificar los datos procesados, almacenados y transmitidos de acuerdo a su nivel de sensibilidad (que está indicado en todas las nuevas regulaciones y compliance)
• Aplicar los controles adecuados para cada nivel de la clasificación
• Todos los datos sensibles deben ser cifrados
• Los datos en tránsito deben ser cifrados usando protocolos seguros como TLS con cifradores que utilicen PFS (Perfect Forward Secrecy)
• Se deben utilizar sólo protocolos de cifrado fuertes, actualizados y estándares
• Los datos sensibles no deben quedar almacenados en el caché
• El almacenamiento de contraseñas debiera tener un trato especial: es recomendable utilizar funciones de hash adaptables además de saltearlas
• Es siempre recomendable realizar web application pentests, de manera que una entidad independiente evalúe la efectividad de las medidas puestas en práctica