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
LVL 3
KruleAsked:
Who is Participating?
 
aozarovCommented:
A simple aproach (and not bullet proof)
Write a utility that creates a message digest from your jar. (see http://javaalmanac.com/egs/java.security/Digest.html )
Provide that message digest together with you war and on deployment create the digest again and compare it to that file.
It is not that strong as the client can generate the MD itself and replace it (though it is not as simple as modyfing your jar).

You can use the information from this link: http://java.sun.com/docs/books/tutorial/jar/sign/signing.html
to create a singed jar
and then on deployment you can run the verfication process: http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/jarsigner.html (JAR File Verification)
This process will require you to provide your clients with your public key.

0
 
objectsCommented:
Can you protect it from the OS level using file permissions?
0
 
KruleAuthor Commented:
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)
0
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

 
objectsCommented:
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.
0
 
KruleAuthor Commented:
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.xml").equals(VALIDATION_XML_MD5) )
 proceed();
else
 fail();

[/Pseudocode]

My question is: Is this plausible? And is it too easy to crack?
0
 
aozarovCommented:
>> 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 
0
 
objectsCommented:
> 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
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.