Los codificadores conquistan la seguridad: serie Share & Learn: deserialización insegura

Dependiendo de la aplicación, el proceso de serialización puede ocurrir todo el tiempo. Es el término que se utiliza para describir cuando las estructuras de datos o los estados de los objetos se traducen a un formato que se puede almacenar o, posiblemente, enviar como comunicación. La deserialización es lo opuesto a este proceso: toma los datos ahora estructurados y los convierte de nuevo en el objeto o la cadena de datos que eran antes del almacenamiento.

La deserialización insegura puede ocurrir cuando una aplicación considera que los datos que se están deserializando son confiables. Si un usuario puede modificar los datos recién reconstruidos, puede realizar todo tipo de actividades malintencionadas, 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 reducir el precio de un objeto o aumentar sus privilegios.

En este episodio aprenderemos:

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

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

En la actualidad, el formato de datos más popular para serializar datos es JSON, aunque XML le sigue de cerca. Muchos lenguajes de programación también ofrecen sus propios métodos para serializar datos, que a menudo contienen 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 confiables, en lugar de seguir el viejo mantra de otros blogs de esta serie, específicamente: «¡Nunca confíes en las entradas de los usuarios!»

Nunca se debe confiar en las entradas del usuario porque el usuario puede insertar código en esas cadenas, lo que podría ejecutar accidentalmente el servidor receptor. Además, dado que a veces también se puede acceder a los datos deserializados sin procesar y explotarlos, es necesario que pertenezcan a la misma categoría de datos que no son de confianza.

Por ejemplo, si una aplicación de foro usa la serialización de objetos de PHP para guardar una cookie que contiene la identificación y el rol de un usuario, puede manipularse. En su lugar, un usuario malintencionado podría cambiar su rol de «usuario» por el de «administrador». O bien, pueden usar la apertura que proporciona la cadena de datos para inyectar código, que podría malinterpretarse y ejecutarlo el servidor mientras procesa los datos «confiables».

¿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, prueba y error mientras el atacante aprende qué tipos de código o exploits aceptará el servidor a partir de sus datos manipulados y deserializados. Dicho esto, se trata de una vulnerabilidad que se aprovecha con frecuencia debido a la potencia potencial que otorga a los piratas informáticos con la habilidad suficiente para utilizarla.

Dependiendo de cómo se supone que se usen los datos deserializados, se pueden emplear cualquier cantidad de ataques, incluidos muchos de los que hemos tratado en blogs anteriores. La deserialización insegura puede ser una puerta de entrada a la inyección remota de código cruzado, a la creación de scripts entre sitios, a la denegación de servicio, al secuestro del control de acceso y, por supuesto, a los ataques por inyección de SQL y XML. Básicamente, abre un punto de partida, declara que todos los datos que se están deserializando son confiables y permite a los atacantes intentar explotarlos.

Eliminar la deserialización insegura

Lo más seguro que pueden hacer las organizaciones para evitar la deserialización insegura es impedir que las aplicaciones acepten datos deserializados. Sin embargo, puede que eso no sea posible ni realista, pero no se preocupe, porque existen otras técnicas que pueden emplearse para defenderse de este tipo de ataque.

Si es posible, los datos se pueden desinfectar para convertirlos en valores numéricos. Es posible que esto no detenga por completo una vulnerabilidad, pero evitaría que se produjeran inyecciones de código. Aún mejor es simplemente exigir algún tipo de verificación de integridad comparándola con datos deserializados, como una firma digital, que podría garantizar que las cadenas de datos no hayan sido manipuladas. Además, todos los procesos de deserialización deben aislarse y ejecutarse en un entorno de pocos privilegios.

Una vez que haya establecido esas protecciones, asegúrese de registrar todos los intentos fallidos de deserialización, así como la actividad de red que proviene de los contenedores o servidores que deserializan los datos. Si un usuario provoca más de un par de errores de deserialización en los registros, es un buen indicio de que se trata de un intruso malintencionado o de que sus credenciales han sido hackeadas o robadas. Incluso podrías considerar la posibilidad de bloquear automáticamente a los usuarios, que provocan errores de deserialización de forma constante.

Independientemente de las herramientas que emplee para combatir la deserialización insegura, recuerde que, en esencia, se trata de datos que pueden haber sido tocados o manipulados por un usuario. Nunca te fíes de ello.

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

Para leer más, puede echar un vistazo a lo que dice OWASP acerca de la deserialización insegura. También puedes poner a prueba tus nuevos conocimientos defensivos con el escaparate gratuito de la plataforma Secure Code Warrior, que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad y la galería de otras amenazas de los delincuentes, visita la Blog de Secure Code Warrior.