Pregunta Clases externas que acceden a métodos privados del paquete


Supongamos que tengo una clase en mi paquete org.jake y tiene un método con acceso predeterminado (sin modificador). Entonces el método es visible solo dentro del paquete.

Sin embargo, cuando alguien recibe el jar de mi framework, ¿qué es lo que les impide escribir una nueva clase, declarando su paquete como org.jakey usando mi método supuestamente invisible?

En otras palabras, ¿hay algo que pueda hacer para evitar esto?


13
2018-05-21 06:25


origen


Respuestas:


Tú podrías sellar el paquete en tu archivo jar Aunque no es a prueba de balas.

Lo principal es no depender de los modificadores de acceso, etc. desde un punto de vista de seguridad para empezar, realmente. Si alguien ejecuta el código con permisos no restringidos, tendrá acceso a todo tipo de cosas. Los modificadores de acceso realmente solo ayudan a evitar que las personas accidentalmente disparándose en el pie.

Si alguien está dispuesto a poner clases en su paquete para eludir su encapsulamiento, claramente están ignorando sus mejores intenciones; les digo que les permitan seguir adelante, pero no brinden apoyo para ese escenario.


16
2018-05-21 06:28



No hay nada que puedas hacer para evitar esto. Incluso a los miembros privados se puede acceder a través de la reflexión. Debería considerar los modificadores de acceso en Java como meramente sugestivos.


6
2018-05-21 06:28



En primer lugar, este es el escenario "DRM": en última instancia, alguien lo suficientemente determinado poder derrota las protecciones que implementes mediante el suministro de un funky modificado en tiempo de ejecución u otras cosas similares. El escenario inverso -donde el tiempo de ejecución es confiable pero algunos de los paquetes no lo son- es abordado adecuadamente por Java mediante el uso de ClassLoader restricciones, pero eso solo puede funcionar cuando hay algo que puede hacer cumplir las restricciones de manera confiable; es por eso que su escenario está básicamente condenado.

Sin embargo, si suponemos que el tiempo de ejecución en sí mismo es confiable entonces podrías intentar, en tu método súper secreto, obtener el rastro de la pila de la pila que se está ejecutando actualmente (ver stackoverflow.com/questions/1069066/... para saber cómo) y las pruebas para ver si la persona que llama del método actual es alguien en quien confía para obtener acceso. Un administrador de seguridad sería aún más adecuado, pero no puede confiar en que el entorno tenga uno de los instalados que desee (está mucho más claramente bajo el control del atacante). ¡Tenga en cuenta que no he probado las opciones en este párrafo!

La otra alternativa es poner sus secretos en un servicio que usted controla y solo ofrecer acceso remoto a ellos. O deje de preocuparse por el uso de mecanismos técnicos para lidiar con un problema que es fundamentalmente sobre cuestiones comerciales y legales (por ejemplo, ¿por qué se trata de personas en las que no puede confiar?)


1
2018-05-21 10:44



Yo diría que simplemente no les permiten ejecutar código donde pueda llamar al suyo, es decir, en la misma JVM. En cambio, podría considerar ofrecer solo un servicio (web) al que puedan llamar externamente. Sin embargo, no estoy muy actualizado sobre las mejores formas de implementar esto.


0
2018-05-21 10:23



Preguntas populares