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

Question

Tengo problemas para entender por qué es importante la codificación segura de Java.Por ejemplo, ¿por qué es importante declarar las variables privadas?Quiero decir, entiendo que será imposible acceder a esas variables desde fuera de la clase, pero podría simplemente descompilar la clase para obtener el valor.De manera similar, definir una clase como final hará imposible subclasificar esta clase.¿Cuándo sería peligroso para la seguridad subclasificar una clase?Nuevamente, si fuera necesario, podría descompilar la clase original y volver a implementarla con cualquier código malicioso que quisiera.¿El problema surge cuando el usuario "confía" en las aplicaciones?¿Y entonces 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 duro.

Si define las API estrictos, que no expongan variables que no se supone que están expuestos (nos gusta llamar a este encapsulación ), que ayudan a los usuarios de sus API, y de este modo facilitar la programación. Esto se considera una buena cosa.?

Las razones no son principalmente la "seguridad", como en mantener las cosas en secreto secretos, tanto como la claridad, sencillez y comprensibilidad.

Como beneficio adicional, es mucho más fácil para que todo funcione correctamente si se puede saber que el usuario de la API no está cambiando "su" variables detrás de la espalda, por supuesto.

Answer 2

Se trata de "seguro" que significa que una clase de trabajo interno están ocultos a quien lo usa.

El término seguro no se utiliza como en "seguridad de un servidor" se utiliza para la intención del hecho de que un usuario de una clase no tiene que preocuparse acerca de cómo la clase va a realizar la tarea que quiere que lo haga.

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, que no es necesario ahora que en su interior hay cobre o whater que necesita para llevar a cabo la tarea.

Answer 3

Java es un programación orientada a objetos lenguaje, y uno de los conceptos clave en la programación orientada a objetos es encapsulación.

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

Usando ese concepto, a uno le gustaría ocultar estados internos usando private variables para evitar que otros objetos afecten directamente a los estados internos.En Java, es común ver captadores y definidores (p. ej. getColor y setColor) para trabajar con objetos.

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

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

Como ejemplo sólido, digamos que hubo un Score objeto que iba a tener un percent valor entre 0 y 100.Al proporcionar un setPercent(int) método que valida que el valor especificado estaba dentro del rango permitido, evitaría la Score que el objeto quede en un estado inaceptable.

Entonces, intentar manipular directamente el estado interno escribiendo una declaración como score.percent = 150 podría prevenirse, si el setPercent El método causa un error o arroja un Exception si el valor especificado es inaceptable.

Answer 4

Hay dos problemas aquí.

La primera, al declarar variables como protegidas o privadas, no pasarán a formar parte de su API pública.Otras clases pueden depender de su clase en el futuro, y es importante que sea libre de cambiar tanto como sea posible si desea incluir nuevas funciones, mejorar el rendimiento, etc.Si todos sus valores son públicos, entonces todos sus valores y mecanismos internos son públicos.Cambiarlos puede romper otras clases que dependen de la tuya.

La segunda, es que al exponer variables permite que otras clases cambien sus valores.Si cambian sus valores internos, pueden dañar su programa y crear un comportamiento extraño e inesperado.Si crea un sistema que se basa en el rendimiento preciso de una de sus clases y se cambian los valores internos, ya no podrá confiar en ese sistema.La subclasificación hace que esto sea 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 parece ser del mismo tipo pero que no realiza las acciones esperadas.

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

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

Answer 5

Sólo para añadir a lo que ya han dicho: Algunas de estas características pueden también ser visto simplemente como una forma de expresar la intención. Si hago un miembro private me lo hacen "imposible" para que otros puedan acceder a ella (es posible, pero eso es además el punto aquí), pero lo más importante que decirle a los usuarios que este es un detalle de implementación, que no deben confiar.

Answer 6

Imagínese si su objeto tiene una propiedad interna que no es privada (oculta) y su código para acceder a esta propiedad se ejecuta en un entorno de subprocesos múltiples, por lo que N subprocesos comenzarían a acceder a él simultáneamente, a 5 subprocesos les gustaría cambiar esta propiedad, de 4 a leer.No hay forma de asegurarse de que todo se ejecute correctamente, ninguno de los subprocesos sabrá qué datos contiene en este momento y si cambió correctamente la propiedad de ese objeto.

Tendrá que programar un código especial que será responsable de manejar el acceso sincrónico y aún así eso no será garantía de que su código funcione correctamente ya que aún debe verificar el resto de las 680 clases en su programa para acceder a esa propiedad para no acceder a ella directamente. .

En resumen, se encuentra en un gran problema y la depuración es una pesadilla ya que no sabe cuándo se cambiaron los datos, qué hilo lo hizo, desde dónde sucedió, etc.

Sólo un escenario de lo que está sucediendo si no se encapsula...

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

Answer 7

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

Para Java hay dos guías notables:

• directrices de codificación segura para el lenguaje de programación Java, versión 2.0. Actualizado dos años hace, y en la necesidad de una actualización.
• Los CERT Sun Microsystems Asegure codificación estándar para Java. un nuevo wiki apoyada tanto por CERT y Sun que puede ser actualizado con lo que se siente es importante. Esto tiene una visión mucho más amplia que las directrices del sol. Por ejemplo, las directrices sol no está realmente preocupado con el desbordamiento de entero porque todos los límites de la matriz se comprueban, pero el wiki hace porque todavía puede causar errores de programa.

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

En una se trata de código que pueden no tener todos los privilegios que hace el código. Por ejemplo, si usted está escribiendo una biblioteca o la firma de código que necesita estar haciendo esto. Debe ser imposible que el código malicioso para aprovechar sus permisos de forma no intencionada. Esto es difícil!

Más comúnmente se trata de programas que se ocupan de datos sólo no son de confianza. Por ejemplo, los servidores web (pensar XSS y SQL inyección) y programas de aplicación de escritorio se trata de archivos no son de confianza (por lo general el problema es con el código C que tienen desbordamientos de búfer - genuina ++ C es mejor). En algunas situaciones denegación de servicio (DoS) puede ser un problema grave.

Existe un cierto solapamiento. Por ejemplo intérpretes ejecutan con los permisos del código del intérprete y pueden ser bastante "potente".