RetireJS for Eclipse extension

Several years ago I wrote an Eclipse plugin to help me identify vulnerable javascript libraries using RetireJS. On a whim, I finally got around to submitting it to the Eclipse marketplace last week and it was approved.

This addresses a common OWASP Top-Ten item – A9:2017-Using Components with Known Vulnerabilities.

For Non-Developers… in English, while software developers are creating websites they often use open-source libraries such as jQuery (or literally thousands of other libraries) to simplify their development. Eventually, almost all software is identified as being vulnerable to various attacks. This tool makes it easier to scan and report on libraries that might be used in an application so that they can be updated or replaced.

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:

Adding TestNG support to Eclipse

Most Java developers are familiar with the Eclipse IDE, even if they use alternatives.

One thing that’s bothered me for some time is that while JUnit is natively supported in Eclipse, TestNG is not. Thankfully, you can easily add this functionality.

  1. Help; Eclipse MarketPlace;
  2. Find – enter: testng
  3. Click on "TestNG for Eclipse" and install by stepping through the prompts.
  4. Restart of Eclipse is required to enable the new functionality.

Eclipse FileSync plugin

I’ve done a lot of front-end java coding over my career,  one particularly annoying aspect is the wait for a build (compile-deploy) cycle in my local developement servers to view or test a small change.  One particularly useful tool that I’ve been using for some time is a FileSync plugin for Eclipse.  It is useful as you can “map” folders from your Eclipse project to a path on your local filesystem, as such the individual files are automatically copied to your server installation.  I’ve personally used this approache with JBoss, Tomcat and WebSphere, but there is no reason that it should not work for other servers.

DTD for logback.xml in Eclipse

After fixing the validation error in my Ant build.xml files, I got to wondering about the other common XML files in my projects. I’ve used Logback on many of my recent projects and it’s configuration has similar warnings that can be resolved in the same manner.

The simplest method to silence the warning is to add a DOCTYPE to the logback.xml files, between the XML declaration and the configuration. Official documentation seems to indicate that a DTD is not possible or likely.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration>
<configuration>

NOTE: For what it’s worth, this approach should work for any XML file to remove the error in Eclipse.

REFERENCES:

DTD for Ant build.xml in Eclipse

I’ve seen this validation error in Eclipse for a few releases and finally got tired enough of seeing it that I did some research.

The simplest method to silence the warning is to add a DOCTYPE to the build.xml files, between the XML declaration and the project, there are a few more complicated methods, but this one works well for the cases I’ve experienced.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project>
<project name="Example"...>

REFERENCES:

Add SonarQube Analysis to Eclipse

If you have already embraced Continuous Inspection with Sonar/SonarQube, you may find it advantageous to do analysis of new or modified code within the IDE without having to wait for a new build/compile/analyze cycle. Additionally, it’s often faster to keep all of your required information within the IDE without having to also open a web browser.

You can easily add this capability:

  1. Help > Install New Software… > Add… > then enter:
  2. http://dist.sonar-ide.codehaus.org/eclipse/
  3. Restart Eclipse
  4. RightClick on project – Configure > Associate with SonarQube > chose project

REFERENCES:

Eclipse compiler error when using sun.misc.Base64Encoder reference

I’ve recently been doing some work with code that is still running in a Java5 environment, to make matters worse, no new libraries can be added to the application. With these restrictions, I’ve had to resort to using only functions available in the standard installed JVM. The code relies on HTTP Basic authentication, and thus needs to use Base64 encoding.

The following classes were to be used…

import sun.misc.BASE64Encoder;
import sun.misc.BASE64Decoder;

Unfortunately, Eclipse did not like this and gave an error…

Access restriction: The type BASE64Decoder is not accessible due to restriction on required library C:\jdk1.5.0_22\jre\lib\rt.jar

Thankfully, this class (while not recommended, is in every build of the JVM that I have seen), you can tell Eclipse to only ‘Warning’ on it’s usage…

Window -> Preferences -> Java -> Compiler -> Error/Warnings.
Select Deprecated and Restricted API. Change it to warning.
Change Forbidden and Discouraged Reference and change it to Warning, or as needed.

BTW, I would normally rely on the commons-codec.jar for this functionality, and use org.apache.commons.codec.binary.Base64 for this purpose.

REFERENCES:

Enerjy plugin for Eclipse IDE

I’ve previously written on the benefits of static analysis of java code with the use of PMD and FindBugs.  I was recently turned on to a new tool that performs similar testing of code within the Eclipse IDE.

When I first found this tool it was free, since that time it’s come out of beta and is now a little costly, but it may still be worth it due to the functionality it provides.

The premise of this tool is a little different than other ones, while it covers much of the same need, it also performs many tests that I would previously use CheckStyle to do.  This only provides them at runtime and in a common manner within the IDE.

REFERENCES:

Cheers! 

Eclipse ResourceBundle Editor

I typically use the open-source Eclipse IDE for most of my Java and PHP work. For my corporate work, this means that I use IBM‘s packaged RAD and WSAD offerings that are based on various versions of the Eclipse framework.

When working on Internationalized (I18n) applications, most experienced Java architects rely on ResourceBundles to store the various text that is needed for different languages, problem is that editing these files becomes problematic, especially when dealing with multi-byte character sets as are often used in Unicode (non Latin-1, aka ISO-8859-1) languages.

The best editor I’ve found for this case is, as you may have guessed, free for download.

Here’s the links:

Cheers!