Posted on

My two security sessions at JavaOne 2014

Awesome news today, my two security sessions at JavaOne 2014 have been accepted! I’ll be speaking about Security starts in the head(er) (CON2371) and 7 security tools and libraries every developer should know (CON2585) (see the session information below). Flight and hotel are booked; hope to see you in San Francisco!

Security starts in the head(er)
Java developers surely have already heard or even used some of the many available HTTP response headers in their web applications. Some of these response headers promise to have a positive impact on the security on the client side. However, they are not widely used yet, even in newly developed web applications. This results in giving away relatively easy attainable security benefits.
This session introduces attendees to different security related response headers and intends to raise the participants’ attention for the unjustified low usage of these security headers. Besides an introduction and a closer look at their properties, the session explains how to correctly configure and integrate them into a Java web application.

7 security tools and libraries every developer should know
Like in almost any other part of Java the security area for web applications offers a huge amount of different sized libraries and tools which all promise to make the life of a developer much easier. However their sheer amount raises the question which libraries are used best at which time and which tools optimally support the secure development of a web application.
This session introduces seven different security-tools and -libraries (frameworks), which support a developer when developing secure Java based web applications. These libraries solve common and wide spread security problems in web applications. The shown tools assist the developer and make it easier to preserve the achieved level of security in the web application.

Posted on

JSF stateless views and CSRF protection

JavaServer Faces (JSF) – especially since version 2.2 – provides a good Cross-Site Request Forgery (CSRF) protection. To achieve this, every form automatically receives a random hidden token:

JSF non-transient view

Nothing more to do for the developer, JSF takes care of comparing the token’s value against the one stored in the server side session. Without the correct token, the request won’t be processed.

JSF 2.2 also introduced stateless views, simply by marking one as transient:

<f:view transient="true">...</f:view>

Using a transient view may make sense e.g. before a user has logged in and no session needs to be stored on the server. Or you want to avoid that nasty ViewExpiredException. But keep in mind that this influences the out of the box CSRF protection as well. Looking at the same form from before but with transient on true, the anti CSRF token changes:

JSF transient view

An anti CSRF token needs to be unpredictable and absolutely random to be of any use for CSRF protection. The static value stateless of course is not.

Is this a bug? No! The most common implementation for CSRF protection is called Synchronizer Token Pattern. This pattern stores a hidden value in forms (like javax.faces.ViewState) and the corresponding value in the server side session. Using transient=”true” avoids creating a server side session. No session, no Synchronizer Token Pattern, no CSRF protection. So when using stateless views you’ll have to implement CSRF protection yourself. The requirement is the same: a random token calculated per user and per session (or per request depending on your security needs). But without the server side session the implementation needs to change. Luckily, there is another option called Double Submit Pattern (see here for a description of both patterns). Double submit, as the name implies, submits the same token from two different places: one in a cookie and the other one, as before, in each form you want to protect. Whereas the cookie is always submitted – including faked requests – the form token is missing and your backend – which has to compare the two submitted tokes – can recognize an invalid request. So by avoiding session creation for every visitor (user), you’ll be giving away the out of the box JSF CSRF protection.

One usage scenario for stateless views might be a login form. After logging in, you want a session for the user, but not for any anonymous visitor. You might ask yourself, what harm a login form that is prone to CSRF could do? Well, it may enable an attacker to automatically log in a user with prepared credentials. This way, the attacker may record and retrace the users’ actions. Therefore you should protect the login form against CSRF as well.

That’s the tradeoff you have the be aware of: JSF provides out of the box CSRF protection, as long as your view isn’t transient. If that this the case you’ll have to take care of the CSRF protection yourself.

Posted on

A look back at JavaLand 2014

JavaLand 2014 is over, and it has been a great first edition of the conference! It was a great privilege speaking there. The sessions I’ve attended were interesting, I ended up with a lot of new ideas for the weeks to come. The different community activities made it really easy to get in touch with others, talking about Java more or less the whole time. Enjoying some park attractions in the late evening did the rest to get to know some new Java enthusiasts. The whole location was nice, definitively the most extraordinary place of any Java conference I’ve attended so far. Like a little geek holiday. Organization was good (with some minor places for improvements). Lunch and dinner buffets were huge. And the floating lunch time avoided long lines. Speakers and organizers welcome dinner on the first evening was a good start, the African food served really something unusual and tasty.

Two minor things I did not like that much were the two too dark session rooms (including mine). I like to see my audience and have some kind of eye contact. Yes, the stage background was really great and something completely different. But simply too dark. The other thing I did not like was the stuff you had to pay for separately. I don’t have a problem that not everything is included in the conference fee (which, as a speaker, I did not pay anyway). But the hotel was quite expensive; to be topped by the drinks at the bar and the drinks you had to pay for after running out of coupons. Yeah, it’s a theme park, which all are at least a little bit pricy. But the park was opened for the conference only, more fair prices should have been possible.

But besides that, I really enjoyed this new conference, definitively worth a visit next year in case you missed this one. And I’m sure that most of this years attendees will come back.

Posted on

JSF – Referencing resources in stylesheets

I recently ran into some trouble when trying to show a background image in a JSF page which was included via a stylesheet. When using

<h:outputStylesheet library="css" value="styles/styles.css" name="styles.css" />

to include the stylesheet into the JSF page, referencing resources (like images) in the CSS file need a special URL form. The typical form

html {
  background: url("/resources/images/bg.jpg")
}

(or any other path like that) will not work. The correct form is

html {
  background: url(#{resource['images/bg.jpg']});
}

Posted on

JCrypTool 1.0.0 Release Candidate 7 available

JCrypTool 1.0.0 Release Candidate 7 is available for download! We fixed a lot of bugs, enhanced a lot of features and integrated six new crypto plug-ins:

  • New visualization plug-in Extended RSA
  • New visualization plug-in Signature Demonstration
  • New visualization plug-in Public-Key Infrastructure
  • New visualization plug-in Huffman Coding
  • New visualization plug-in Shanks Babystep-Giantstep
  • New games plug-in Divide

Special thanks to all contributors!

All changes are listed on the Core Issues and on the Crypto Issues pages.

This is our last release candidate, the final version will be available 2014. Your bug reports and your feedback are welcome (as always).

Posted on

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"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://www.jboss.com/xml/ns/javaee"
  xsi:schemalocation="http://www.jboss.com/xml/ns/javaee
  http://www.jboss.org/schema/jbossas/jbossws-web-services_1_0.xsd">
  <context-root>/</context-root>
</webservices>

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.