Oracle revela planes para mejorar la seguridad de Java
Oracle planea hacer cambios para reforzar la seguridad de Java, incluyendo la reparación de su característica para la comprobación de revocación de certificados para así evitar que aplicaciones sin firma se ejecuten de forma predeterminada; además agregarán opciones para la gestión centralizada de listas blancas para entornos empresariales.
Estos cambios, junto con otros esfuerzos relacionados con la seguridad, pretenden “reducir la posibilidad de explotación y severidad de las potenciales vulnerabilidades de Java en el entorno del escritorio y se desea ofrecer mecanismos de protección adicionales de seguridad para Java que funcionan en el entorno del servidor” argumentó Nandini Ramani, vicepresidenta de ingeniería para Clientes Java y Plataformas Móviles de Oracle.
En el post de Ramani (del blog de Oracle) se habla sobre “la solvencia de la seguridad en Java,” en el que se aborda, indirectamente, algunas de las críticas y preocupaciones planteadas en este año por los investigadores de seguridad tras una serie de ataques con éxito que explotaban vulnerabilidades de día cero (zero-day) en el plugin de Java de los navegadores web.
Ramani reiteró los planes de Oracle para acelerar el cronograma de aplicación de parches de Java a partir de octubre, de manera que lo alineó con el calendario de aplicación de parches de otros productos de la compañía. Además, reveló algunos de los esfuerzos de la compañía para llevar a cabo las revisiones de código de seguridad de Java.
Añadió que “el equipo de desarrollo de Java extendió el uso de herramientas de pruebas de seguridad automatizadas, lo que facilita la cobertura sobre una gran parte del código de la plataforma Java”. El equipo trabajó con el principal proveedor de Oracle en el análisis de código fuente para hacer que estas herramientas sean más eficaces en entornos Java y también se desarrollaron heramientas para realizar análisis “fuzzing” y eliminar ciertos tipos de vulnerabilidades.
La aparente ausencia de revisiones apropiadas del código fuente y de pruebas de aseguramiento de calidad para Java 7 fue una de las principales críticas hechas por los investigadores. Ramani también comentó sobre los nuevos niveles de seguridad y advertencias en los applets de Java y en las aplicaciones web basadas en Java que se introdujeron en Java 7 Update 10 y Java 7 Update 21 respectivamente.
Estos cambios estaban destinados a rechazar la ejecución de applets sin firma o autofirmados, debido a que en un futuro próximo, el comportamiento por defecto de Java no permitirá la ejecución de códigos autoafirmados o sin firma.
NOTA: Los interesados en información sobre contrato de soporte Asistencia Tecnica de SATINFO y/o licencia de uso/actualizaciones de sus utilidades, contacten con info@satinfo.es
__________
Este blog no se hace responsable de las opiniones y comentarios de los textos en los que se cita la Fuente, ofreciendo su contenido solo para facilitar el acceso a la información del mismo.
Puedes seguir cualquier respuesta a esta entrada mediante el canal RSS 2.0. Los comentarios y los pings están cerrados.
Los comentarios están cerrados.