Category: Secure Development

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.

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.