Free web application vulnerability scanner for Eclipse

Contrast released Contrast for Eclipse 1.0 already a little while ago. The Eclipse plug-in works as a runtime security scanner and checks for security vulnerabilities in your web application while executing it in Eclipse. Promised by Contrast on Eclipse Marketplace is an Automated detection of OWASP Top 10 vulnerabilities.

This is the first free tool available that explicitly scans for security vulnerabilities. Other tools like FindBugs or PMD may find some security problems as well, but are focussed on bugs and bad practices.

Running the Contrast test is easy: Instead of running or debugging your web application you simply launch your configured web server with Contrast in the Servers view:

Contrast in Eclipse Server view

The scanner detects possible vulnerabilities while you are using the web application (a.k.a. at runtime) and points to the source code line causing the vulnerability, extended with helpful information about the vulnerability and additional links.

I’ve used some of my intentionally vulnerable web applications in the JavaSecurity and Java-Web-Security repositories as test environment. These are some of the results I received while using the XSS sample application:

Contrast view with findings

The findings are all correct, but the important one is missing: The XSS vulnerability. So while Contrast tells me that no Anti-Caching response headers are in place and that my forms use auto-completion (both warnings are absolutely correct), it has missed the successful XSS attack that ended in the following dialog visible in my browser:

XSS popup in the browser


Next stop, CSRF: Same findings (cache and auto-complete), no CSRF warning.

Final stop, SQL Injection: Same findings (cache and auto-complete), no SQL Injection warning.

XSS, CSRF and SQL Injection are – in my eyes – still some of the nastier problems we are facing in web applications (among others). And they have been a part of the OWASP Top 10 forever.

Countercheck with FindBugs (and manually enabled security and malicious code vulnerability checks): got several warnings on reflected cross-site scripting and SQL Injection vulnerabilities.

So, use the Contrast plug-in or not? Well, use it from time to time, it still might discover some vulnerabilities in your web application. But don’t expect too much and definitively extend it with regular FindBugs scans. Still a long way to go with open source security scanner.

Remove Checkstyle warnings for certain classes

Checkstyle warnings for generated or automatically filled classes like in Eclipse RCP can be annoying. But even without the .checkstyle file under version control, it is possible to deactivate Checkstyle warnings for selected files.

First you have to add the SuppressionFilter module to your Checkstyle configuration file:

<module name="SuppressionFilter">
 <property name="file" value="${samedir}suppressions.xml"/>

The path entered to suppressions.xml must be absolute, ${samedir} takes care of that.

The suppressions.xml file contains a simple list of suppress elements, where a . as checks-attribute property represents all checks (the attribute value is a regular expression). The other possibility is to deactivate only selected checks by inserting a module name as configured in the Checkstyle configuration.

<?xml version="1.0"?>
<!DOCTYPE suppressions PUBLIC "-//Puppy Crawl//DTD Suppressions 1.1//EN" "">
 <suppress checks="." files=""/>

Eclipse RCP export failure

Even though the JCrypTool runtime in Eclipse is working perfectly fine, exporting the product via the Product Configuration Editor fails on OS X 10.8.2 with Java 1.7.0_09 (the same happened with 1.7.0_07). Every export crashes after 2 percent with the following exception:

/[…]/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/[…]/build.xml:31: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/Classes does not exist.
The following error occurred while executing this line:
/[…]/build.xml:31: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/Classes does not exist.

I‘ve already re-installed Eclipse 4.2.1 Classic, tried Eclipse 4.2.1 for RCP Developers, deleted the workspace, cleaned projects, everything that came into my mind. No success. Any ideas?

Alphabetically sorting Eclipse RCP help pages and custom bookmark titles

Extending the Eclipse help in a RCP is easy. However, there seem to be some hidden features as we have lately discovered for JCrypTool. Since JCrypTool is heavily based on crypto plug-ins which do extend our platform, we do include lots of other plug-ins via anchors in the online help:

<topic label="Signatures" href="toc.html" sort="true">
  <anchor id="signaturePlugins" />

sort=”true” does the magic here and sorts all plug-ins extending this anchor alphabetically.

The other latest change was the title element for each html head. Even though the title entered here is not visible, it is used for the bookmark title a user can create for each page. Adding it is strongly recommended, otherwise the pages’ path will be used.

Apache XML Security 1.5.0 released

Apache Santuario 1.5.0 has been released. As the release notes point out, this release is not binary compatible with Santuario 1.4 any more.

There are some really good updates included, of which I like that Xalan/Xerces are not required dependencies any more the most. Under the covers, support for Java 1.4 was dropped, and generics are used where possible.

The binary incompatibility will require some changes and tests until this version will be available with the JCrypTool XML Security plug-in.

XML Security Tools in danger

Yes, the XML Security Tools are really in danger. Those of you following the improvement of the project didn‘t see much lately. Not that I'm not interested in Eclipse or XML Security any more. But my free time is very limited and I desperately need a co-developer supporting me and the project.

As a first step, I have integrated the XML Security Tools into JCrypTool, and moved the adapted code into our Crypto GitHub repository. The XML Security Tools are located in the org.jcryptool.crypto.xml projects there. This code differs from the code at to match the JCrypTool requirements and extension points. Integration is by far not complete, and the code needs some love – feel free to contact me and join the JCrypTool project.

On Eclipse side, Dave Carver will be separating the XML Security Tools code into a separate Git repository. If no one steps up, the code will be archived there.

EGit 1.1 pushes only the active branch by default

As it turns out, there is already a fix in EGit 1.1 for the unexpected EGit behavior I described here and here.

The new default for EGit 1.1 is to only push the active branch via Push to Upstream in case there is no explicit default spec. More is not possible at the moment due to some JGit protocol limitations. I can totally live with that, at least there are no surprises with local branches appearing in the remote repository silently any more.

EGit pushes all local branches when no explicit RefSpec is found – Update

As it turns out, some parts of yesterdays' post are not correct: The description of the behavior I expect was OK, but EGit behavior is not correct at all. Have a close look at the Git push spec and the sentence in bold:

The special refspec : (or +: to allow non-fast-forward updates) directs git to push “matching” branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side. This is the default operation mode if no explicit refspec is found (that is neither on the command line nor in any Push line of the corresponding remotes file—see below).

And EGit does the exact opposite of that! Every local branch is pushed, no matter it exists in the remote repository or not. Thanks to Carsten Reckord, who pointed that out in my post in the Eclipse Community Forums. I'm waiting on another reply to my post, after that I'll file a bug.