Deserialización insegura (Insecure deserialisation)
En seguridad de aplicaciones, la deserialización insegura es un fallo por el que una aplicación reconstruye objetos a partir de datos que controla un atacante, y esa reconstrucción en sí ejecuta código. El atacante no entrega una carga que la aplicación vaya a interpretar más tarde: el acto de leer la entrada es ya la explotación.
Cómo funciona
Serializar convierte un objeto que está en memoria en bytes; deserializar convierte esos bytes de vuelta en un objeto. Los formatos nativos de varios ecosistemas guardan el tipo del objeto además de su contenido, así que el lector instancia el tipo que nombren los bytes e invoca métodos de ciclo de vida sobre él durante la reconstrucción.
Esa es la puerta. Un atacante no necesita un método vulnerable en el código propio de la aplicación. Ensambla una gadget chain con clases que ya están en el classpath, casi siempre de librerías, donde la reconstrucción de un objeto llama a la de otro, y el último eslabón hace algo útil como ejecutar un comando o abrir una conexión de red. Existen herramientas públicas que generan estas cadenas para combinaciones habituales de librerías, y por eso esto deja de ser un fallo exótico y pasa a ser uno repetible.
Qué sale mal
El error recurrente es intentar arreglarlo con una firma. Firmar un bloque serializado impide que un tercero lo falsifique, y no hace absolutamente nada si el atacante es un usuario legítimo autenticado que puede obtener un bloque firmado y cambiar lo que la aplicación hace con él, o si la clave de firma está dentro del mismo artefacto que se entregó al cliente.
El segundo es una lista de tipos permitidos implementada como lista de clases gadget prohibidas. Aparecen cadenas nuevas según cambian las dependencias, así que una lista de tipos prohibidos está desactualizada la próxima vez que alguien suba una versión, y esta es una de las pocas clases de fallo donde el análisis estático señala el punto de llegada con fiabilidad. La respuesta fiable es usar un formato de solo datos, atarlo a un tipo esperado, y no deserializar nunca un grafo de objetos nativo que haya cruzado una frontera de confianza. En una prueba, la pista es una cookie, un campo oculto, una entrada de caché o el contenido de una cola de mensajes que lleve una cabecera serializada reconocible, y es una vía frecuente en parques donde hay una librería vulnerable y nadie ha pasado software composition analysis.
Dónde aparece esto en una auditoría
Señalamos todos los sitios donde un objeto serializado cruza una frontera, confirmamos la explotabilidad por un canal aparte en vez de disparar algo destructivo, y anotamos el parámetro y la codificación exactos. El hallazgo nombra el framework, el formato, el punto de entrada y la evidencia, y se escribe como una vía de ejecución remota de código cuando una cadena funciona, porque es lo que es. Comprobamos además ese mismo formato de objeto en las colas internas, donde suele ir sin autenticar. Esto forma parte de cómo probamos los datos serializados que cruzan una frontera de confianza.