¿Por qué es importante la codificación segura de Java?

Question

Tengo problemas para entender por qué la codificación segura de Java es importante. Por ejemplo, ¿por qué es importante declarar las variables como privadas? Quiero decir que entiendo que será imposible acceder a esas variables desde fuera de la clase, pero simplemente podría descompilar la clase para obtener el valor. Del mismo modo, definir una clase como final hará imposible la subclase de esta clase. ¿Cuándo sería peligroso subclasificar una clase para la seguridad? De nuevo, si es necesario, podría descompilar la clase original y volver a implementarla con el código malicioso que pueda querer. ¿El problema surge cuando el usuario "confía" en las aplicaciones? ¿Y la gente podría abusar de esta confianza de alguna manera? Básicamente lo que estoy buscando es un buen ejemplo de por qué se deben seguir las pautas de codificación segura.

Answer 1

La programación es difícil.

Si define API estrictas, que no exponen las variables que no se supone que estén expuestas (nos gusta llamar a esto encapsulation), ayuda a los usuarios de sus API y, por lo tanto, facilita la programación. Esto se considera algo bueno.

Las razones no son principalmente de "seguridad", como mantener secretas las cosas secretas, tanto como la claridad, la simplicidad y la comprensibilidad.

Como beneficio adicional, es mucho más fácil hacer que las cosas funcionen correctamente si puede saber que el usuario de la API no está cambiando "sus" variables a sus espaldas, por supuesto.

Answer 2

Es "seguro" lo que significa que un trabajo interno de clase está oculto para quien lo usa.

El término seguro no se usa porque al "proteger un servidor" se usa para prever el hecho de que un usuario de una clase no tiene que preocuparse por cómo la clase realizará la tarea que él quiere.

Tomando su ejemplo:

La exposición de las variables de una clase permitiría al usuario de sus habilidades de clase de su existencia, que es algo que no quieres, por ejemplo: sólo tiene que pulsar un botón para encender la luz, no necesitas ahora que dentro hay cobre o Whater que necesita para realizar la tarea.

Answer 3

Solo para agregar a lo que otros ya han dicho: algunas de estas características también se pueden ver simplemente como una forma de indicar la intención. Si hago un miembro private, hago que sea "imposible" que otros accedan a él (es posible, pero eso es además del punto aquí), pero más importante, les digo a los usuarios que este es un detalle de implementación, que no deben confiar en .

Answer 4

Hay dos problemas aquí.

El primero al declarar las variables como protegidas o privadas, no se convertirán en parte de su API pública. Otras clases pueden depender de su clase en el futuro, y es importante que pueda cambiar tanto como sea posible si desea incluir nuevas funciones, mejorar el rendimiento, etc. Si todos sus valores son públicos, no todos sus valores internos. los valores y mecanismos son públicos. Cambiarlos puede romper otras clases que dependen de la suya.

El segundo, es que al exponer variables permite que otras clases cambien sus valores. Si cambian sus valores internos, pueden romper su programa y crear un extraño comportamiento inesperado. Si crea un sistema que depende del rendimiento preciso de una de sus clases y los valores internos cambian, entonces ya no podrá confiar en ese sistema. Subclases hace esto más complicado. Su sistema puede depender de una clase de cierto tipo para realizar las acciones esperadas.Al crear subclases, es posible crear una nueva clase que parezca ser del mismo tipo pero que no realice las acciones esperadas.

Por ejemplo, si tiene un cuadrado de clase con una función protegida getArea(), espera devolver el área de un cuadrado. Sin embargo, se puede hacer una nueva clase que extienda el cuadrado, por ejemplo, el rectángulo de la clase se extiende al cuadrado. Ahora rectange puede anular getArea(), pero sigue siendo de tipo cuadrado, lo que puede romper algo que depende de esa funcionalidad de square. Al hacer que tu clase sea definitiva, afirmas que esto nunca puede ocurrir en tu sistema.

Este tipo de "codificación segura" no impedirá que alguien vea su código fuente, pero ayuda a que su código sea más confiable y utilizable en el futuro.

Answer 5

Java es un idioma object-oriented programming, y uno de los conceptos clave en la programación orientada a objetos es encapsulation.

La idea detrás de la encapsulación es "ocultar" los detalles de implementación tales como variables internas que mantienen el estado del objeto y el funcionamiento interno como algoritmos, y solo proporcionan una interfaz que otros objetos pueden usar para realizar funciona con el objeto.

Usando ese concepto, uno quisiera ocultar los estados internos usando las variables private para evitar que otros objetos afecten directamente los estados internos. En Java, es común ver getters y setters (por ejemplo, getColor y setColor) para trabajar con objetos.

Además, la encapsulación también puede aumentar la robustez del código.

Por ejemplo, al restringir el acceso a los estados internos, sería posible realizar algunas comprobaciones de cordura antes de que se modifique un objeto.

Como un ejemplo sólido, decir que no había un objeto Score que iba a tener un valor percent entre 0 y 100. Al proporcionar un método setPercent(int) que valida que el valor especificado estuvo dentro del rango permisible, evitaría que el objeto Score se establezca en un estado inaceptable.

Por lo tanto, tratando de manipular directamente el estado interno escribiendo una declaración como score.percent = 150 podrían prevenirse, si el método setPercent produce un error o una lanza Exception si el valor especificado es inaceptable.

Answer 6

imagine que su objeto tiene una propiedad interna que no es privada (oculta) y que su código accediendo a esta propiedad se ejecuta en un entorno multiproceso, por lo que N hilos comenzarían a acceder a él simultáneamente, a 5 hilos le gustaría cambiar esto propiedad, 4 para leer. No hay forma de que se asegure de que las cosas funcionen bien, ni el subproceso sabrá qué datos contiene en el momento y si cambió con éxito la propiedad de ese objeto.

Tendrá que programar una pieza especial de código que será responsable de manejar el acceso síncrono y aún así no se garantizará que su código funcione bien ya que todavía debe verificar el resto de clases 680 en su programa accediendo a esa propiedad para acceder a ella directamente

En resumen, usted está en un gran problema, y ​​la depuración es una pesadilla ya que no se sabe cuando se chagned los datos, lo que hizo que el hilo, de donde sucedió etc.

Sólo un escenario de lo está sucediendo si no encapsulas ...

Lo bueno es que su código funciona un 1% más rápido, hay menos carga en la pila, ha logrado aumentos de rendimiento probablemente insignificantes que pagará con bloqueos periódicos del sistema y menores posibilidades de depuración exitosa.

Answer 7

El término "codificación segura" se refiere a la construcción de software que claramente intenta evitar las vulnerabilidades de seguridad, ya sea en C, Java, Ruby, ensamblador o cualquier otra cosa. Quizás la parte más importante de eso, después de seleccionar un sistema de lenguaje seguro, es mantener buenas prácticas de programación. Si un programa no está claro, entonces tiene pocas posibilidades de que sea digno de confianza.

Para Java hay dos guías notables:

• Secure Coding Guidelines for the Java Programming Language, version 2.0. Actualizado hace dos años, y en necesidad de una actualización.
• The CERT Sun Microsystems Secure Coding Standard for Java. Una nueva wiki compatible con CERT y Sun que se puede actualizar con lo que creas importante. Esto toma una visión mucho más amplia que las pautas de Sun. Por ejemplo, las directrices de Sun no están realmente relacionadas con el desbordamiento de enteros porque todos los límites de la matriz están marcados, pero la wiki sí lo hace porque aún puede causar errores en el programa.

En Java existen dos modos distintos de codificación segura.

En una se trata de un código que puede no tener todos los privilegios que tiene su código. Por ejemplo, si está escribiendo una biblioteca o firmando un código, debe hacerlo. Debería ser imposible que un código malicioso aproveche tus permisos de forma involuntaria. ¡Esto es difícil!

Más comúnmente se trata de programas que solo tratan con datos que no son de confianza. Por ejemplo, servidores web (piense en inyección XSS y SQL) y programas de aplicaciones de escritorio que tratan con archivos que no son de confianza (generalmente el problema es que el código C tiene desbordamientos de búfer, es mejor C++ genuino). En algunas situaciones, la denegación de servicio (DoS) puede ser un problema grave.

Existe cierta superposición. Por ejemplo, los intérpretes se ejecutan con los permisos del código de intérprete y pueden ser bastante "potentes".