¿Cómo puedo evitar la ingeniería inversa de los archivos .war de JavaEE 6?

Question

Tenemos varias aplicaciones JavaEE 6 (archivos .war) que necesitamos proteger contra la ingeniería inversa, pero parece que no hay muchas opciones disponibles.

Me gusta la idea de un archivo .jar encriptado (SJAR) utilizado en los productos JarCrypt/JInstaller, pero no está claro si JarCrypt/JInstaller funcionará en una aplicación JavaEE 6. servidor como Glassfish3.1. Los archivos SJAR encriptados tienen que ser descifrados por una biblioteca nativa utilizando un cargador de clases personalizado, así que aparentemente tendría que agregar un cargador de clases personalizado a Glassfish.

¿Alguien ha utilizado las tecnologías JInstaller/JarCrypt? ¿Funcionan en un servidor de aplicaciones?

También he examinado la ofuscación, pero para las aplicaciones JavaEE hay muchos problemas. Tendría que dejar todos los servicios web y las búsquedas JNDI solo. El uso de cosas como a.b.c.MyClass.class (es decir, para crear Log4j Loggers) es problemático. Leer archivos de registro se vuelve difícil. Y para todos esos problemas, la ofuscación casi no hace nada para asegurar nuestro código.

He intentado con Proguard, pero aparentemente es can't deal with the JavaEE 6 libraries.

¿Existen otras alternativas o estas son todas las opciones que tengo?

Gracias.

Answer 1

¿Está enviando esas aplicaciones a terceros que las ejecutarán en su infraestructura? Entonces el cifrado no lo ayudará en absoluto, porque la JVM no puede ejecutar el código de bytes cifrado y it is trivial to retrieve the loaded class files from a running app.

Eche un vistazo a GuardIT for Java - hasta la fecha no he tenido experiencia con él, pero al menos el vendedor afirma que está específicamente diseñado para proteger las aplicaciones web de Java.

Si sus aplicaciones se ejecutan en Tomcat, podría haberlas compilado en código nativo. ¿O necesitan un servidor de aplicaciones Java EE completo?

Answer 2

La prevención es realmente imposible. Lo mejor que puede esperar es elevar la barrera ligeramente, lo que en gran medida dará como resultado que se sienta mal el factor Security through obscurity es no security at all. Los productos que pretenden hacer esto están actualmente vendiendo silicon snake oil

Answer 3

He estado trabajando en la protección de software durante los últimos dos años y he evaluado la mayoría de las soluciones europeas en el mercado (lo siento, evitamos las soluciones estadounidenses ...).

Hay cuatro técnicas que hemos visto como soluciones de protección: - ofuscación - Cifrado - compilación a código nativo - transcodificación

usted probablemente sabe más de estas técnicas a excepción de transcodificación.

La ofuscación requiere mucho trabajo por lo que, al final, es una protección deficiente. Pero puedes combinar ofuscación y con todas las otras técnicas.

La encriptación es bastante fácil de romper (no hay una solución para almacenar la llave en un área segura, incluso con un Dongle es fácil de recuperar). Además, hay un trabajo para robar clases descifradas de la memoria (o, más directamente, la clave de cifrado).

La mayoría de los desarrolladores de Java piensan que la compilación de código nativo proporciona una buena protección ... Pero, no proporciona protección en absoluto; durante más de 20 años ha sido posible revertir el código nativo y hay algunos ingenieros de ingeniería inversa muy capacitados para hacerlo. También hay algunos buenos compiladores inversos para el lenguaje C para ayudar ...

Finalmente, existe Transcodificación (de la cual hay muy poca información en internet). Esta es la única protección eficiente contra ingenieros revertidos expertos. Es un dolor de romper porque requiere años de trabajo. No es imposible, pero exige mucho, mucho tiempo. Además, cada vez que se lanza un nuevo parche, debe reiniciar la ingeniería inversa nuevamente porque en cada versión, el código es totalmente diferente. ¿Hay algún inconveniente? Sí, rendimiento. Pero se puede combinar con todas las otras técnicas y no existen limitaciones de implementación (servidor de aplicaciones, generación dinámica de clases, etc.) o limitaciones de Java (reflexión, etc.).

No hay una bala de plata. Cada solución se puede usar dependiendo de tu objetivo. Proteger contra un gobierno o contra script kiddies no es lo mismo ... Elija una solución relativa a los pros y los contras, y más importante aún, las limitaciones relativas (como Jarcryp y la ofuscación en la aplicación web).

Para responder a la pregunta sobre Jarcryp (y otras soluciones que realizan cifrado), es posible: solo tiene que pedirle a Componio (que proporciona JInstaller/Jarcryp) que le proporcione un cargador de clases que hereda del cargador de clases del servidor de aplicaciones tu usas.

La transcodificación funciona con todos los servidores de aplicaciones.

Answer 4

La ofuscación de archivos WAR con ProGuard lo ayudará a encriptar su archivo war en gran medida. Para obtener más información, visite el enlace http://bratonfire.blogspot.in/2012/01/war-file-obfuscation-using-proguard.html