General Secure Development

Java-Web-Security – Sichere Webanwendungen mit Java entwickeln

Java-Web-SecurityMy (German) book Java-Web-Security – Sichere Webanwendungen mit Java entwickeln is available at dpunkt.verlag since February 25th 2014 and of course in every book store out there.

Java Secure Development

Java-Web-Security: Sichere Webanwendungen mit Java entwickeln

Early 2014 in a bookstore near you Java-Web-Security: Sichere Webanwendungen mit Java entwickeln (German only, at least at the moment…)


JBoss AS 7 context-root manipulation for web services

I recently had a requirement for web service availability at root context level on JBoss AS 7. Without any configuration, a web service URL (as the rest of the web application) contains the jars’ name like http://localhost:8080/MyJar/MyService/MyEndpoint whereas my desired URL looked like http://localhost:8080/MyService/MyEndpoint without the jars’ name. Adding the jboss-webservices.xml file to the META-INF folder of the web service project with the following content was only have the story:

<?xml version="1.0" encoding="UTF-8"?>
<webservices version="1.0"

Now JBoss Management Console showed service availability at the desired URL, but the service was unreachable (404). The final part was to modify standalone.xml and set the value of the enable-welcome-root attribute to false (attribute belongs to the virtual-server element), which made the web service reachable on context root.

Eclipse Java

Remove Checkstyle warnings for certain classes

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

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" "">
 <suppress checks="." files=""/>

Events Secure Development

Java Security Myths session at DOAG 2013

DOAG SpeakerI’ll be speaking about Java Security Myths at the DOAG 2013 conference in Nürnberg. My (German) session is on November 21st at 10 a.m.


A little bit more security for Java in the browser

Oracle just released Java 7 update 21, containing once more many security fixes (install it right away). And some changes for applet usage und handling. First of all, the preference dialog does not contain the low security setting any more. Which forces more user interaction when launching unsigned applets. Unsigned applets therefore require at least some interaction now; they are not launched automatically any more. A future Java update (probably the next update in July) will prevent you from running unsigned applets at all. And there will be a blacklist which will protect you from running applets signed with an invalid or revoked certificate.

For sure this will have a positive impact on Java browser security, but it’s not a big catch. This totally relies on certificate authorities and that they carefully check people buying certificates. And we all know how well that worked out in the past many, many times. It’s just too easy to get valid certificates. And there are no restrictions left when running signed applets.
Yeah, now we ‘know’ who bought the certificate and probably signed the malicious applet and can trace it back. Up to the point where we figure out a faked id was used to buy the certificate. This is not helpful at all. Oracle’s reaction to certificate fraud is to add such an invalid certificate to the frequently(?!) updated JRE certificate blacklist and prevent the JRE from further applet execution. This might work in 80% of the time. The other 20% will receive this update too late. In my eyes this is not a real solution, just another workaround to avoid killing the whole Java applet support at all.

Of course it is not Oracle’s fault that it is that easy to get a valid certificate with a fake id or no check at all. But fixing one broken system with another broken system is simply not going to work. And the loser is Java.


Java in the browser is dead

So its certificates now. Looks like Java applets don‘t care about certificate revocation lists at all. Signed applets gain full access to the system. An invalid certificate should prevent that. Which means a certificate revocation list is kind of important. But no, let’s forget about that check. No need to hack the sandbox this time (which is easy anyway, see the last couple of Java updates).

This is another huge security failure in Java applet ‘security’ again. One in a long way. And not the last one. In fact there are still some known vulnerabilities even in the latest Java version.

The latest series of security problems caused a lot of damage for the whole Java platform and ecosystem. As a Java developer I can (and do) only advise everybody to uninstall Java or at least to deactivate Java browser support. Like a lot of people do. But what’s Oracle’s reaction? By shipping one critical update after the other. Faster than ever. But that won’t change much, the next critical security hole is just around the corner. Java in the browser is insecure and will remain so. And Java in the browser is that. Oracle just won’t admit it.

The problem with that is: Java on the client will be dead next. Normal users cannot distinguish between Java browser applications and rich clients (kind of our fault, since we told everybody for years now to ignore that border). Server side Java will not die that easily (good!), but the last couple of months caused a lot of damage there too. It became much harder to argue for a Java web application instead of .net for example. Not that other frameworks don’t have security issues too. But all people hear at the moment on a certain (management) level is that Java is insecure and needs security fixes every couple of days. How would you react?

This will become even harder in the future if Oracle continues like that. The only solution in my eyes is to remove Java browser support right now. Get rid of this totally outdated and widely unused peace of technology. Restore Java’s good reputation before it is too late.

Secure Development

OWASP Top 10 2013 release candidate published

The first release candidate of the new OWASP Top 10 2013 was published a couple of days ago (PDF). And the top 10 changed quite a bit (see the project wiki):

  • A1 Injection
  • A2 Broken Authentication and Session Management (was formerly A3)
  • A3 Cross-Site Scripting (XSS) (was formerly A2)
  • A4 Insecure Direct Object References
  • A5 Security Misconfiguration (was formerly A6)
  • A6 Sensitive Data Exposure (merged from former A7 Insecure Cryptographic Storage and former A9 Insufficient Transport Layer Protection)
  • A7 Missing Function Level Access Control (renamed/broadened from former A8 Failure to Restrict URL Access)
  • A8 Cross-Site Request Forgery (CSRF) (was formerly A5)
  • A9 Using Known Vulnerable Components (new but was part of former A6 – Security Misconfiguration)
  • A10 Unvalidated Redirects and Forwards

Some changes are a little bit surprising in my eyes at first. Definitively not that injections are still number 1. Guess some things never change. But I think the drop of XSS from 2 to 3 and CSRF from 5 to 8 does not reflect reality. Sure, there is little more awareness to these problems (only a little), and some Java frameworks offer (some, but getting better) out-of-the-box-protection. But these issues are still tough to solve and are still dangerous. And they are a good eye-catcher and easy to talk about. Hopefully that does not prevent developers to think about it during web application development. Not that the other items are unimportant, however I can’t fully agree with the order.

But whatever is your motivation for secure development (in case you simply need another one besides, well, security), don‘t take the OWASP top 10 positions too seriously. The issue is important, not the current position. OWASP top 10 issue 11 (whatever dropped out the list) may be your issue number 1. And even a controversial list makes developers talk about security, which is the best thing that could happen to us.

The OWASP Top 10 2013 final version should be available in May 2013.


Making Java secure again

The recent total failure of Java security is neither the first one, nor will it be the last one. Java in the browser (in the form of Java applets) is not secure and will never be secure. Oracle can provide all the security patches they want, the next major security breach is just around the corner.

This is comparable with Microsoft Windows security a couple of years ago. Year after year they tried to fix it and ran from bugfix to bugfix before noticing it will not change too much and that a complete redesign of their operating system is required. In case of Java the only solution (in my eyes) is to remove Java browser support with the next major release Java 8. This feature is not widely used any more, applets are plain old technology. Oracle should announce the stop of support right now. Don’t tell people to deactivate it, this is not a solution. Don’t even ship it. Users still requiring Java in the browser can use Java 7 in the transition period. This should provide enough time for all companies and all products to switch from unsecure Java applets to much safer Java web applications. And companies still using Java applets should ask themselves, why they force their users to rely on an unsafe technology.

Oracle keeps telling (e.g. in the JRE installation dialog) us that 3 billion devices run Java. This number will go down rapidly with every new major security problem. The security problems of one little part of the platform will have a negative influence on the rest of the platform. Word will spread that Java is insecure. This makes the usage of Java in any project harder than necessary. Server side Java is safe, Java desktop applications are safe, Java embedded is safe (in the usual dimensions). But it’s hard to argue about Java safety with everybody hearing about Java security failures in mainstream news. Normal users do not and cannot differentiate between web and desktop application security as we developers do. For a normal user Java is failing. This will be a huge problem in the future.

And finally, removing Java browser support will give more time for all the great Oracle Java employees on moving the platform forward. The rest of the Java platform would surely benefit from that.


Java 7 update 11 available, addressing the latest major security flaw

So, Oracle released Java 7 update 11 today, addressing the latest major security flaw with Java applets. Guess we are safe now for about a week. Of course I strongly recommend installing the new release as quickly as possible. But keep Java disabled in your browser! In case you do need a Java applet I’ll recommend to only activate Java on demand. Java in the browser (I’m talking about Java applets only) is outdated technology, and it is totally unsafe. And it will remain unsafe, no matter how many security patches will be provided by Oracle. The next security flaw is just around the corner. It is time to get rid of Java browser support; focus on server side Java, Java desktop applications as well as the mobile world. Java rocks, but it definitively sucks as a safe browser extension.