¿Hay casos de la vida real, donde el uso de la palabra clave final en Java aumenta la seguridad del sistema?

Esta característica de Java tiene sentido, desde el punto de vista de la seguridad, en el modelo de applet : un contexto donde, de hecho, el el atacante ejecuta su código en su máquina y, sin embargo, ese código potencialmente hostil todavía está contenido. Esto fue pensado inicialmente para navegadores web, no para servidores.

Toda la contención de un applet de Java se realiza llamada por llamada, de manera muy precisa. Existe un marco complejo de permisos que codifica lo que puede hacer el applet y lo que no puede hacer. En particular, un applet básico no puede realizar una serialización arbitraria de código, o reflexión para inspeccionar y / o modificar instancias de su propio paquete, o llamar a código nativo. La palabra clave final también tiene sentido en ese contexto: dado que String es final , las clases estándar pueden asumir que cuando reciben como argumento un String , es el objeto genuino, no un EvilString , que extiende String pero actúa de manera inesperada cuando se invoca su método Substring() .

Resultó que mantener la seguridad en estas condiciones era un problema difícil, más difícil de lo que Sun creía inicialmente. Hay cientos, si no miles, de clases de biblioteca estándar que deben hacerse "conscientes de los permisos" y, para cada una de ellas, el código debe tener cuidado de hacer cumplir los permisos apropiados. Era inevitable que la gente de Sun, por muy competentes que fueran, se olviden de algunos casos de esquina, lo que lleva a vulnerabilidades explotables. Durante los últimos años, ha habido un flujo constante de "vulnerabilidades del applet de Java" que permiten que un sitio web malvado tome el control de cualquier navegador web que lo visite, siempre que ese navegador use un complemento de Java que no haya sido arreglado.

Nada de esto afecta a Java como lenguaje de programación, ya que se usa a menudo en servidores o en aplicaciones de escritorio grandes; en estas situaciones, de hecho, no hay ningún código hostil ejecutándose localmente.

La palabra clave final todavía puede servir como documentación aplicada por el compilador (por lo tanto, no contra los atacantes , sino como un recordatorio para los programadores descuidados); también ayuda a la optimización (cuando la JVM ve una llamada a un método final , o a cualquier método en una clase final , entonces sabe que puede optimizar la llamada en un salto directo al código del método, ya que hay de ninguna manera ese método podría ser anulado).

También hay seguridad de diseño :

Marcando clases y métodos como final ; el equipo de desarrollo poda la cantidad de mutación futura en el código sensible *. Esto guía al equipo de desarrollo (que puede ser distribuido) y a los futuros mantenedores de código o proyectos de mejora sobre dónde se produce y debería ocurrir el comportamiento sensible, concentrando el riesgo de diseño en un área más pequeña.

Si recuerdo correctamente, las clases de BouncyCastle que no están destinadas al consumo público de la API se bloquean de esta manera para desalentar el comportamiento polimórfico inesperado y el diseño de cripto-primativos caseros de BouncyCastle. Si bien final no impide que nadie modifique el código fuente y vuelva a compilar como mejor le parezca, para cualquier proyecto con un buen diseño, final ofrece un indicador de advertencia decente para los nuevos desarrolladores de que la mutación del método puede tener efectos secundarios inesperados. Integridad del marco interno. Y por lo tanto sobre la seguridad.

_{* Para la gran inconveniencia de los desarrolladores de POO entrenados clásicamente, podría agregar.}