Minify .js files during Maven builds

Minifying files for use on the web is essential to improving performance, to reduce network overhead as well as a slight bump in execution speed.

Long ago I used the YUICompressor plugin for both JS as well as CSS files, unfortunately that project appears to have been abandoned many years ago and no longer functions well for JS files that make use of modern features.

For JS files, I’ve found that most capabilities can be replicated with the following in the pom.xml:

<plugin>
<groupId>com.github.blutorange</groupId>
<artifactId>closure-compiler-maven-plugin</artifactId>
<version>2.21.0</version>
<executions>
<execution>
<id>default-minify-js</id>
<phase>generate-resources</phase>
<configuration>
<!-- not supported (always uses .min) <suffix>-min</suffix> -->
<encoding>UTF-8</encoding>
<baseSourceDir>${basedir}/${webapp-folder}</baseSourceDir>
<baseTargetDir>${webapp.path}/</baseTargetDir>
<sourceDir>js</sourceDir>
<targetDir>js</targetDir>
<skipMerge>true</skipMerge>
<includes>
<include>**/*.js</include>
</includes>
<excludes>
<exclude>**/webjars-requirejs.js</exclude>
<exclude>**/bootstrap*.*</exclude>
<exclude>**/jasmine*.*</exclude>
<exclude>**/*-min.js</exclude>
<exclude>**/*.min.js</exclude>
</excludes>
</configuration>
<goals>
<goal>minify</goal>
</goals>
</execution>
</executions>
</plugin>

NOTE: the only feature I have not yet been able to match is the suffix, as it appears to always use *.min.js (where I used to prefer *-min.js).

An additional advantage of using the plugin is that many common syntax errors will be identified at build time, before they cause user problems… but they will also break your build!

REFERENCES:

Minify .css files during Maven builds

Minifying files for use on the web is essential to improving performance, to reduce network overhead as well as a slight bump in execution speed.

Long ago I used the YUICompressor plugin for both JS as well as CSS files, unfortunately that project appears to have been abandoned many years ago but is still effective for CSS even if it is less useful for modern JS.

NOTE: default extension uses -min, to change it set property ‘maven.yuicompressor.suffix’ to the desired value, such as .min to match GCC used for JS.

For CSS files, you can use following in the pom.xml (JS is also possible if you are not using ES6 features):

<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.5.1</version>
<executions>
<execution>
<id>compressyui-min</id>
<phase>prepare-package</phase>
<goals>
<goal>jslint</goal>
<goal>compress</goal>
</goals>
</execution>
</executions>
<configuration>
<nosuffix>false</nosuffix><!-- false will create -min versions, true does not -->
<warSourceDirectory>${basedir}/${webapp-folder}</warSourceDirectory>
<webappDirectory>${webapp.path}/</webappDirectory>
<jswarn>false</jswarn>
<gzip>false</gzip><!-- create .min.gz files -->
<nocompress>false</nocompress>
<force>true</force>
<excludes>
<exclude>**/*.js</exclude><!-- YUI cannot handle ES6 const let, use closure-compiler instead -->
<exclude>${webjars-output.path}*.*</exclude>
<exclude>**/webjars-requirejs.js</exclude>
<exclude>**/bootstrap*.*</exclude>
<exclude>**/jasmine*.*</exclude>
<exclude>**/*-min.css</exclude>
<exclude>**/*.min.css</exclude>
</excludes>
</configuration>
</plugin>

REFERENCES:

Force cleaning of workspace during automated Maven builds

I’ve been using Maven for years, but once in a while forget to ‘clean‘ before building, resulting in old artifacts being included in the output. This can be problematic when refactoring for security items. Thankfully, it is very easy to add a ‘clean‘ step to your pom.xml to force clean each build.

BONUS – the plugin has some additional capabilities, specifically you can specify files outside of ‘target’ to be removed. This can be useful for any custom reporting or logging that you might create.

The Maven clean plug-in can be added to the pom.xml as such:

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-clean-plugin</artifactId>
<version>${maven-clean-plugin.version}</version>
<executions>
<execution>
<id>auto-clean</id>
<phase>initialize</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>

REFERENCES:

Sonatype Nexus2 Repository Manager OSS

To allow for repeatable, faster builds in a continuous build environment, it’s often a good idea to use a central repository to cache common assets and prevent the need to download assets from the internet for each build. Using Nexus allows for those transfers to occur over your local network for previously downloaded assets.

You can download the WAR from:
http://www.sonatype.org/downloads/nexus-latest.war

And install on your Java application server, such as Apache Tomcat, via normal means.

If you are using Maven, you’ll need to make appropriate changes in (/.m2/settings.xml) to direct your builds to use Nexus.

Jenkins and other build automation tools will require similar changes.

REFERENCES:

Selenium HtmlUnit driver separated in 2.53.0

I’ve been a user of Selenium testing for several years, though I noticed that some classes related to the HtmlUnit WebDriver were missing after upgrading from 2.52.0 to 2.53.0. After some research, I discovered that it is now a separate dependency allowing for a separate release cycle. Additionally, if you don’t use this (relatively generic) webdriver, you will no longer need to have it in your binaries.

Here’s all you need to do to add it to your Maven projects for testing.

In your pom.xml file:

<properties>
<selenium.version>2.53.0</selenium.version>
<htmlunitdriver.version>2.20</htmlunitdriver.version>
</properties>
<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>htmlunit-driver</artifactId>
<version>${htmlunitdriver.version}</version>
<scope>test</scope>
</dependency>
</dependencies>

REFERENCES:

Java Dependency Vulnerability scanning with Maven victims-enforcer

One of the OWASP guidelines for secure applications is to not use components with known vulnerabilities. Unfortunately it can be a very difficult and time consuming task to keep up with these manually, automation can save you countless hours!

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

NOTE: victims-enforcer can be used in conjunction with the OWASP dependency scanner. I have only found it to be problematic in ‘tycho’ builds.


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<dependencies>
<dependency>
<groupId>com.redhat.victims</groupId>
<artifactId>enforce-victims-rule</artifactId>
<version>1.3.4</version>
<type>jar</type>
</dependency>
</dependencies>
<executions>
<execution>
<id>enforce-victims-rule</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<rule implementation="com.redhat.victims.VictimsRule">
<!--
Check the project's dependencies against the database using
name and version. The default mode for this is 'warning'.

Valid options are:

disabled: Rule is still run but only INFO level messages and no errors.
warning : Rule will spit out a warning message but doesn't result in a failure.
fatal : Rule will spit out an error message and fail the build.
-->
<metadata>warning</metadata>

<!--
Check the project's dependencies against the database using
the SHA-512 checksum of the artifact. The default is fatal.

Valid options are:

disabled: Rule is still run but only INFO level messages and no errors.
warning : Rule will spit out a warning message but doesn't result in a failure.
fatal : Rule will spit out an error message and fail the build.
-->
<fingerprint>fatal</fingerprint>

<!--
Disables the synchronization mechanism. By default the rule will
attempt to update the database for each build.

Valid options are:

auto : Automatically update the database entries on each build.
daily : Update the database entries once per day.
weekly: Update the database entries once per week.
offline : Disable the synchronization mechanism.
-->
<updates>daily</updates><!-- was: auto -->

</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>

Vulnerability database is sourced from: https://victi.ms with backing from RedHat.

REFERENCES:

OWASP Dependency Vulnerability Scanning of Java JARs with Maven

One of the OWASP guidelines for secure applications is to not use components with known vulnerabilities. Unfortunately it can be a very difficult and time consuming task to keep up with these manually, automation can save you countless hours!

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

NOTE: OWASP dependency scanner can be used in conjunction with the victims-enforcer.

Add to your projects pom.xml:

<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>1.3.4</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

Each time you build, the plug-in will verify the assets against the list of known vulnerable libraries and report them in your output.

Vulnerability database is populated from: https://nvd.nist.gov.

NOTES:

  1. The example above is a very simple implementation, see the documentation for additional functions.
  2. The first use of the plug-in can take a long time as the vulnerability library must be installed locally before initial use.
  3. Similar functionality is available for Ant builds, if desired.

REFERENCES:

RetireJS javascript libary vulnerability scanning with Maven

It’s important to note that even though your site is using a vulnerable library, that does not necessarily mean your site is vulnerable. It depends on whether and how your site exercises
the vulnerable code. That said, it’s better to be safe than sorry.

I identified this method of using the asset after reading the instructions for the Burp/Gulp scanner from h3xstream after the following section caught my eye:
https://github.com/h3xstream/burp-retire-js#maven-plugin-, it contained a small reference to Maven and even showed output but no configuration for use. A couple of attempts later I came up with the following:

Add to pom.xml:

<build>
<plugins>
<plugin>
<groupId>com.h3xstream.retirejs</groupId>
<artifactId>retirejs-maven-plugin</artifactId>
<version>2.1.0</version>
<executions>
<execution>
<id>scanProjectJavascript</id>
<phase>install</phase>
<goals>
<goal>scan</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

After adding this to your pom.xml, the console output for each build will contain information regarding each vulnerable JavaScript library.

One small problem exists in the current version, use behind corporate firewalls can often be blocked, resulting in an error in the console and use of an older version of the vulnerability library to be used in scans.

Error example:

[ERROR] Exception while loading the repository (Most likely unable to access the internet) java.net.UnknownHostException: raw.githubusercontent.com

See the following for updates:
https://github.com/h3xstream/burp-retire-js/issues/8

See https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities.

REFERENCES:

Code signing of java applets – using Maven

To sign your java assets during the maven build process, you can add the following to the pom.xml to make use of the values we established in the keystore creation step.

WARNING: for security and maintainability purposes, you should define the ‘configuration’ items in your local ‘settings.xml’ file instead of in the pom.xml as is done here for example only!


<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jarsigner-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>sign</id>
<goals>
<goal>sign</goal>
</goals>
</execution>
<execution>
<id>verify</id>
<goals>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<alias>selfsigned</alias><!-- ${project.name} -->
<keystore>selfsignkeys.store</keystore><!-- NOTE: you can also specify an absolute path here -->
<storepass>123456</storepass>
<keypass>123456</keypass>
</configuration>
</plugin>

REFERENCES:

Code signing of java assets – creating a keystore

This is generally done via the command line, though I’ve seen it done with Ant in some cases. Here are the specifics… you’ll want to change the passwords and likely take a look at the algorithm (RSA for this example and validity (365 days in this example) for your actual use.

Background, in order to sign your java assets, you will first need to generate a key. You can later get this verified by a CA (Certifying Authority) as needed, this example is selfsigned.

NOTE: I’ll use these example values in the Maven and Ant signing code examples to follow.


keytool -genkey -keyalg RSA -alias selfsigned -keystore selfsignkeys.store -storepass 123456 -keypass 123456 -validity 365

REFERENCES: