Programadores que conquistan la seguridad: Serie de aprendizaje y colaboración - Deserialización insegura

Dependiendo de la aplicación, el proceso de serialización puede ocurrir constantemente. Es el término utilizado para describir cuando las estructuras de datos o los estados de los objetos se traducen a un formato que puede almacenarse o enviarse como comunicación. La deserialización es el proceso inverso: toma los datos estructurados y los convierte de nuevo en el objeto o cadena de datos original antes de su almacenamiento.

La deserialización insegura puede ocurrir siempre que una aplicación trate los datos que se están deserializando como información de confianza. Si un usuario puede modificar los datos recién reconstruidos, puede realizar todo tipo de actividades maliciosas, como inyecciones de código, ataques de denegación de servicio o simplemente alterar los datos para obtener alguna ventaja dentro de la aplicación, como reducir el precio de un artículo o elevar sus privilegios.

En este episodio aprenderemos:

• Cómo pueden los atacantes explotar la deserialización insegura
• Por qué la deserialización insegura es peligrosa
• Técnicas para solucionar esta vulnerabilidad.

¿Cómo explotan los atacantes la deserialización insegura?

Hoy en día, el formato de datos más popular para serializar información es JSON, aunque XML le sigue de cerca. Muchos lenguajes de programación también ofrecen sus propios métodos para serializar datos, los cuales suelen incluir más funciones que JSON o XML. En cualquier caso, pueden surgir problemas si los desarrolladores programan aplicaciones para tratar los datos deserializados como entradas de confianza, en lugar de seguir el mantra de otros blogs de esta serie: "¡Nunca confíes en la entrada del usuario!"

Nunca se debe confiar en la entrada del usuario, ya que este puede insertar código en esas cadenas que el servidor receptor podría ejecutar accidentalmente. Y dado que los datos deserializados sin procesar a veces también pueden ser accedidos y explotados, deben incluirse en esa misma categoría de falta de confianza.

Por ejemplo, si una aplicación de foro utiliza la serialización de objetos de PHP para guardar una cookie que contiene la identificación y el rol de un usuario, esta podría ser manipulada. Un usuario malintencionado podría cambiar su rol de "usuario" a "administrador". O bien, puede aprovechar la apertura que ofrece la cadena de datos para inyectar código, el cual podría ser malinterpretado y ejecutado por el servidor al procesar los datos "de confianza".

¿Por qué es peligrosa la deserialización insegura?

Es cierto que este tipo de ataque requiere cierto nivel de habilidad por parte del hacker, y a veces requiere de prueba y error mientras el atacante aprende qué tipos de código o exploits aceptará el servidor a partir de sus datos deserializados y manipulados. Dicho esto, es una vulnerabilidad comúnmente explotada debido al potencial que ofrece a los hackers con la habilidad suficiente para utilizarla.

Dependiendo de cómo se deban utilizar los datos deserializados, se pueden emplear diversos ataques, incluidos muchos de los que cubrimos en blogs anteriores. La deserialización insegura puede ser una puerta de entrada a la inyección remota de código, cross-site scripting, denegación de servicio, secuestro de control de acceso y, por supuesto, ataques de inyección SQL y XML. Básicamente, crea un punto de partida, declara que todos los datos que se están deserializando son de confianza y permite que los atacantes intenten explotarlos.

Eliminación de la deserialización insegura

Lo más seguro que pueden hacer las organizaciones para prevenir la deserialización insegura es restringir la aceptación de datos deserializados por parte de las aplicaciones. Sin embargo, esto puede no ser posible o realista, pero no te preocupes, ya que existen otras técnicas que se pueden emplear para defenderse contra este tipo de ataque.

Si es posible, los datos pueden sanearse convirtiéndolos en valores numéricos. Esto podría no detener completamente un exploit, pero evitaría que ocurrieran inyecciones de código. Aún mejor es simplemente requerir algún tipo de verificación de integridad en los datos deserializados, como una firma digital, que garantice que las cadenas de datos no han sido manipuladas. Además, todos los procesos de deserialización deben estar aislados y ejecutarse en un entorno de bajos privilegios.

Una vez que tengas esas protecciones implementadas, asegúrate de registrar todos los intentos fallidos de deserialización, así como la actividad de red proveniente de contenedores o servidores que deserializan datos. Si un usuario activa más de un par de errores de deserialización en los registros, es una buena señal de que se trata de un usuario interno malintencionado o de que sus credenciales han sido hackeadas o robadas. Incluso podrías considerar medidas como bloqueos automáticos para los usuarios que activen constantemente errores de deserialización.

Independientemente de las herramientas que emplees para combatir la deserialización insegura, recuerda que, en esencia, se trata de datos que podrían haber sido tocados o manipulados por un usuario. Nunca confíes en ellos.

Más información sobre el uso de componentes con vulnerabilidades conocidas

Para profundizar, puedes consultar lo que dice OWASP sobre la deserialización insegura. También puedes poner a prueba tus nuevos conocimientos defensivos con la demostración gratuita de la plataforma Secure Code Warrior, que entrena a equipos de ciberseguridad para convertirse en expertos. Para aprender más sobre cómo vencer esta vulnerabilidad y otras amenazas, visita el blog de Secure Code Warrior.