Dependiendo de la aplicación, el proceso de serialización puede ocurrir todo el tiempo. Es el término utilizado para describir cada vez que las estructuras de datos o los estados de los objetos son traducidos a un formato que puede ser almacenado o posiblemente enviado como una comunicación. La deserialización es lo contrario de este proceso, tomando los datos ahora estructurados y convirtiéndolos de nuevo en el objeto o cadena de datos que era antes del almacenamiento.

La deserialización insegura puede ocurrir cuando una aplicación trata los datos que se están deserializando como de confianza. Si un usuario es capaz de 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 cambiar los datos para obtener alguna ventaja dentro de la aplicación, como bajar el precio de un objeto o elevar sus privilegios.

En este episodio aprenderemos:

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

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

Hoy en día, el formato de datos más popular para serializar datos es JSON, aunque XML le sigue de cerca. Bastantes lenguajes de programación también ofrecen sus propios métodos para serializar datos, que a menudo contienen más características que JSON o XML. En cualquier caso, pueden surgir problemas si los desarrolladores programan las aplicaciones para tratar los datos deserializados como una entrada de confianza, en lugar de seguir el viejo mantra de otros blogs de esta serie, concretamente "¡Nunca confíes en la entrada del usuario!"

La entrada del usuario nunca es de confianza porque el usuario puede insertar código en esas cadenas, que podría ser ejecutado accidentalmente por el servidor receptor. Y dado que los datos crudos deserializados también pueden ser accedidos y explotados en ocasiones, tienen que entrar en esa misma categoría de no confianza.

Por ejemplo, si una aplicación de foro utiliza la serialización de objetos PHP para guardar una cookie que contiene la identificación y el rol de un usuario, entonces eso puede ser manipulado. Un usuario malicioso podría cambiar su rol de "usuario" por el de "administrador". O puede utilizar la apertura proporcionada por la cadena de datos para inyectar código, que podría ser malinterpretado y ejecutado por el servidor mientras procesa los datos "de confianza".

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

Es cierto que este tipo de ataque requiere un mínimo de habilidad por parte de un hacker, y a veces ensayo y error mientras el atacante aprende qué tipo de código o exploits aceptará el servidor a partir de sus datos manipulados y deserializados. Dicho esto, se trata de una vulnerabilidad comúnmente explotada debido al poder potencial que otorga a los hackers lo suficientemente hábiles como para utilizarla.

Dependiendo de cómo se supone que se usen los datos deserializados, se puede emplear cualquier número de ataques, incluyendo muchos de los que hemos cubierto en blogs anteriores. La deserialización insegura puede ser una puerta de entrada a la inyección remota de código cruzado, scripting entre sitios, denegación de servicio, secuestro de control de acceso y, por supuesto, ataques de inyección SQL y XML. Básicamente abre un punto de lanzamiento, declara que todos los datos que se están deserializando son de confianza, y deja que los atacantes intenten explotarlo.

Eliminación de la deserialización insegura

Lo más seguro que pueden hacer las organizaciones para evitar la deserialización insegura es restringir las aplicaciones para que no acepten datos deserializados. Sin embargo, eso puede no ser posible o realista, pero no hay que preocuparse, porque hay otras técnicas que se pueden emplear para defenderse de este tipo de ataques.

Si es posible, los datos pueden ser saneados a algo como valores numéricos. Esto podría no detener totalmente un exploit, pero evitaría que se produzcan inyecciones de código. Aún mejor es simplemente requerir algún tipo de comprobación de integridad contra los datos deserializados, como una firma digital, que podría asegurar que las cadenas de datos no han sido manipuladas. Y todos los procesos de deserialización deben ser aislados y ejecutados en un entorno de bajo privilegio.

Una vez que tenga esas protecciones, asegúrese de registrar todos los intentos fallidos de deserialización, así como la actividad de la red que provenga de contenedores o servidores que deserialicen datos. Si un usuario desencadena más de un par de errores de deserialización en los registros, es un buen indicio de que se trata de una persona malintencionada o de que sus credenciales han sido pirateadas o robadas. Incluso se puede considerar la posibilidad de bloquear automáticamente a los usuarios que provocan constantemente errores de deserialización.

Cualquiera de estas herramientas que emplees para luchar contra la deserialización insegura, recuerda que en el fondo 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 más información, puedes echar un vistazo a lo que dice la OWASP sobre la deserialización insegura. También puedes poner a prueba tus nuevos conocimientos defensivos con la muestra gratuita de la plataforma Secure Code Warrior , que entrena a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .