How to protect WAR file from tampering?

I’m thinking of some property to be added in build.gradle such that I get a WAR file with read-only privilege when I build my gradle project. I would recommend this to be considered to protect the project files if there aren’t any ways to make a read-only WAR file.

Note: Read-only privilege to WAR file meaning all files inside it must not be allowed for modify.

I have tried the below snippet and this doesn’t helped me protecting the WAR file.

war {
    from("$buildDir/libs") {
        fileMode = 0444
    }
}

Could someone tell me what has to be done to add access privilege when running gradle build, please?

Hi again,

I’m not sure what you mean by “read only privileges when I run the build”. The war task you describe would generate a war. Do you want to generate a war file which has read only flags? In which case it has nothing to do with the dependency cache.

Hi,

I am not sure what you are trying to achieve here.
My current understanding is that you want to make sure no one tampers your WAR after it is produced. The only way to do that in a really safe way is to sign it, certainly not a permission based solution.

If I misunderstood your point, could you please elaborate?

@CedricChampeau @ljacomet Thanks for getting back to me.

Yes, this is what I’m trying to achieve here.

I don’t want anyone to make changes to my WAR file but this is not the case now. Say for example, I tried to amend a properties files using Notepad++ after opening the WAR file with WinRAR and I could able to save the changes. This is a serious issue in terms of security.

@ljacomet I could try above. Could you tell me how to and where to do this?

The only thing signing an artifact will give you, is a Yes or No answer to the question: „Has the artifact been tampered with?“.

Signing will not prevent tampering from occurring. It will only let you know whether or not tampering has occurred.

Every jar that Gradle or Maven or Ivy downloads from a remote public repository has been signed. Signing is mandatory to publish a jar to Maven Central, for example.

Even so, I can still open that jar once it is on my own machine. I can remove stuff from it; add stuff to it; and replace what’s in it with something else of my own. Even though it was signed by the original author when they published it.

Hello @lingocoder I understood as currently it is not possible to make the producing WAR file as non editable when running Gradle Tasks -> Build. Are there any plan to do this in the near future? This is a requirement for our project and I believe this will be more widely useful for Gradle project developers.

I couldn’t tell you because I don’t work for Gradle.

I doubt Gradle will ever add it. I don’t think it’s something that’s requested a lot.

There might be some other third-party tool out there that does what you need. Maybe you could wrap the required capability in a custom plugin of your own.

I know you mentioned your project is concerned about security. But can you tell us what is the specific reason your project needs the war to be uneditable?

It is impossible to make a read only zip, jar, war, or any other archive. Why? because all a person need do to ‘modify’ it is to extract the contents, make their modifications, then create a new archive with the same name.
The best and only things you can do are hashing and/or signing the archive (using the Signing plugin), and then verifying the hash or signature at time of use.

@ashton Thanks for your response. Could you explain or suggest a reference site to implement the above suggested solution as I couldn’t find a working solution after doing serious of searches in the internet?

Here is my working environment and I’m looking for a best suitable working solution.

  1. Web services created using Gradle project with resource files such as .java, .properties, and .xml files.
  2. Gradle build automation creates a WAR file.
  3. My web server is Jetty and I will deploy the WAR file into this to host the services to my client.

My intention is to add authentication to the WAR file deployed in my web server to prevent from tampering.

Thanks in advance!