Seguridad aplicación Java EE

Hola a todos, me gustaría saber si alguien por aquí me puede ayudar un poco en algo que le he estado dando vueltas pero no encuentro cómo solucionarlo:

Resulta que tengo una aplicación J2EE que voy a instalar en el servidor de un cliente, pero esa aplicación yo la manejo por licencias que están instaladas en una tabla de la bd. Lo que pretendo es que no puedan abrir la bd, cambiar la fecha de la licencia (así de fácil podrían tener la aplicación 2 años más jejee). Intento protegerla para que no modifiquen la tabla donde está la licencia que les platico.

De entrada, ya tengo todos los passwords encriptados en la bd, pienso encriptar la fecha de la licencia. Lo que yo me pregunto es si no sería muy fácil abrir mi .war, ver un archivo properties para sacar el salt y luego decompilar el código fuente para ver el algoritmo de encripción que estoy utilizando, para luego con un programita poder generar lo que ellos quieran y modificar la bd?

Algo más que se me ocurrió fue hacer distintos usuarios para la bd (postgresql), que yo tuviera el root y ellos un usuario con el que solo puedan hacer backups diarios, pero creo que de esta forma, ellos podrían ver la estructura de la bd, hacer un clon, modificar el war y apuntar hacia la bd clon......

Alguna idea o sugerencia sobre mi esquema y de cómo podría proteger mi aplicación? No conozco bien, pero tal vez meter todo con jndi y que el contenedor me encripte los datos?
Muchas gracias de antemano por su ayuda y sugerencias

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

PKI

la única solución verdaderamente confiable es usando PKI:

- Genera un par de llaves RSA
- Cifra con la llave privada la fecha de expiración, junto con un MD5 o algo de la llave pública
- Anexa la llave pública en tu aplicación
- Cuando quieras validar la fecha de expiración, la descifras con la llave pública que está en la app, y de paso verificas que el MD5 de la llave pública con la que descifraste el dato, sea el que viene junto con la fecha.

La única manera de burlar esta seguridad seria que el cliente genere un par de llaves y haga lo mismo, reemplazando tu llave pública con la de ellos (que no es imposible, pero pues es más complicado si dicha llave la guardas como algo que no sea obvio en la app, y de hecho el MD5 de la llave pública podría estar hardcodeado en algun lado).

muchas gracias, voy a

muchas gracias, voy a investigar un poco sobre lo que mencionas y ya estaré posteando mis resultados
Gracias por tu tiempo

Firmar archivo WAR

Otra pregunta, me imagino que haciendo lo que me cuentas, también sería fácil decompilar el código, reconstruir un archivo .java modificando la sentencia if donde yo compare la licencia por un if(true)...., luego recompilar con un poco de esfuerzo y listo !!

Creo que de esa forma, se podría burlar la seguridad sin nisiquiera generar las llaves que mencionas, no crees?
Hay alguna forma de firmar el archivo war, para que reconozca si algún archivo .class fue modificado?

Gracias de antemano por tu ayuda.

Algún comentario?

Alguien que pueda ayudarme en este tema o alguna sugerencia ?
Gracias

Imagen de ezamudio

no hay

No existe una solución infalible para el problema que postulas. Si el atacante tiene acceso a tu aplicación, puede descompilarla y encontrar la validación que sea y burlarla. Es la naturaleza de un crack y es imposible de eludir al 100%. La solución que propuse inicialmente es para dificultar el proceso, pero si crees que el atacante (tu cliente) está dispuesto a dedicar todo el tiempo que sea necesario para descompilar toda tu aplicación y revisar el código hasta dar con la validación y cambiarla, recompilando esa clase para tener una versión que ya no haga la verdadera validación, pues no hay manera de burlar eso.

Porque si lo piensas, el WAR firmado no te arregla nada, ya que de todas maneras pueden descompilar todo el código, encontrar si en alguna parte verificas la firma de las clases en el war y sobreescribir eso también. Si es una configuración en el contenedor JEE, pues se deshabilita y ya. Si usas autenticación o validación con un servidor externo en internet, de todas maneras es un if en algún lado el cual pueden anular si lo encuentran.

Tu única esperanza es esconder muy bien ese código en una clase que no esté directamente dentro de tu war, sino en alguna de las bibliotecas que utilizas (algo de Spring, Apache, Commons, etc etc). Y no olvidar dónde está porque cuando actualicen la versión de esa biblioteca hay que volver a meterle esa clase tuya.

Gracias por tu respuesta, me

Gracias por tu respuesta, me queda muy clara
Un saludo

Imagen de JRichard

No todo esta perdido

Holas.

Para decompilar un war hay mcuhas herramientas. Estas herramientas no te decompilan al 100% es decir que tienen errores que son una lagrima corregirlas ( no hablo de decompilar una clase Persona.java, hablo de decompilar todo un proyecto ).

Despues de decompilar el war o el jar , se procede a intentar correrlo para hacerle modificaciones. Aqui empieza al calvario, es decir linea a linea tratar de corregir el proyecto para que se pueda ejecutar y ver su funcionamiento para asi borrar el " if(true)" que mencionas.

Es ahi, en la lectura linea a linea que se hace las clases, donde podemos hacerle la vida imposible al individuo que quiere hacer free nuestro sistema :)

Lo que puedes hacer es ofuscar el codigo. Esto convierte tu codigo en un codigo dificl de comprender por un ser humano. Mira el ejemplo de la imagen:

ejemplo de ofuscacion

Lo que hace es cambiar el nombre de las clases, metodos, variables casi al 100%.

Por lo tanto, si aplicas lo que ezamudio menciona + la ofuscacion esta casi seguro tu codigo :) !! Claro a menos que el sistema que hagas se de defensa militar o para un banco, eso haria que fueras blanco de crackers chinos, rusos, cientificos, el mercado negro, etc. En ese caso si ni Lucius Fox de las Empresas Wayne ni Tony Stark te podrian ayudar :) !!

Saludos.