contrast security plugin for eclipse

I recently learned that Contrast Security has a free plugin that tests your application against the OWASP Top 10.  We’ve tried to fix these already. You can read about how we fixed Clickjacking, CSRF and XSS in JForum.

Installing

I started out by installing the Contrast plugin from the Eclipse Marketplace. After restarting Eclipse, a Contrast view automatically opens with instructions. It says to right click your server and choose “Start with Contrast.” Easy enough. I usually use Sysdeo so I can start the server in one click, but this is hardly onerous.

A Diversion: Fixing Tomcat Configuration

I got an error on startup. I then tried to start the server using the server view (without Contrast) and got the same NoSuchMethodError:

java.lang.NoSuchMethodError: sun.security.ec.NamedCurve.<init>(Ljava/lang/String;Ljava/lang/String;Ljava/security/spec/EllipticCurve;Ljava/security/spec/ECPoint;Ljava/math/BigInteger;I)V

I fixed this by switching Tomcat 7 to use Java 7 instead of Java 8. (We aren’t using Java 8 yet for CodeRanch’s JForum software so this is fine.)

  • Workspace preference
  • Server
  • Runtime Environments
  • Click Tomcat and edit
  • Choose Java 7 as JRE

This had nothing to do with Contrast. I hadn’t encountered it because I was using Sysdeo to start Tomcat before this.

Actually testing

Now that the server starts up, I stopped it and restarted with Contrast. Then I clicked around the app a bit. (You can use Selenium tests or any other testing tool to automate this part.) The Contrast view starts to populate with its findings. I clicked around until I had about a dozen findings. They were:

Category Issue # Instances Details My analysis
Orange Insecure hash algorithms in XXX 3 Provides an explanation of what the problem is, why it might/might not be a problem along with the stack trace (showing how it is used) and the HTTP request/headers for the request(s) that triggered it. Two of the three findings refer to the exact same line of code. (Which was run on two different screens). The other appears to be in Tomcat itself. My configuration isn’t the same as the real server here. [The other two I need to look into further]
Yellow Anti-Caching Controls Missing in XXXX 6 Provides the HTTP request/headers, suggested remediation It’s annoying to have this reported on every page. Glad there is an :ignore this rule” option. We run a public website and want things to be cached. Client side caching makes the site faster for users and doesn’t leak information since 90% of our information is public to begin with. The only risk is if a moderator access the private forum on a public computer. We are technical users and know to clear data if this happens.
Yellow Forms without autocomplete prevention 3 Provides the HTTP request/headers, suggested remediation Again, we are a public site so not a big deal for browsers to retain information.
Warning CVE(s) in commons-httpclient-3-1.jar 1 Provides links to the two CVEs along with the manifest of the vulnerable library. I knew this from running Sonatype CLM Insight. The two CVEs are in functionality in the library that we don’t use. Still it is sweet to have this information available for free and with almost no effort. (Insight is a commercial project. We saw a one time result from the report.) I was concerned that information about the jars was being sent over the internet so I asked on Twitter. Jeff Williams replied that the CVE information is in a built in database updated via Eclipse Marketplace. Neat!

What to do with the results

When right clicking on any finding, you have four options:

  • Mark Resolved
  • Delete
  • Ignore (this instance) – useful for a false positive
  • Ignore rule – useful for a rule that doesn’t apply

My thoughts on the Contrast plugin

  • I like that the stack trace is included because it is easy to see context. I also like that lines belonging to the app is in blue in the stack trace.
  • It was very easy to use. And free. Which makes using it a no brainer.
  • While there aren’t false positives from unused code, there are false positives from context (which a tool can’t know).
  • Two of the rules triggered on a number of pages. (and would have triggered on a lot if I tested more)
  • While I don’t have a long list of things to follow up, it was a good thought exercise. And the reason I don’t have a long list is because we manually went through the OWASP top 10 in preparation for the “Iron Clad Java” promo recently. (so as not to have embarrassing issues pointed out)

Progress on the OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide

book-pdf

In September, Scott and I announced we were writing a book for the OCA (Java 8) exam. Just over a month later, the book cover is up on Amazon along with the estimated publish date of December 31, 2014. I assume this means early January as I find it hard to believe anything happens at a large company during Christmas/New Year’s Week.

It’s great to see progress though. The book is now starting the technical proofreading stage. Yesterday, our tech proofer showed us what the PDF or some of the chapters looks like. it was really cool seeing the jump from a (heavily edited and iterative) Word document to a sharp looking PDF. It’s also exciting seeing something we wrote in near final form.

OWASP A9 – Using Insight/CLM for CodeRanch

This week at CodeRanch we have a promotion for Iron Clad Java. Before the promo, I wanted to make sure we didn’t have anything embarrassing going on. We had already dealt with XSSCSRF, Clickjacking and brute force logins. As I looked through the OWASP Top 10, I realized that I had no idea how we were doing on A9 “Using Components with Known Vulnerabilities”.

I saw that Sonatype provides a free Insight scan. I did that and got a nice summary:

clmHigh level summary

The high points of the summary are that:

  1. We use 58 libraries
  2. No high known security vulnerabilities in the libraries we use!
  3. Need to look into the details for the license “issues” since we are non-commerical.

Details

I then clicked on the other tabs and got a sample report. That’s the line where free lives. Since CodeRanch doesn’t have a budget, I asked the vendor for a free credit to see the report and they graciously agreed.

I then learned:

  1. All four of our security “issues” were in commons-httpclient. This library isn’t used anywhere in the codebase or in unit tests. I checked the description of the issue and we don’t  use that part of the library. So clean! I’m impressed that a completely volunteer run site came out clean. Good job to all the mods who update the jars!
  2. The license part showed a variety of licenses. For example dom4j and hibernate-core came up. The licenses would be more useful if we were a company and owned the product/could configure it ourselves.
  3. It was cool seeing the ages of the components we use. And which ones are exact matches vs similar. (I’m sure we didn’t edit hibernate-core!)

This report would be clearly be more useful for a large company. More applications and more people who work on them makes it harder to know what is going on. Still, I’m glad I didn’t have to check 50+ libraries by hand.

Disclaimer: I received free access to the detailed report in exchange for writing this review.