¿Cómo prevenir ataques a la red de serialización del lenguaje de programación Java?

La programación Java siempre ha sido el lenguaje de desarrollo principal en el mercado de desarrollo de software de Internet. Esto también lleva al hecho de que mientras ocurra una vulnerabilidad, todo el software desarrollado con programación Java tendrá problemas. entrenamiento java Echemos un vistazo a cómo resolver el problema de serialización en el lenguaje de programación Java.

¿Qué es la serialización?

La serialización ha existido en la plataforma Java desde el lanzamiento de JDK 1.1 en 1997.

Se utiliza para compartir representaciones de objetos entre sockets, o para guardar objetos y su estado para uso futuro (deserialización).

En JDK10 y versiones inferiores, la serialización existe en todos los sistemas como parte del paquete java.base y el método java.io.Serializable.

Desafíos y limitaciones de la serialización

Las limitaciones de la serialización se reflejan principalmente en los dos aspectos siguientes:

Han surgido nuevas estrategias de transmisión de objetos, como JSON, XML, ApacheAvro, ProtocolBuffers, etc.

La estrategia de serialización de 1997 no pudo prever la forma en que se construyen y atacan los servicios modernos de Internet.

La premisa básica para los ataques de vulnerabilidad de serialización es encontrar clases que realicen operaciones privilegiadas en datos deserializados y luego pasarles código malicioso.

¿Dónde está la serialización? ¿Cómo sé si mi aplicación usa serialización?

Para eliminar la serialización, debe comenzar con el paquete java.io, que es parte de java. módulo básico. Los escenarios de uso comunes son:

Implementar la interfaz serializable y (opcional) el campo de entero largo serialversionuid.

Utilice ObjectInputStream u ObjectOutputStream.

Utilice bibliotecas que dependan en gran medida de la serialización, como: Xstream, Kryo, BlazeDS y la mayoría de los servidores de aplicaciones.

Los desarrolladores que utilicen estos métodos deberían considerar el uso de otros métodos alternativos para almacenar y leer datos. EihaySmith ha publicado métricas de rendimiento para varias bibliotecas de serialización diferentes. Al evaluar el rendimiento, es necesario incluir consideraciones de seguridad en las métricas de referencia. La serialización predeterminada de Java es "más rápida", pero las vulnerabilidades aparecerán con la misma rapidez.

¿Cómo podemos reducir el impacto de las fallas de serialización?

El Proyecto Amber incluye una discusión sobre cómo aislar las API de serialización. La idea es mover la serialización de java.base a un módulo separado para que las aplicaciones puedan eliminarla por completo. No se han obtenido resultados sobre esta propuesta mientras se finaliza el conjunto de características de JDK11, pero las discusiones pueden continuar en futuras versiones de Java.

Reducir la exposición a la serialización mediante protección en tiempo de ejecución

Un sistema que pueda monitorear los riesgos y automatizar la experiencia en seguridad repetible puede resultar útil para muchas empresas. Las aplicaciones Java pueden integrar herramientas JVMTI en sistemas de monitoreo de seguridad e integrar sensores en aplicaciones a través de instrumentación.

Otras técnicas de seguridad útiles

Al realizar el mantenimiento, en lugar de enumerar manualmente una larga lista de cosas, utilice un sistema como OWASPDependency-Check, que puede identificar dependencias para vulnerabilidades de seguridad conocidas y solicitar para actualizar. Considere también las actualizaciones automáticas de las bibliotecas a través de un sistema como DependABot.

Aunque tiene buenas intenciones, el filtro de serialización predeterminado de Oracle sufre el mismo defecto de diseño que SecurityManager y las vulnerabilidades relacionadas del sandbox. La adopción masiva de esta característica está limitada por la confusión de los permisos de las funciones y la necesidad de conocimientos agnósticos de antemano: los administradores de sistemas no conocen el contenido del código y, por lo tanto, no pueden enumerar los archivos de clase, los desarrolladores no conocen el entorno e incluso los equipos de DevOps. Muchas veces tampoco conocemos los requisitos de otras partes del sistema, como por ejemplo el servidor de aplicaciones.