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

Bummer!

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.

Free web application vulnerability scanner for Eclipse auf Twitter teilen
Free web application vulnerability scanner for Eclipse flattrn
Free web application vulnerability scanner for Eclipse auf Digg teilen
Free web application vulnerability scanner for Eclipse auf Delicious teilen
Free web application vulnerability scanner for Eclipse auf Xing teilen
Free web application vulnerability scanner for Eclipse auf LinkedIn teilen
Free web application vulnerability scanner for Eclipse auf Pinterest teilen
Free web application vulnerability scanner for Eclipse auf StumbleUpon teilen
Free web application vulnerability scanner for Eclipse auf Tumblr. teilen
Free web application vulnerability scanner for Eclipse auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

Remove Checkstyle warnings for certain classes

Checkstyle warnings for generated or automatically filled classes like Messages.java 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"/>
</module>

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" "http://www.puppycrawl.com/dtds/suppressions_1_1.dtd">
<suppressions>
 <suppress checks="." files="Messages.java"/>
</suppressions>

Remove Checkstyle warnings for certain classes auf Twitter teilen
Remove Checkstyle warnings for certain classes flattrn
Remove Checkstyle warnings for certain classes auf Digg teilen
Remove Checkstyle warnings for certain classes auf Delicious teilen
Remove Checkstyle warnings for certain classes auf Xing teilen
Remove Checkstyle warnings for certain classes auf LinkedIn teilen
Remove Checkstyle warnings for certain classes auf Pinterest teilen
Remove Checkstyle warnings for certain classes auf StumbleUpon teilen
Remove Checkstyle warnings for certain classes auf Tumblr. teilen
Remove Checkstyle warnings for certain classes auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

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/compile.org.eclipse.pde.[…]/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?

Eclipse RCP export failure auf Twitter teilen
Eclipse RCP export failure flattrn
Eclipse RCP export failure auf Digg teilen
Eclipse RCP export failure auf Delicious teilen
Eclipse RCP export failure auf Xing teilen
Eclipse RCP export failure auf LinkedIn teilen
Eclipse RCP export failure auf Pinterest teilen
Eclipse RCP export failure auf StumbleUpon teilen
Eclipse RCP export failure auf Tumblr. teilen
Eclipse RCP export failure auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

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" />
</topic>

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.

Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf Twitter teilen
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles flattrn
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf Digg teilen
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf Delicious teilen
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf Xing teilen
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf LinkedIn teilen
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf Pinterest teilen
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf StumbleUpon teilen
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf Tumblr. teilen
Alphabetically sorting Eclipse RCP help pages and custom bookmark titles auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

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.

Apache XML Security 1.5.0 released auf Twitter teilen
Apache XML Security 1.5.0 released flattrn
Apache XML Security 1.5.0 released auf Digg teilen
Apache XML Security 1.5.0 released auf Delicious teilen
Apache XML Security 1.5.0 released auf Xing teilen
Apache XML Security 1.5.0 released auf LinkedIn teilen
Apache XML Security 1.5.0 released auf Pinterest teilen
Apache XML Security 1.5.0 released auf StumbleUpon teilen
Apache XML Security 1.5.0 released auf Tumblr. teilen
Apache XML Security 1.5.0 released auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

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 eclipse.org 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.

XML Security Tools in danger auf Twitter teilen
XML Security Tools in danger flattrn
XML Security Tools in danger auf Digg teilen
XML Security Tools in danger auf Delicious teilen
XML Security Tools in danger auf Xing teilen
XML Security Tools in danger auf LinkedIn teilen
XML Security Tools in danger auf Pinterest teilen
XML Security Tools in danger auf StumbleUpon teilen
XML Security Tools in danger auf Tumblr. teilen
XML Security Tools in danger auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

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 1.1 pushes only the active branch by default auf Twitter teilen
EGit 1.1 pushes only the active branch by default flattrn
EGit 1.1 pushes only the active branch by default auf Digg teilen
EGit 1.1 pushes only the active branch by default auf Delicious teilen
EGit 1.1 pushes only the active branch by default auf Xing teilen
EGit 1.1 pushes only the active branch by default auf LinkedIn teilen
EGit 1.1 pushes only the active branch by default auf Pinterest teilen
EGit 1.1 pushes only the active branch by default auf StumbleUpon teilen
EGit 1.1 pushes only the active branch by default auf Tumblr. teilen
EGit 1.1 pushes only the active branch by default auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren

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.

EGit pushes all local branches when no explicit RefSpec is found - Update auf Twitter teilen
EGit pushes all local branches when no explicit RefSpec is found - Update flattrn
EGit pushes all local branches when no explicit RefSpec is found - Update auf Digg teilen
EGit pushes all local branches when no explicit RefSpec is found - Update auf Delicious teilen
EGit pushes all local branches when no explicit RefSpec is found - Update auf Xing teilen
EGit pushes all local branches when no explicit RefSpec is found - Update auf LinkedIn teilen
EGit pushes all local branches when no explicit RefSpec is found - Update auf Pinterest teilen
EGit pushes all local branches when no explicit RefSpec is found - Update auf StumbleUpon teilen
EGit pushes all local branches when no explicit RefSpec is found - Update auf Tumblr. teilen
EGit pushes all local branches when no explicit RefSpec is found - Update auf Pocket weiterlesen
Dominik Schadow auf Feedly abonnieren