¿Los miembros privados son realmente más "seguros" en Java?

Question

Aprendizaje de Java Algunas veces me enseñaron a usar el modificador de acceso private para no exponer la "información sensible" a otras clases, como si esto pudiera abrir un agujero de seguridad legítimo. Pero nunca me encontré con una situación en la que restringir la visibilidad de los miembros fuera más que una conveniencia para modelar un programa de forma orientada a objetos.

Son private campos y funciones en las clases de Java realmente más "seguro" que de lo contrario?

---

EDITAR - Recopilación de las mejores respuestas.

Por qué private no significa "seguro":

• descompiladores permiten mirada estática en el código de bytes
• reflexión biblioteca permite el acceso en tiempo de ejecución a los miembros privados

Lo private es bueno para:

• mantenimiento de código debido a forzar el acceso a nivel de método
• modularidad del código al ocultar los detalles de implementación

Answer 1

nunca he oído hablar de él - en cualquier sentido serio - como una problema de seguridad. Quiero decir, los decompiladores funcionan. Puede usarlos para descubrir qué está pasando dentro del bytecode.

Tener private miembros es un problema de mantenimiento. Si solo le proporciono acceso a nivel de método a mi parte interna, entonces mi única responsabilidad es garantizar que mis métodos de API sigan funcionando. No estoy encerrado en el uso de un Double frente a un BigDecimal en el interior, siempre y cuando mis métodos continúen devolviendo Double s (por ejemplo).

Answer 2

private no es realmente para la seguridad, ya que la reflexión puede omitirlo (modulo classloader/cosas de carga de clase segura). Sirve como una indicación de intención, y como barrera para un tipo de error de programación.

Pero considere una API de terceros: los usuarios de la API ni siquiera ven las propiedades o los métodos private. No se trata solo de su propio código, sino de qué código está expuesto a los demás. (De nuevo mirándolo desde el punto de vista "No estoy intentando entrar en el código")

Answer 3

No, no son más "seguros" en ese sentido, aunque algunos (muy pobres) libros sobre Java intentan para explicar private de esa manera. Si un atacante tiene la capacidad de provocar la ejecución de código arbitrario de Java en su proceso, toda la "seguridad" ya no existe. Y como otra respuesta ya mencionada, la reflexión puede eludir el modificador de acceso private.

Answer 4

Obviamente, los principios de hacer todo privado donde sea posible solo se aplican si se adhiere al open-closed principle; de lo contrario, si las personas se acostumbran a editar las partes internas de las clases existentes en lugar de extenderlas, pueden cambiar la encapsulación de variables de miembros privados ya sea a través de hacerlos accesibles a través de mutadores y accesorios o cambiando el modificador de acceso.

Answer 5

En lo que respecta a la seguridad, la respuesta es "no realmente": determinados hackers podrían llegar a sus campos privados y llamar a sus funciones privadas con un poco de reflexión; todo lo que necesitan es un JAR con su código.

Aunque ocultar información "sensible" no hace que su clase más segura , lo hace (junto con los sistemas construidos de él) mucho más fácil de mantener . Entonces esta respuesta no es una excusa para hacer públicos a todos los miembros de tus clases.

Answer 6

Creo que el significado de "seguridad" de su instructor no se trata de mantener a los piratas informáticos fuera, sino de evitar errores. Al hacer que todo sea lo más privado posible, se limitan las formas en que una clase puede meterse con otra clase sin que lo sepa. Este es un ejemplo de Modular Programming.

Answer 7

Btw: la reflexión en Java en realidad le permite anular los modificadores de acceso de los campos de los objetos. Ver javadoc y un example.

Answer 8

Estoy de acuerdo en general con las respuestas hasta ahora (es decir, que private es realmente para la seguridad del código, no para la seguridad real). Varias respuestas han señalado que puede omitir private mediante reflexión. Tenga en cuenta que puede, a su vez, deshabilitar la reflexión si habilita un Java SecurityManager. Ver particularmente el ReflectPermission. Sin embargo, los administradores de seguridad rara vez se utilizan (fuera de la zona de pruebas habitual del navegador).