Get ready for the Java Forum Stuttgart 2012

July 5th 2012 is coming closer, and with that the Java Forum Stuttgart as well as my (German) session Sichere Software vom Java-Entwickler. This session will give you some ideas and recommendations for all of the problems and risks mentioned in the current OWASP Top 10. Since 10 is quite a number for 45 minutes, I'll mention some of them (5 to be exactly) rather as a quick overview and focus on the other 5. I'm not telling which 5 belong to which category yet, you'll have to attend my session to figure that out…

What you will get from the session are tips and tricks on how to avoid some of the top 10 risks in your applications. That's something every Java developer should know and use in his day to day programming. Hope to see you there!

Confident Data Transfers with Apache Camel Security at JavaOne 2012

Fantastic news today (with a little delay due to various reasons): My session on Confident Data Transfers with Apache Camel Security at JavaOne 2012 was accepted! So hurry up, sign up for it! It‘ll be all about securing Camel routes with XML-Security or normal cryptography and how to use Apache Shiro or Spring Security components to protect route access. All those topics are of course closely related to my latest article on Apache Camel Security – Payload Security in the German JAVAaktuell magazine 03/2012 as well as the follow up article Apache Camel Security – Route Security in 04/2012 (available in September).

This will be my first visit to JavaOne, hope to see you there!

JCrypTool release candidate 6 takes a little while longer…

As you may have already noticed, JCrypTool release candidate 6 (RC6) is already delayed. While there are still some (minor) issues we are working on, both in core and crypto, the main reason for the delay is this bug in FlexiProvider. This issue causes endless loops in different FlexiProvider operations and makes some crypto plug-ins mostly unusable. As long as it isn‘t fixed, RC6 is delayed, currently to June 3rd, 2012. Stay tuned and keep on enjoying release candidate 5a

Security is every developer’s job

In one of his latest blog posts published in the OWASP feed, Dinis Cruz points out, that secure development and application security itself must be invisible to developers. I can’t completely agree to that.

On one side, Dinis is right: The frameworks we use must be way more secure out of the box and way easier to use. But this will take a long time, and probably never be true for all the frameworks and functionality we are using in our everyday work.

Having said that, I always want developers to think about security while implementing a feature or a bug fix. As they (should) think about general code quality. They should ask questions like 'What can an attacker do here?' and 'How do I have to protect this method?'. These questions do not require being a security expert; they just require some basic security knowledge and awareness. And those questions even make sense when using secure frameworks.

So how can we make our software more secure? First of all, we need security aware developers. In other words: secure development training. Not all of them have to be e.g. cryptography or LDAP authentication experts (one per team, if required at all, is enough). But basics like input validation/ output escaping and the correct usage of prepared statements is a must for every developer. Don’t rely on the chosen framework here and that somebody else will clean up your mess. This is every developer’s job!

And secondly, we need more secure frameworks, as Dinis points out. I don’t want security features hidden to the developer, but easy to use and enabled by default. Look at the prepared statements example again. Why is it possible to use a secure alternative for normal statements in an insecure way with String concatenation (which leads to SQL injection)? There should be no way to do that. And why do I have to configure all the web.xml parameters myself, that make my application more secure (like http-only and secure for cookie handling)? OK, the last one is more a configuration than an actual framework issue, but you can see the point.

In the end, we can’t and shouldn’t stop secure development training for our developers. Even if it is expensive to train them all, one security aware developer is not enough. Companies really caring about secure development and application security train their developers. It’s that simple. And we should stop using insecure frameworks, and/ or influence their (open source) developers to make it more secure out of the box. Make suggestions on how to use functionality more easily and more secure. I bet that most communities welcome such contributions.

In my opinion, it is only the combination that will lead to more secure software: training and (more) secure and easier to use frameworks. Picking one will not bring us much closer to the ultimate goal of secure applications.

Using interceptors with version 2.1 Enterprise Beans

I recently hit the requirement to use Interceptors with some EJB 2.1 beans. Those beans should be migrated to 3.1, and tracing should make their complex flow easier to understand. As this blog post points out, it is possible to use interceptors with old EJB versions. Simply update the deployment descriptor to 3.0 or 3.1 and integrate the interceptors.

However, the code mentioned in the post did not work without modifications (at least in my environment with GlassFish 3.1.2). The described AuditInterceptor class required one little additional != null check in the first if to avoid NullPointerExceptions:

if (ic.getParameters() != null && ic.getParameters().length != 0) {

The deployment descriptor required some more changes, maybe only for the GlassFish 3.1.2 environment in my case:


<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar id="ejb-jar_ID" version="3.1"
 xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
 <enterprise-beans>
  <session>...</session>
 </enterprise-beans>
 <interceptors>
  <interceptor>
   <interceptor-class>de.xmlsicherheit.AuditInterceptor</interceptor-class>
   <around-invoke>
    <method-name>logMethodCall</method-name>
   </around-invoke>
  </interceptor>
 </interceptors>
 <assembly-descriptor>
  <interceptor-binding>
   <ejb-name>*</ejb-name>
   <interceptor-class> de.xmlsicherheit.AuditInterceptor</interceptor-class>
  </interceptor-binding>
 </assembly-descriptor>
</ejb-jar>

Using

<method>
 <method-name>*</method-name>
</method>

in the interceptor-binding did not work out. However, omitting this element completely results into intercepting all EJB methods anyway.

Using this approach brings you the benefit of intercepting EJB 2.1 beans in a 3.1 environment without touching the actual classes and minimal changes to the deployment descriptor(s).

XML Encryption 1.1 is a candidate recommendation

The XML Security Working Group has published the Candidate Recommendation for XML Encryption Syntax and Processing 1.1. The most important update in this version addresses the lately published chosen-ciphertext attacks against the CBC class of algorithms. Besides that, AES 128-GCM is now a required algorithm. AES-GCM is an authenticated encryption algorithm and provides both authentication and privacy. RSA-OAEP, a key transport algorithm, offers more algorithm variants. The other updates were more or less polishing for the final recommendation.

The other updated recommendation is XML Encryption 1.1 CipherReference Processing using 2.0 Transforms, now a candidate recommendation too. This rather short document (for a W3C recommendation!) specifies how the XML Signature 2.0 transform model may be used with XML Encryption 1.1 for CipherReference processing.

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.