Si usa Java como la mayoría de los otros lenguajes de programación, por ejemplo. para escribir aplicaciones independientes, no es menos seguro que otros idiomas y más seguro que C o C ++ debido a que no hay desbordamientos de búfer, etc.

Pero Java se usa regularmente como un complemento dentro del navegador web, por ejemplo. similar a Flash. Debido a que en este caso el usuario ejecuta código no confiable sin haberlo instalado explícitamente, la idea es que el código se ejecute dentro de un recinto limitado, donde no debería poder actuar de alguna manera contra el sistema o el usuario (por ejemplo, leer los archivos locales y enviarlos). al sitio web, escanear la red local, etc.). Y aquí es donde Java falló en los últimos años, por ej. a veces diariamente aparecían nuevos errores que permitían escapar de la caja de arena.

También, a veces, los errores en el intérprete de códigos de bytes o las bibliotecas nativas llevan a desbordamientos de búfer y pueden comprometer el sistema, pero en este sentido, Flash generalmente se considera peor.

Y en cuanto a que los otros idiomas son mejores: por lo general, ni siquiera se pueden ejecutar como código no confiable dentro de un recinto de seguridad (la excepción es JavaScript y quizás Flash), por lo que serían aún peores porque no hay una forma inherente de limitar su interacción. con el sistema.

Las vulnerabilidades de seguridad informadas no se refieren a Java (el lenguaje de programación) que, en virtud de la JVM, hace cumplir seguridad de la memoria , en realidad es más robusto que lenguajes como C o C ++, donde los desbordamientos de búfer y las sobre-lecturas de búfer siguen siendo una amenaza, y pueden generar problemas como Heartbleed.

En su lugar, las vulnerabilidades reportadas se encuentran en el área de pruebas de Java, que intenta imponer un modelo de privilegio que permite la ejecución segura de código no confiable, y se usa más para permitir la ejecución automática de los applets de Java en un navegador. Esa caja de arena está llena de agujeros. Además, Oracle lanza parches (las "actualizaciones de parches críticos") solo 4 veces al año. No hace falta decir a los proveedores de navegadores que no están contentos con esto. Firefox, por ejemplo, requiere la autorización del usuario para iniciar un applet de Java desde Firefox 26.

La razón por la que los informes de prensa no hacen esa distinción es que Oracle utiliza la marca comercial "Java" tanto para el lenguaje de programación como el complemento del navegador que ejecuta applets . De hecho, si un usuario normal se encuentra con la marca registrada de Java, probablemente se refiera a esta última.

Es un tanto especulativo por qué exactamente Sandbox sigue siendo vulnerable. Si me preguntas, una razón es que la misma API se usa con y sin Sandbox, y la mayoría del código de Java se ejecuta sin Sandbox (porque el código es de confianza). Como resultado, es bastante posible que un desarrollador se olvide de esa característica oscura cuando cambia la API de Java o su implementación, exponiendo accidentalmente cosas que deberían estar protegidas (para ilustrar lo fácil que es esto, he aquí el extenso Pautas de codificación seguras para Java SE ). Otra razón relacionada es el tamaño total de la API de Java 6 ).

  

Hay muchos otros lenguajes de programación que no tienen este problema, por lo que debe haber una mejor manera de hacer lo que Java está haciendo mal.

Es un reclamo bastante alto, ¿de dónde sacaste esa impresión? Hay "toneladas de otros lenguajes de programación" que no se han puesto a prueba al igual que Java, o se usan de forma ubicua.

En principio, la razón por la que hay tantos parches de seguridad es porque Java fue diseñado para ser seguro, con una serie de características centradas en la seguridad que otros idiomas no tienen.

  

El entorno del lenguaje Java

     

1.2.2 Robusto y seguro

     

La tecnología Java está diseñada para funcionar en entornos distribuidos, lo que significa que la seguridad es de suma importancia. Con las características de seguridad diseñadas para el lenguaje y el sistema de tiempo de ejecución, la tecnología Java le permite crear aplicaciones que no pueden ser invadidas desde el exterior. En el entorno de red, las aplicaciones escritas en el lenguaje de programación Java están protegidas contra intrusiones por medio de código no autorizado que intenta ponerse detrás de la escena y crear virus o invadir sistemas de archivos.

Si no incluye "estar seguro" en las especificaciones de su lenguaje de programación, rara vez tendrá que lanzar parches de seguridad. Si, por otro lado, ese es uno de tus objetivos declarados, será difícil que no .

Por sí mismo, Java tiene grandes recursos para la seguridad, a saber, su resistencia inherente a los desbordamientos de búfer y los errores de gestión de memoria:

• Todos los accesos a la matriz se verifican con respecto a la longitud de la matriz asignada. Por lo tanto, los desbordamientos de búfer quedan atrapados de manera confiable, y activan una excepción, que es mejor (esto convierte las vulnerabilidades de ejecución remota de código en meras denegaciones de servicio).

• La asignación de memoria se administra a través de un recolector de basura, lo que evita el uso después de errores libres y el doble de errores. Además, el GC permite un manejo más fácil de las cadenas de caracteres (las cadenas son inmutables en Java), lo que elimina la mayoría de las ocasiones para errores de desbordamiento de búfer.

• Se aplica la escritura estricta; El código no puede acceder a los bytes de datos por lo que no son. De nuevo, esto evita vulnerabilidades (los errores en los que se transgreden los tipos de datos se informarán en la compilación o, en el peor de los casos, como tiempo de ejecución ClassCastException ).

Esto hace que Java sea mucho más fuerte que muchos lenguajes de programación (en particular la pareja infernal C / C ++) cuando se trata de seguridad.

Sin embargo, los diseñadores de Java intentaron aprovechar esta seguridad mejorada para dificultar algo, es decir, applets . El problema es la superficie de ataque : como el applet es un código potencialmente hostil, todo lo que haga debe ser controlado. Pero el código hostil debe ser capaz de usar las "clases estándar de Java" si es para hacer algo, por lo que los "puntos de control" deben aplicarse en todas las clases estándar de Java. Por lo tanto, la superficie de ataque consta de cientos de clases que contienen miles de métodos, y todos de ellos deben imponer controles adecuados.

Los diseñadores de Java pecaron por ambición: la dificultad de implementar miles de controles sin fallar fue mucho mayor de lo que imaginaron. Todos los "errores de Java" provienen de este hecho.

Podemos comparar Java con Javascript aquí; Por ejemplo, Java permite el acceso a archivos en discos, pero este derecho no debe otorgarse a los applets, excepto si el applet lo solicitó y el usuario está de acuerdo (lo que implica todo el negocio de firmas de applets). Javascript, menos ambicioso, simplemente carece de cualquier método de acceso a archivos: ¡los controles de acceso en una función no se pueden implementar incorrectamente si la función no existe realmente!

Para resumir: Java está bien y es seguro. Los applets de Java implican una gran superficie de ataque cuya seguridad es muy difícil de garantizar. Sin embargo, para aplicaciones y servidores independientes, usar Java es una buena idea si desea seguridad (esto también se aplica a C #).

En estos días, encontrar más vulnerabilidades puede no implicar cuán inseguro es el software. El problema es cómo reacciona el equipo de respuesta de seguridad de cada proveedor de software y qué tan rápido salen los parches.

Solo verifica la rapidez con la que se aplican parches a Firefox y Chrome. Muchas vulnerabilidades se encuentran en ellos también y se resuelven.

Como recuerdo, Oracle tiene un programa llamado Actualizaciones de parches críticos (CPU) que ofrece parches trimestrales. También lanzan parches sin CPU si existe una vulnerabilidad de día cero . Pero el problema es el tiempo que toma Oracle para lanzar un parche.

El miedo sobrevalorado .. Java en sí está bien; Los problemas ocurren con los applets de Java de la vieja escuela que se ejecutan en los navegadores web, pero dudo que alguien realmente cree applets. La mayoría de las casas de desarrollo han usado Flash o HTML4 / 5 para interfaces web front-end durante al menos los últimos 10 años. p>

En estos días, Java se usa principalmente para JEE backend, clientes de interfaz de usuario (JFX / AWT / SWING), aplicaciones de consola y aplicaciones móviles, por lo que no hay problema.

La respuesta es bastante obvia. ¿Puedes eliminar los archivos de tu computadora usando JavaScript, HTML o Flash? No, no puedes.

¿Qué pasa con Java. ¿Puede eliminar todos sus archivos, borrar completamente su disco duro con un applet de Java (alojado en un sitio web)? La respuesta es sí, si acepta ejecutar el applet. A diferencia de cualquier otro idioma del navegador web.

Java tiene la capacidad de hacer cosas como ejecutar programas en su computadora (ejecutables) y también tiene la capacidad de escribir, actualizar o eliminar archivos en su disco duro.

Además, los applets de Java no son detectables por los escáneres de virus: en la mayoría de los casos, ni siquiera sabrás que arruinó tu computadora. Algunos escáneres pueden detectar que algo está intentando eliminar archivos en un directorio restringido: uno que conozco es Kaspersky , pero la mayoría de las personas tienen esta función activada desactivado por defecto.

Los applets de Java pueden hacer cosas como actualizar archivos de Windows, como HAL.dll , lo que evitará que su computadora arranque. Puede hacer cualquier cosa en su computadora cuando acepta ejecutar el applet.

En algunos casos, ni siquiera importa si un applet de Java está firmado o no firmado, seguirá descargando archivos en su computadora.

Sin mencionar que Java es muy popular.

Hay otro que está creciendo en popularidad, llamado Unity Engine (similar a Flash): tiene los mismos problemas de seguridad como Java y podría hacer nada a tu computadora La única diferencia entre Unity Engine y Java es que Unity se ejecuta sin preguntarte si deseas ejecutarlo o no. Entonces, si alguien tiene instalado Unity Player y ejecuta un juego que contiene un virus, dañará tu computadora.

Menos popular, pero podría ser extremadamente dañino VBScript . Creo que Microsoft Internet Explorer es el único que lo admite actualmente, pero podría estar equivocado. Tiene las mismas habilidades que Java.