Angular & OpenId: a real world example

In theory it appears pretty easy to build the browser side of an application using OpenId Connect. Actually implementing it in a real world application has usually proven to be more difficult than that.

I would like to show you how to solve some of the real world problems beside the basic setup. First let me describe what I want to build:

  • a single page app with Angular
  • routing via the hash part of the url
  • a forced login via OIDC

I will write about the following problems within building that app:

  • What library to choose?
  • Where and when to initialise that library?
  • Angular and hash based routing
  • How to handle errors?
  • Some smaller miscellaneous problems

Continue reading

WildFly 8-10 and JBoss EAP 7 verbose HTTP headers

As a developer I am really happy to have an easy way to determine which version of a software I’m running. But I do not like it if my software tells everyone its name and version, as this gives important fingerprinting information to possible attackers.

If you use WildFly versions 8 through 10 or JBoss EAP version 7 the default configuration includes some HTTP headers that are too verbose in my opinion. JBoss EAP 6 is not affected by the way. The headers you get look like this

Server: JBoss-EAP/7
X-Powered-By: Undertow/1

Getting rid of these headers is really easy. So I think the tiny effort to remove these headers should be put into any project even if the probability of getting attacked and the possible impact are really small.

To fix the problem let’s have a look at the default configuration in the standalone.xml:

Continue reading

commons-fileupload 1.3.3 resolves deserialisation vulnerability CVE-2016-1000031

CVE-2016-1000031 is a vulnerabilty in the extremely widely used Apache Commons library commons-fileupload – you might not even know you’re having it on your class path. It has a very nasty Remote Code Execution vulnerability with easy to use exploits publicly available up to version 1.3.2. What makes it even worse is that you do not even need to use the library – you only need to have it on your class path and to deserialise some data. The data is the attack vector. You can find a good in detail explanation of the vulnerability here.

It did take a while but with version 1.3.3 this vulnerability is finally closed (by default).

There is some stuff that you should know about the fix though:

Continue reading