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.

flattr this!

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.

flattr this!

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']});
}

flattr this!

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).

flattr this!

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.

flattr this!

Remove Checkstyle warnings for certain classes

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

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" "http://www.puppycrawl.com/dtds/suppressions_1_1.dtd">
<suppressions>
 <suppress checks="." files="Messages.java"/>
</suppressions>

flattr this!

Eclipse, Java, JCrypTool, Secure Development, XML Security and other IT related thoughts