Gradle dependency versions plugin

Developers often have a lot on their plates, maintaining current version of their library dependencies often takes a back seat to deliverables. Far too often, the only time a library is updated is when it becomes a problem, either as a vulnerability or as a headache that prevents other updates. Monitoring repositories and email lists can also be problematic.

To simplify some of the manual effort that often goes into this, use of build plugins can help. With them, each build, either on the developer desktop or as part of a CI (Continuous Integration) pipeline, can provide feedback to any developer that looks at the output.

Adding to a Gradle project only takes a few small changes:

In build.gradle:

plugins {
  id 'com.github.ben-manes.versions' version '0.51.0'
}

Then to invoke you can use:

./gradlew dependencyUpdates

To simplify for use with make, add to an existing step like ‘test’ in a Makefile like:

.PHONY: test
test: clean
  ./gradlew test dependencyUpdates

 

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:

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:

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:

Firefox 41+ extension signing

In the never-ending quest for browser security, Firefox has started implementing safeguards to only allow signed extensions. I found this out after upgrading to Firefox 41 as my installed version of “Deque FireEyes” stopped working. Thankfully, there is a workaround in Firefox 41, but it goes away in Firefox 42.

  • Firefox 40: warning only!
  • Firefox 41: workaround, via:

    about:config:
    xpinstall.signatures.required = false
  • Firefox 42: BLOCKED! unless signed

REFERENCES:

Deque FireEyes accessibility testing plugin

I’ve done a lot of accessibility testing and development work over my career. One of the many free tools that I use in that role is FireEyes. Deque also has some commercial packages for developer use.

FireEyes adds a new tab on the Firebug tab bar and adds the ability to analyze a web site for WCAG 2.0 Level A and AA and Section 508 accessibility violations. The Stand-Alone version of FireEyes is a browser plugin to the FireFox browser. It requires that the FireBug plugin already be installed

Requirements:

  • Firefox 31-41

    As of 2015aug21, the current version of the extension is NOT signed and will not execute on later versions. [See my later post on this topic]

  • FireBug 2.x – Do NOT install Firebug v3 alpha as the tab will not show.

NOTE: should be on Firebug tab labeled “Worldspace Fireyes”, but does not seem to be available in Firebug3.

NOTE: if you try to download in MSIE, you must rename the .zip to .xpi, and then open with Firefox.

REFERENCES:

Adding meta “viewport” for WordPress

Google recently changed their search algoritms to better recognize and weight “Mobile” support. This term is loosely defined in general, but to get your Google search “juice” you simply need to add a “viewport” meta tag. Unfortunately, unless you have the knowledge and want to edit your WordPress theme manually, there’s not an obvious way to add this.

Adding the “Definitely Allow Mobile Zooming” plugin makes this painless in WordPress without any additional configuration.

HTML code required (in <head>):

<meta name="viewport" content="width=device-width" />

PHP required (for manual addition):

<?php
function set_viewport() {
?>
<meta name="viewport" content="width=device-width" />
<?php
}
add_action('wp_head', 'set_viewport');
?>

REFERENCES:

Selenium Firefox modifyheaders

A few of my tests require access to modify the HTTP Request headers. Unfortunately, Selenium hides access to them to allow for portability, and to better emulate what “users” generally can change. To work around this a Firefox extension can be used and configured at runtime for this purpose.

NOTE: for Maven, you need to place a copy of the .xpi file referenced into the /src/test/resources folder for Selenium to locate it.

In the example below, I’m setting the HTTP Header for “DNT” to “1”.

public FirefoxDriver createFirefoxDriver() throws URISyntaxException, IOException {
// Specify the install location (if not default)
System.setProperty("webdriver.firefox.bin","C:\\path\\to\\Firefox.exe");
// Prevent Console log "noise" from the Selenium Firefox plugin
System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.SimpleLog");
System.setProperty("org.apache.commons.logging.simplelog.log.httpclient.wire", "OFF");
System.setProperty("org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient", "OFF");

final FirefoxProfile profile = new FirefoxProfile();
final URL url = this.getClass().getResource("/modify_headers-0.7.1.1-fx.xpi");
final File modifyHeaders = modifyHeaders = new File(url.toURI());

profile.setEnableNativeEvents(false);
profile.addExtension(modifyHeaders);

profile.setPreference("modifyheaders.headers.count", 1);
profile.setPreference("modifyheaders.headers.action0", "Add");
profile.setPreference("modifyheaders.headers.name0", "DNT");
profile.setPreference("modifyheaders.headers.value0", "1");
profile.setPreference("modifyheaders.headers.enabled0", true);
profile.setPreference("modifyheaders.config.active", true);
profile.setPreference("modifyheaders.config.alwaysOn", true);

final DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setBrowserName("firefox");
capabilities.setPlatform(org.openqa.selenium.Platform.ANY);
capabilities.setCapability(FirefoxDriver.PROFILE, profile);
return new FirefoxDriver(capabilities);
}

Maven build script for replacement of text in web.xml (and others)

Automated replacement of BUILD_LABEL token in web.xml <description> with Maven. For JAR’s the replacement is commented out, but can be any file.

NOTE: This proves to be rather difficult to do because of the way that Maven copies resources as it’s building the WAR. The most reliable manner I’ve found (so far) is below, it works by making a .tmp copy of the web.xml in a different path and then later uses it in the WAR.


<plugins>
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.3</version>
<configuration>
<quiet>false</quiet>
</configuration>
<executions>
<execution>
<id>replaceBuildLabel</id>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
<configuration>
<file>${basedir}/src/main/webapp/WEB-INF/web.xml</file>
<outputFile>${project.build.directory}/web.xml.tmp</outputFile>
<replacements>
<replacement>
<token>BUILD_LABEL</token>
<value>Maven-${maven.build.timestamp}</value>
</replacement>
</replacements>
<regex>false</regex>
<quiet>false</quiet>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.5</version>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
<webXml>${project.build.directory}/web.xml.tmp</webXml>
<archive>
<manifest>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
<manifestEntries>
<url>${project.url}</url>
<Build-Label>${maven.build.timestamp}</Build-Label>
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>

Most importantly, you will want to have this token in the web.xml file for replacement, the description line is best used for this as such:

<description>ExampleWAR [BUILD_LABEL]</description>

during the build, that value would be replaced to something like:

<description>ExampleWAR [Maven-20141015-1700]</description>

REFERENCES: