La seguridad del lenguaje no está claramente definida, mientras que hay advertencias sobre, por ejemplo, Java. Entonces, ¿cómo puede decir que el idioma no es seguro mientras que la seguridad del idioma no está claramente definida? Si Java no es seguro ahora, ¿es la versión 7 de Java "más segura" que la versión 2 de Java?
Se puede decir que un idioma es "seguro" si es posible implementar su entorno de intérprete / compilador / tiempo de ejecución de manera eficiente, con pleno respeto de la especificación del idioma, y aún impidiendo por la fuerza que ocurran "cosas malas". Entonces depende de las "cosas malas" de las que estés hablando.
Java es "seguro" si desea proteger a la máquina de el código escrito por el desarrollador . Los límites de la matriz se verifican, los tipos no se pueden escapar y la desasignación de la memoria se maneja mediante un recolector de basura , lo que significa que no es teórico factible hacer que un applet de Java, por muy mal escrito que sea, ejecute el código nativo elegido por el atacante. En las mismas condiciones, C es "inseguro" porque no se puede implementar completamente con verificaciones que eviten la ejecución de código arbitrario.
Por supuesto, en la práctica , las cosas cambian un poco: el código C se puede hacer "más seguro" con varias técnicas (como DEP and ASLR ) y el sistema operativo puede" contener "código nativo bajo algunos derechos de acceso específicos (un proceso de" usuario normal "no es root ). Y la actualidad de Java nos muestra que si bien Java es teóricamente seguro, la implementación de la Máquina Virtual de Java y su entorno de ejecución pueden tener agujeros. Hasta cierto punto, la especificación JVM exacta garantiza que la implementación de Java de forma segura sea difícil (es una característica errónea del modelo Applet: fuerza el control por método en toda la biblioteca estándar).
No puede tener una definición única de seguridad del lenguaje, a menos que esté contento con un eslogan subjetivo (¡COBOL apesta! ¡Reglas de F #! ¡Prólogo para siempre!). Todo depende del contexto.
Puede haber alguna confusión aquí. Un lenguaje de programación no incluye inherentemente vulnerabilidades. Son los programas escritos en esos idiomas los que hacen.
Los lenguajes de nivel superior (como Perl, Java, JavaScript, C #, pero no C o C ++) ayudan a simplificar su código de programación, y le permitirán escribir su código de modo que no sea posible un desbordamiento de búfer, lo que es mejor para la seguridad. pero la diferencia de seguridad entre los lenguajes de alto nivel es muy pequeña.
En el caso de Java, hay una zona de pruebas que no ha demostrado ser completamente efectiva. Este sandbox estaba destinado a permitir que un programa se escriba en Java y luego se ejecute en el navegador, sin tener acceso a la computadora en la que se estaba ejecutando. Es el entorno limitado de Java el que ha tenido problemas de seguridad, no Java en sí. No puedo hablar de la comparación entre Java 7 y Java 2.
Los idiomas se clasifican como seguros y no seguros según algunas propiedades. Un lenguaje seguro como dices incluye al menos las siguientes propiedades:
El lenguaje Java tiene todas estas propiedades y, por lo tanto, se puede clasificar fácilmente como un lenguaje "seguro". La inseguridad que mencionó no se debe al lenguaje en sí, sino a un entorno de sandbox inseguro y llamadas de biblioteca inseguras. Separe cualquier código de explotación de Java reciente y todo lo que hace es eludir las restricciones de seguridad para llamar a un código de clase privilegiada. No tiene nada que ver con la inseguridad del lenguaje en sí, sino con el diseño complejo e inseguro de las bibliotecas de Java.
La seguridad del lenguaje se puede interpretar más ampliamente que afectando simplemente a la seguridad. Pero como este es un sitio de seguridad, solo debemos restringirnos a la seguridad.
Es evidente que la selección de idioma tiene una importancia significativa sobre si obtendrá ciertos tipos de vulnerabilidad. Escriba un programa no trivial en C y estará lleno de errores de corrupción de memoria (desbordamiento del búfer, uso después de que se libere, etc.).
Hay un par de definiciones útiles:
Memoria segura : esto significa que un programa dentro del idioma no puede acceder a la memoria fuera de las asignaciones. No se ejecuta más allá de un búfer ni se utiliza una asignación después de que se haya liberado. Eso es difícil de probar automáticamente para un lenguaje como C. La seguridad de la memoria generalmente se logra a través de la recolección de basura y el uso de la seguridad de tipo más restrictiva.
Tipo de seguridad : no confunda esto con solo no desordenar sus tipos en idiomas inseguros. Esta es una garantía que va más allá de la seguridad de la memoria en el sentido de que no puede usar un tipo de manera inapropiada para el tipo real del objeto. No puede tratar un puntero como un entero, por ejemplo.
Curiosamente, desde 1.5 Java no es seguro para el tipo de vainilla. Es de tipo seguro con respecto a los tipos sin procesar, según lo utilizado por la JVM y el lenguaje de Java 1.4 y anteriores. No es seguro con respecto al sistema completo de tipo de idioma, incluidos los genéricos. Esto no parece importar en absoluto, en gran parte porque para acceder a un objeto, el bytecode debe realizar una verificación de tipo en bruto.
Para las vulnerabilidades de corrupción sin memoria, las bibliotecas se vuelven más importantes. Por ejemplo, la inyección es una clase de vulnerabilidad increíblemente popular, pero realmente no hay ninguna excusa para tener alguna.
El código móvil (que es un código móvil y no confiable) es algo completamente diferente. La seguridad se puede lograr a través de una caja de arena (como NaCl de Google), un Modelo de Capacidad de Objetos (jerga que significa esencialmente POO en un entorno seguro) o alguna combinación de los otros dos.
En cuanto a Java SE 1.7 vs 1.2. No ha habido mucho cambio. 1.2 es muy diferente a 1.1, y 1.0 fue un poco diferente de nuevo (aunque en realidad antes prestaba atención a este tipo de cosas).
Problemas específicos en el lenguaje de Java que causan vulnerabilidades:
static (para campos, cuando no es inmutable) es una forma de una sola palabra clave para introducir vulnerabilidades y destruir la calidad del código. transient y una implementación que ni siquiera es posible en el código de bytes) son dudosos. Lea otras preguntas en las etiquetas java known-vulnerabilities