Categories
Events Java

JavaOne 2012 roundup

My first JavaOne ever is over. Had a great time there. San Francisco is a great city, and the weather was perfect, a least the first couple of days.

I did enjoy all keynotes, especially of course the Java Community Keynote with James Goslings‘ surprise visit and presentation.

Most sessions I‘ve attended were really great. Experiencing Adam Bien live was really a lot of fun. My other highlights were Modern Software Development Antipatterns by Ben Evans and Martijn Verburg (those guys rock!), Real-World Java EE 6 Tutorial by Paul Bakker and Bert Ertman (impressive knowledge) as well as several security related sessions. And of course my own session on Apache Camel Security. More people (about 60 showed up, more than 80 registrations) as expected were interested in a security topic.

The locations (the three JavaOne hotels) were closer together than expected, way less time-consuming walking as expected. But even the short distance made it impossible to attend all desired sessions in full length since an early show up at most sessions was required.

Plus of course the free beer and coffee (not at the same time) sponsored by IBM. A lot of cool bands in the evening. Oracle‘s overall organization was perfect, including always available helpful staff.

What I do not understand however is how technically interested people (a.k.a. geeks) are not able to mute their mobile when attending a session. I can‘t remember too many session without at least one mobile entertaining everybody with a lovely ringtone. This is totally disrespectful of the speaker and the other attendees.

What I didn't like that much: WLAN was a catastrophe, at least most of the time. OK, this is really a challenge, so many geeks with so many devices… But hey, it‘s 2012! And food was extremely poor. Welcome dinner on Sunday night was great, but the rest of the week was sandwich only. It was enough, but nothing special at all. And why they served drinks in cans is, for a so-called green conference, beyond me.

But anyway, JavaOne 2012 was a success for me and a great experience! Lets see whether I will get the chance to go there again.

Categories
Events Java

Still some seats available in my JavaOne session on Apache Camel Security


Hurry up, JavaOne starts in one week! And there still some spots available in my session on Apache Camel Security. Save the date, October 3rd 2012 (Wednesday) at 10 a.m. at Parc 55 – Embarcadero.

My session will introduce you to Apache Camel Security and show how to secure your Camel routes and messages using Camels’ very own features only. You will end up with secured messages and routes which can only be accessed by the configured user groups. Since Camel tends to integrate services providing critical business data it’s about time to take security into account.

Slides are ready, demo is ready, the only thing missing is you… So what’s holding you back, see you there!

Btw, I will (try to) twitter about my week at JavaOne.

Categories
Java Secure Development

Total failure of Java security

Wow, that’s a sentence I believed I would never write in my professional life: deactivate Java in your web browser immediately! In any browser and on any operating system. Instructions are e.g. available here and normally on your browser manufacturer home page. Turning it off does not have an impact on normal Java applications, those programs can operate normally. In case you are using an older Java version as 1.7: you should be fine and safe, at least with this bug (but there are other bugs in Java 1.6 that have been fixed in Java 1.7).

What happened? Java applets, as unimportant they are these days, are potentially harmful programs executed on your machine. You don’t want them to have access to everything. And for years we (including myself) believed that it is not possible to turn the Java applet security manager of or modify it. This security manager is always and automatically in place when launching a Java applet and it can’t be deactivated, replaced or modified by another one. It makes sure that untrusted (a.k.a. dangerous) code from another machine does not have access to the local computer and its resources. At least up to now.

There is no way to put lipstick on the pig; this is a total failure of Java security. Sandboxes (not only the Java sandbox) have always been a problematic area and of course did and do contain security holes (like most of the other applications). But are there any alternatives?

I think it’s time to remove Java support from web browsers. At least by default. It’s only required for Java applets, and honestly, how often do you run into those? Java web applications deliver, as other web applications, normally HTML to the client. They don’t need a Java runtime on the client. Removing Java support in web browsers does not affect those applications. And the client itself can keep on using Java applications, that’s no problem either. So where is the downside?

Yes, I like Java, yes, I develop Java (web) applications and I don’t want people and companies to stop using Java. It’s a great programming language and a great platform. But it’s time to rethink some old habits and get rid of mostly unused and insecure features that where only important in the past.

There are some good (German) technical details and some code available at heiseSecurity, some English details are available here.

Update, 08/30/12: Oracle has released Java 7 Update 7 which fixes this critical vulnerability. You should update your systems immediately!

Update, 09/03/12: Turns out the new release is still vulnerable, see here (in German). In case you do not use any Java applets better turn off the browser plugin permanently.

Categories
Java

Nasty NullPointerException in org.springframework.beans.factory.BeanDefinitionStoreException

I had a lot of trouble with Camel 2.9.2/Spring 3.0.7 projects lately (though the issue is related to Spring, not Camel). During development, a lot of server starts (I used VMware vFabric tc Server Developer Edition v2.7, but others seem to be affected as well) failed with a really nasty exception:

org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring/camel-context.xml]; nested exception is java.lang.NullPointerException

Stopping and starting sometimes helped, but often a couple of restarts were necessary to get everything working. The solution was to omit jaxb-impl version 2.2.4-1 in the Maven configuration by replacing it with the following dependency (exactly this version):


<dependency>
 <groupId>com.sun.xml.bind</groupI>
 <artifactId>jaxb-impl</artifactId>
 <version>2.2.3</version>
</dependency>

Categories
Java

Integrating Jenkins build results into JIRA issues

After linking Subversion (or Git) with JIRA, the build server looks like a worthwhile target too. Aim of the JIRA integration for Jenkins is to link JIRA issues with the resulting build artifact and to answer the question “Which build contains the bug fix for issue 1234?”. The Jenkins JIRA plugin therefore updates the JIRA issue by adding a comment containing a link to the generated build artifact.

The JIRA Plugin requires Jenkins, sadly it does not work with Hudson any more (this includes the latest Eclipse Hudson 3.0 milestone 2 release). It is possible to install the JIRA plugin in Hudson, even to configure it. However, including JIRA as post build action results into a java.lang.NoSuchMethodError: hudson.scm.ChangeLogSet$Entry.getCommitId()Ljava/lang/String; exception and a failed build.

Installation and initial configuration
Installation is simple: Open the Plugin Manager, install the JIRA Plugin and restart Jenkins:

JIRA Plugin installation

The following initial configuration must be done only once on the Manage System page, in a corporate environment supposedly by a Jenkins administrator. Add a new JIRA configuration and provide the URL to your issue tracker, as well as username and the password. This user requires write access to all projects using the Jenkins JIRA integration. Since the username will show up as comment author, a service user like jenkins_ci or something similar makes it easier understandable where those comments are coming from. Finally, check the Record Scm changes checkbox and save your changes.

JIRA Plugin configuration

In case a certificate exception like sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target shows up at the URL textfield, Jenkins doesn’t find or recognize the JIRA server certificate (especially if it is a self-generated one). Simply obtain this certificate and import it using the Java keytool (replace [jira-domain] with your domain name):

keytool -import -alias [jira-domain] -keystore $JAVA_HOME/jre/lib/security/cacerts -file file.cer

The JDK (or JRE) entered for the keystore must be the one configured for Tomcat. You have to use this keystore (Linux requires usage of the sudo command)! Password of the global cacerts keystore should be changeit. Jenkins (Tomcat) needs to be restarted after the import. In case the exception is still there, either the imported certificate was not the correct one, the alias is not correct or the given Java path is not the Java installation used by Tomcat.

Individual project configuration
Now every project can use the JIRA integration. First of all, create your JIRA project and your SVN (or Git) repository as usual. Then start a new Jenkins build or modify an existing one. Set up all required build steps as usual.

Each project must enable the JIRA Jenkins connection individually. This requires write access for the Jenkins service user to your JIRA project. This user will update the corresponding issues with a comment after a build.

After this initial organizational task and the basic project setup, the projects Post-build Actions in its build configuration must be updated by selecting Update relevant JIRA issues. No additional JIRA configuration is required here. But it may make sense to periodically poll the SCM by configuring a schedule (like every couple of minutes). Otherwise you’ll have to start the build manually.

JIRA Plugin Post-build Actions

Day to day project usage
There are no special tasks or steps required to take advantage of the Jenkins JIRA integration. The only requirement is, that a SVN/Git commit contains the JIRA issue ID in the commit message (e.g. as it is done automatically by Eclipse Mylyn with an active task). Every new commit included in a new build will be searched for JIRA issue IDs. Each issue will contain the same comment created by the Jenkins JIRA plugin pointing to the generated artifact.

JIRA issue updates by Jenkins

Categories
Events Java

Camel Security @ JavaOne – What is it all about?

As JavaOne 2012 is coming closer, it's time for some more information on my session CON3418 – Confident Data Transfers with Apache Camel Security.

As you might have already guessed, it's all about Apache Camel security. So, what exactly is so special about Camel security? Well, it is of course possible to secure any Camel communication with SSL/TLS, like any other http communication or web service calls for example. Not really special and associated with some disadvantages too. And that's where Camel security comes to the rescue. In fact, Camel security consists of more than one part, payload and route security are the important ones in this case. Payload security takes care of encrypting or signing the message content (a.k.a. payload). This can be classic cryptography (classic does not stand for the real classic cryptography like Caesar encryption) with the Crypto data format or XML based cryptography (XML Encryption) with the XMLSecurity data format. And of course digital signatures of the message content. In the other part of the session I will talk about route security. Route security protects the routes itself, taking care of who (user or user group) can call a route or particular route section. This is done with the Camel components for Apache Shiro or Spring Security.

A lot to talk about. And a lot of ideas and recommendations for securing your Apache Camel routes in your integration projects. Hope to see you in my session! And for the Camel fans: There is a second session on Apache Camel: CON2430 – Next Generation: Systems Integration in the Cloud Era with Apache Camel

As I'm making progress in creating the slides/ demos for my session, I will provide some previews here in my blog the next couple of weeks. Make sure to come back regularly…

Categories
Events Java

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!

Categories
Events Java

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!

Categories
Java Secure Development

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.

Categories
Java

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 &&amp; 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).