Usted tiene razón en su evaluación de "Java 0-day" para el código del servidor. Estos ataques tienen que ver con la ruptura de código hostil del sandbox de applet , que es el modelo de seguridad utilizado por los applets: un applet es un código que podría ser malicioso y, por lo tanto, se ejecutará bajo fuertes restricciones (por ejemplo, sin acceso a archivos locales, sin carga de código nativo, sin conexiones de red, excepto al servidor que envió el applet El primer lugar, no hay introspección completa en otros paquetes ...). En un servidor, el código es, por definición, no hostil y no se ejecuta en un entorno limitado.
Java en un servidor todavía se ejecuta en la Java Virtual Machine , que no es lo mismo que el sandbox. En términos generales, la JVM impone reglas de tipo (sin acceso a campos o llamadas de método en objetos que no tienen el campo o método designado) y límites de matriz (no se escribe en bytes adyacentes después de desbordamientos de búfer), y ejecuta el recolector de basura; La zona de pruebas agrega muchos controles adicionales sobre qué métodos estándar pueden llamarse o no, con un elaborado sistema de permisos. El código del lado del servidor no está en un espacio aislado, pero la JVM seguirá conteniendo el daño en caso de que haya agujeros explotables:
-
En el caso de un desbordamiento del búfer, el subproceso ofensivo se termina (bueno, recibe una excepción que puede interceptar, pero en la práctica la terminación es el resultado final normal) y ningún objeto en la memoria ha sido realmente dañado. Los desbordamientos de búfer siguen siendo errores, pero, al menos, las consecuencias son limitadas.
-
El recolector de basura , por definición, evitará cualquier tipo de acceso después de libre.
-
El sistema de tipo estricto evitará el acceso a cualquier byte de datos con una interpretación distinta de la que se utilizó para almacenar ese byte en primer lugar.
-
Las variables locales no inicializadas no se pueden leer (el análisis de flujo cuando se carga el código lo impide). Los campos se ven obligados sistemáticamente a establecer valores predeterminados sanos (0, false , 0.0, null ).
Todo esto, sin embargo, se aplica igualmente a .NET, PHP y Perl y casi a todos, excepto a los lenguajes de programación de muy bajo nivel.
Intentar establecer niveles de vulnerabilidades inherentes es un negocio arriesgado. Las características de Java, que expliqué anteriormente, pueden convertirse en un argumento sobre cómo es Java ". inherentemente seguro ". Sin embargo, lo mismo se aplicaría a la mayoría de los otros marcos de programación, incluido PHP. En última instancia, la mayoría de las vulnerabilidades son errores de programación, no en el marco, sino errores cometidos por el desarrollador que utilizó el marco. Contar las vulnerabilidades publicadas le informará solo sobre los agujeros de seguridad en el marco bibliotecas , pero no sobre los agujeros en el código desarrollado para el marco, y ahí es donde estarán la mayoría de los agujeros.
Por lo tanto, las vulnerabilidades se relacionan con lo fácil que es usar el marco y con lo buenas (o malas) que las características del marco ayudan al programador a no hacer errores. Esto es relativo al desarrollador . Un desarrollador PHP capacitado que no sepa nada sobre Java no será bueno para crear un servidor seguro basado en Java: tendrá que aprender algo de Java y usarlo de inmediato, será un proceso doloroso y el desarrollador no tendrá Mucho tiempo para pruebas. Esto no implica en absoluto que PHP sea inherentemente más seguro que Java; la situación se revertiría con un desarrollador que conoce Java pero no PHP.
En el mejor de los casos, podemos señalar que los lenguajes de programación de "bajo nivel" como C, Forth, Assembly, C ++ ... son objetivamente más difíciles de usar que los de "alto nivel" (como C #, Java, PHP, Node.js ...). El punto donde esto es más evidente es el manejo de las cadenas de caracteres. Los servidores típicos hacen eso mucho. En C, el manejo de las cadenas de caracteres es muy manual, con todas las asignaciones y copias, y cuidando las longitudes del búfer. Los idiomas con gestión de memoria automática (por ejemplo, todos los que tienen un GC) hacen que estos trabajos sean mucho más fáciles, es decir, es mucho más difícil equivocarse .
Eso es sobre el final del ejercicio. Para plataformas basadas en lenguajes de alto nivel (ya sea LAMP, Spring, .NET ...), el "más seguro" será el que el desarrollador conozca mejor . Este "factor de conocimiento" triunfa sobre todos los demás.
(Podría convertir eso en: "el marco web más seguro será aquel para el que es más fácil encontrar un desarrollador competente".)