Capacitación en diseño de Beida Jade Bird: ¿Cómo prevenir ataques de 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. De manera similar, siempre que ocurra una vulnerabilidad, todo el software desarrollado con programación Java tendrá problemas. Las siguientes son buenas noticias sobre capacitación en Java. Aprendamos juntos 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: la aparición de nuevas estrategias de transmisión de objetos, como JSON, XML, Apache Avro, Protocol Buffers, 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 forma parte del módulo java.base.
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.
EishaySmith publicó indicadores 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 llegarán a usted a la misma velocidad.
¿Cómo podemos reducir el impacto de las fallas de serialización? El Proyecto Amber incluye una discusión sobre el aislamiento de 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 obtuvieron resultados sobre esta propuesta mientras se finalizaba el conjunto de funciones JDK11, pero las discusiones pueden continuar en futuras versiones de Java.
Reduzca la exposición a la serialización con 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 para el mantenimiento incluyen no hacer manualmente una larga lista de cosas, sino utilizar un sistema como OWASPDependency-Check, que identifica las dependencias de las vulnerabilidades de seguridad conocidas y solicita la actualización.
También puedes considerar 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 necesidad de ofuscar los permisos de las funciones y requerir conocimiento avanzado de cosas incognoscibles limita la adopción a gran escala de esta característica: los administradores del sistema no conocen el contenido del código y, por lo tanto, no pueden enumerar los archivos de clase, y los desarrolladores sí. No comprender el entorno. Incluso los equipos de DevOps a menudo no conocen las necesidades de otras partes del sistema, como los servidores de aplicaciones.