Importance of block cipher modes

While writing software dealing with cryptography, it’s important to be familiar with a concept of block cipher modes. Most of common encryption algorithms work on data grouped together into blocks. For instance, in case of DES cipher, the block size is equal to 64 bits. While encrypting larger amounts of data, cipher implementation will divide the input into 8 byte chunks and encrypt each of them separately.

This is definitely not desired – in case of specific input that contains repeatable sets of information (like text documents, bitmaps with large areas of the same color), the encrypted chunks might repeat just like original plain-text values do. As a result of that, encrypted data might reveal important details of the original content.

Non-repudiative logging

Non-repudiation is a very interesting subject at the intersection of technology and law. For the sake of exercise let’s imagine a very simple scenario in which we’d like to have some specific user actions logged into a file in a way that would allow us to find out later, whether anybody has modified the content of such a log file. Let’s naively assume that anything that the application puts to logs can be trusted.

In order to accomplish this task, we will create a Log4j appender that will calculate an HMAC (hash) of every logged event and attach it to the log file as well.

Decryption of configuration passwords in WebLogic

BEA/Oracle WebLogic application server being an enterprise-ready piece of software treats security seriously. One of the symptoms of that is the fact that all sensitive pieces of information like logins, passwords etc. are kept in encrypted form. While browsing through config.xml or boot.properties files you can easily spot them since they are usually prefixed with ‘{3DES}’ string which obviously suggests the encryption algorithm used.

The interesting thing is that with a little bit of efford it’s actually quite easy to extract the decrypted values from config files by using a few undocumented APIs buried in WebLogic itself. Below you will find a simple tool that will output a content of either .xml or .properties configuration file provided as input, replacing all encrypted values with their original content. It works with WebLogic 10 but can be easily adapted for versions 8 and 9 as well (domain directory structure is slightly different between these versions). I wrote it some time ago in order to be able to easily retrieve logins and passwords of development domains that I kept forgetting too often. Obviously there are many other uses, like configuration management, application server migration tools etc.

User context tracking in log4J

Majority of web applications based on Java platform use log4j library to record user activities. All is fun and games until the number of users and logged messages per unit of time exceed a specific threshold. Since log entries for multiple users are intermixed – it gets very difficult to analyze what exactly did a specific user do within a single request.

Fortunately log4j provides a very convenient way of solving this problem. A class org.apache.log4j.MDC provides a mechanism to ‘attach’ any arbitrary information to a given thread that processes a request and to output this information into the log entry. What we need to do is to invoke a static method MDC.put(“userId”, userId) somewhere at the beginning of request processing chain (by using servlet filter for example) and add the element %X{userId} to the row format definition in log4j configuration, for example:

log4j.appender.file.layout.ConversionPattern=%d %5p %c %X{userId} (%F:%L) – %m%n

After that every log entry will contain user identifier which is all we need in most cases. Sometimes we might want to put into the log some additional data. If our application uses AJAX a lot, then a single user might issue multiple requests at the same time, which still can get mixed. It might be a good idea then to add a unique index value incremented after each request etc.

If you add this feature to your application, the people who routinely have to analyze its logs and solve user problems will be most grateful!

Hierarchical stopwatch measuring code performance

While developing software it is a good habit to keep an eye on performance of specific parts of code. There are obviously many ways to do it – we can for instance benchmark specific methods or modules as part of unit tests, we can use tools like JMeter to simulate larger number of users, we can run a profiler from time to time etc. Despite having all these advanced approaches in reach, sometimes the most convenient (or lazy) way to measure performance is to wrap code with something like this:

long t = System.currentTimeMillis();
doSomething();
System.out.println("took " + (System.currentTimeMillis() - t) + "ms");

There are definitely many cons to this approach – it’s not elegant, the results are scattered all over the log file, it can not be turned off and so on. If you happen to be using Spring Framework or Apache Commons, you might use one of their implementations of StopWatch class (here and here), which is a wrapper with some additional capabilities, like report formatting, providing of statistics etc.

Some time ago I was in a need to use a stop watch for a web application based on Spring. After spending some time with mentioned implementations it became obvious that what I needed was a slightly different mechanism – one that would allow me to see a hierarchical structure of time consumption of individual pieces of code. Something like:

run() : 2753 ms
	foo() : 2753 ms
		bar() : 417 ms
			bang() : 60 ms
			bang() : 119 ms
			bang() : 238 ms
		bar() : 2336 ms
			bang() : 477 ms
			bang() : 953 ms
			bang() : 906 ms

Cross-site scripting and HttpOnly attribute

Microsoft Internet Explorer⁽¹⁾ has an interesting feature which is not very well known. If a cookie has been set with attribute ‘HttpOnly’ then the browser will forbid any access to it from client-side code. Javascript will not be able to read, write or acknowledge information stored in the cookie.

At first sight this might not seem to be very useful, but if we bring into the picture security of web applications and especially cross-site scripting (XSS) vulnerabilities – things get interesting. One of the classical examples of XSS attack is the one in which a hacker manages to read user’s session identifier from a cookie and use it to access a resource⁽²⁾.

The most obvious way to remediate that would be to use HttpOnly attribute while setting the JSESSIONID cookie. Unfortunately this step is done by the application server itself and as on now most of them do not use HttpOnly⁽³⁾. What we might try to do is to rewrite the cookie after it has been created as shown here: http://keepitlocked.net/archive/2007/11/05/java-and-httponly.aspx.

But there’s also another way which you might consider.