Clases externas que acceden a métodos privados del paquete

Question

Supongamos que tengo una clase en mi paquete org.jake y que 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é impide que escriba una nueva clase, declarando su paquete como org.jake y utilizando mi método supuestamente invisible?

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

Answer 1

Puede seal the package en su archivo jar. Aunque no es a prueba de balas.

Lo principal es no depender de los modificadores de acceso, etc. desde el punto de vista de la 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 detener a las personas desde 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 soporte para ese escenario.

Answer 2

No hay nada que pueda 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.

Answer 3

Yo diría que simplemente no les permiten ejecutar código donde puede 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.

Answer 4

primer lugar, este es el escenario de “DRM”: en última instancia, alguien lo suficientemente determinado puede derrotar a cualquier protección que se aplican por mediante el suministro de un tiempo de ejecución modificado funky o otras cosas. El escenario inverso, donde el tiempo de ejecución es confiable pero algunos de los paquetes no lo son, se aborda adecuadamente mediante Java mediante el uso de las restricciones adecuadas ClassLoader, 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 asumimos que el tiempo de ejecución en sí es confiable entonces usted podría intentar, en su método de súper secreta, para obtener el seguimiento de la pila de la pila se está ejecutando actualmente (ver stackoverflow.com/questions/1069066/… para saber cómo) y las pruebas para ver si el llamador del método actual es uno en el que 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 tratar un problema que es fundamentalmente sobre cuestiones comerciales y legales (por ejemplo, ¿por qué se trata de personas en las que no puede confiar?)