Securing WAR (Jar) Files In Web Application
I've been looking for a way to lock down a web application that I have to distribute to various clients in the form of a WAR fire (jar file with a different extension).
This application makes use of xml files for settings, (It's Struts based, so the struts-config.xml, and validation.xml..etc), however my employer is inhibiting the distribution of the software because a potential client can extract the xml files and make a change to render our validation (as well as other things) worthless.
He therefore wants me to find a way to secure the WAR file so that it will not function if it has been tampered with.
My research has brought me to what people call 'Signed Jar Files' and 'SecurityManagers' however how the concepts work practically are not described anywhere, and I am therefore asking if someone can show me how I may make use of these signed jar files, and a security manager in my web application.
I'd like, if possible, to do this all within the contained war file, without any 'policy' files if that is possible, or at the very least, with as few additional files / changes outside of the war file as possible.
Thanks
This application makes use of xml files for settings, (It's Struts based, so the struts-config.xml, and validation.xml..etc), however my employer is inhibiting the distribution of the software because a potential client can extract the xml files and make a change to render our validation (as well as other things) worthless.
He therefore wants me to find a way to secure the WAR file so that it will not function if it has been tampered with.
My research has brought me to what people call 'Signed Jar Files' and 'SecurityManagers' however how the concepts work practically are not described anywhere, and I am therefore asking if someone can show me how I may make use of these signed jar files, and a security manager in my web application.
I'd like, if possible, to do this all within the contained war file, without any 'policy' files if that is possible, or at the very least, with as few additional files / changes outside of the war file as possible.
Thanks
Mick Barry
Can you protect it from the OS level using file permissions?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OS level file protection is out of the question. This will be distributed to various people on multiple OS
What i'm looking for is a way to, via the code, Test a jar file to make sure it has not been tampered with
Here's what I'm thinking right. I could calculate the Md5 hash on the .xml files, then in the code (somehow) test to see if I get the same hash before I begin my web app (in a servlet that is called once or something...nothing heavy here)
What i'm looking for is a way to, via the code, Test a jar file to make sure it has not been tampered with
Here's what I'm thinking right. I could calculate the Md5 hash on the .xml files, then in the code (somehow) test to see if I get the same hash before I begin my web app (in a servlet that is called once or something...nothing heavy here)
really depends on the level of skill and amount of effort they want to put into cracking it. All security is crackable, its just a matter of deciding on a level of security that is acceptable.
ASKER
For the spec that I was given we assume they will not be editing the .class files since they are compiled and obfuscated (Even though it is possible to reverse engineer a class file, we assume they will not)
The security only needs to ensure that the xml files have not been altered. So I believe (correct me if I'm wrong) that if we were to get an MD5 hash on the xml files (each individually) and then test if the hash is the same in a Servlet (At runtime) using something like this
[Pseudocode]
if( md5.encrypt("validation.xm
proceed();
else
fail();
[/Pseudocode]
My question is: Is this plausible? And is it too easy to crack?
The security only needs to ensure that the xml files have not been altered. So I believe (correct me if I'm wrong) that if we were to get an MD5 hash on the xml files (each individually) and then test if the hash is the same in a Servlet (At runtime) using something like this
[Pseudocode]
if( md5.encrypt("validation.xm
proceed();
else
fail();
[/Pseudocode]
My question is: Is this plausible? And is it too easy to crack?
>> I could calculate the Md5 hash on the .xml files, then in the code (somehow)
Did you see my above link -> http://javaalmanac.com/egs/java.security/Digest.html (shows how create MD5 on some byte[] content).
>> Is this plausible? And is it too easy to crack?
It is far more complex then just tampering with the xml file.
It will require applying the md5 on that file using the password stored in your Class file {need to decompile this file} then change your class file with the new signature {need to recompile it again}. So for this kind of need I personally think it should be sufficient (though it is definitely not bullet proof).
Adding to the contract with your clients a non-reverse engineering clause would help as well 
Did you see my above link -> http://javaalmanac.com/egs/java.security/Digest.html (shows how create MD5 on some byte[] content).
>> Is this plausible? And is it too easy to crack?
It is far more complex then just tampering with the xml file.
It will require applying the md5 on that file using the password stored in your Class file {need to decompile this file} then change your class file with the new signature {need to recompile it again}. So for this kind of need I personally think it should be sufficient (though it is definitely not bullet proof).
Adding to the contract with your clients a non-reverse engineering clause would help as well 
> My question is: Is this plausible? And is it too easy to crack?
If you're assuming they cannot alter class files then you should be safe
If you're assuming they cannot alter class files then you should be safe