flawopen.com/Deserialización de Java/Seguridad de ObjectInputStream

¿Es seguro ObjectInputStream para datos no confiables?

Referencia de seguridad Java

En lenguaje sencillo

Por lo general, no: readObject() reconstruye objetos Java y puede ejecutar métodos de deserialización de las clases. Es como aceptar un formulario cuyos anexos también ejecutan sus propias instrucciones. Un flujo malicioso puede alcanzar clases disponibles en la aplicación. La ejecución depende de las clases, bibliotecas, rutas y frontera de entrada; no ocurre en cada llamada.

RIESGOSO: deserialización nativa

// No pases aquí bytes controlados por un atacante.
try (var in = new ObjectInputStream(untrustedStream)) {
    Object value = in.readObject();
    handle(value);
}

MÁS SEGURO: analizar un tipo fijo

// Desactiva el tipado polimórfico amplio para entradas no confiables.
ObjectMapper mapper = new ObjectMapper();
OrderRequest value = mapper.readValue(
    untrustedBytes, OrderRequest.class
);
validate(value);

Cómo puede alcanzarse el fallo

Una API, cola, caché o importador recibe bytes controlados por usuarios. Si llegan a ObjectInputStream.readObject(), la JVM restaura objetos de clases serializables presentes en el proceso. Una cadena de gadgets es una ruta posible por el comportamiento de esas clases, no un payload integrado en cada flujo. Oracle documentó CVE-2015-4852 como caso concreto: ataques sin autenticación mediante WebLogic T3 contra versiones indicadas. Esto no implica que cualquier uso de ObjectInputStream sea remoto.

Si no puedes eliminar la serialización nativa

✓Prefiere JSON o Protocol Buffers con esquema explícito; conviértelos a un DTO fijo y valida campos y permisos.
✓Si es inevitable, configura un ObjectInputFilter específico antes de readObject(); permite solo las clases exactas necesarias y rechaza las demás.
✓Limita profundidad, referencias, matrices y bytes según entradas válidas medidas. Una lista permitida no evita agotar recursos.
✓No habilites tipado polimórfico amplio para JSON no confiable: los metadatos arbitrarios de subtipos pueden volver a construir objetos.
✓Actualiza Java y sus dependencias, elimina bibliotecas innecesarias y procesa flujos heredados con privilegios y recursos limitados.

Pregunta frecuente

¿ObjectInputFilter hace seguro readObject()?

Reduce el riesgo si se configura antes de leer con una lista estrecha y límites, pero no es un saneador universal. Importan las clases permitidas, su comportamiento y que el filtro esté activo; la validación y autorización siguen siendo necesarias. Evita serialización nativa de datos controlados por usuarios.

Fuentes primarias

Véase también Deserialización insegura: riesgos y defensa Newtonsoft.Json TypeNameHandling: ¿configuración segura? PHP unserialize() y datos no confiables Seguridad de pickle.load() en Python: riesgos de datos no confiables ¿Es seguro Ruby YAML.load? Versiones de Psych y safe_load .NET BinaryFormatter: riesgos y migración