Seguridad de JVM para el servidor

Java está bien para los servidores. Los problemas de seguridad con Java son en realidad problemas con el modelo de applet de Java , en el que su JVM ( en su navegador) está destinado a ejecutar código potencialmente hostil (es decir, código "de la Web") y, de alguna manera, evitar que ese código hostil haga algo malo. El modelo de applet es un poco como ejecutar el código de applet en una máquina virtual, excepto que la capa de aislamiento se realiza con el propio lenguaje y con las salvaguardas en la biblioteca estándar. Resulta que tratar de hacer un sandbox de esa manera es muy difícil, porque tienes que incluir controles explícitos en cada clase y método de biblioteca potencialmente peligroso, y hay miles de estos. Todas las vulnerabilidades de Java que han llegado a las noticias en los últimos años son sobre eso: algunos códigos de bibliotecas estándar que no filtraban las llamadas con suficiente solidez, en caso de que la persona que llama sea un applet hostil.

Nada de esto se aplica a Java en un servidor. En un servidor, ese es su código, presumiblemente no hostil, y con acceso completo a la biblioteca estándar. Ejecutar el código Java en su servidor no es peor (por seguridad) que ejecutar el código C o C ++; en realidad es posiblemente mejor porque las protecciones inherentes del lenguaje de Java (gestión de memoria basada en el recolector de basura, tipos fuertes y verificaciones de límites de matriz) lo hacen más robusto con respecto a algunas categorías de errores como desbordamientos de búfer. Es decir, las consecuencias de un desbordamiento de búfer son más limitadas (el búfer no está realmente desbordado; en su lugar se lanza una excepción), y el GC permite un manejo mucho más sencillo de las cadenas de caracteres, algo que es una fuente fértil de desbordamientos de búfer cuando se escribe el código C .

El mismo razonamiento se aplica a .NET y sus diversos idiomas (C #, VB ...).

El Java Runtime Environment se puede ejecutar utilizando un Administrador de seguridad si desea restringir cierto acceso a cierta parte de la aplicación (dependiendo del código que se esté ejecutando y del estado de autenticación).

Esto se puede habilitar en Apache Tomcat o en JBoss por ejemplo.

El sistema de políticas y permisos es un tema complejo y está documentado aquí .

Es cierto que el sistema no es perfecto, ya que las vulnerabilidades a las que hace referencia sobre los applets ocurren cuando el applet "escapa" a su administrador de seguridad. Esto puede suceder si hay un error en el administrador de seguridad (obviamente un problema) o si la política es demasiado flexible.

A este respecto, un entorno de servidor se diferencia de un entorno de applet en que el entorno de applet se instala con una política de talla única: algo que apunta a ser lo suficientemente bueno como para restringir el mal comportamiento y habilitar la mayoría de las funciones, sin saberlo. qué código se va a ejecutar ni en qué entorno exacto. Un entorno de servidor es menos vulnerable a este respecto, ya que es posible que pueda personalizar su política para satisfacer sus necesidades específicas (por ejemplo, permitir conexiones a su servidor de base de datos específico pero no a otras conexiones salientes).

Los administradores de seguridad tienden a no estar habilitados de forma predeterminada en los contenedores de aplicaciones web, pero si lo necesita, puede configurar las políticas según sea necesario.

Sí, JVM y entornos similares reducen el riesgo de vulnerabilidades de corrupción de memoria, aunque se debe tener en cuenta que este tipo de problemas también pueden ocurrir a nivel de VM (por ejemplo, CVE-2013-2420)

La reciente ola de vulnerabilidades de Java se centra en los applets del lado del cliente, pero también se debe tener en cuenta que ha habido formas de explotar estos problemas en el lado del servidor (como en el protocolo RMI). Oracle no siempre lo señala en sus avisos:

enlace

Respecto a la seguridad de las diferentes implementaciones de JVM, el proyecto SE-2012-01 de Security Explorations parece ser un buen punto de partida:

enlace