Prof. Dr. Eric Bodden

In my group we worry a lot about what the future of secure software engineering is going to look like, and we are trying to shape that future for the better by developing tools, methods and programming languages that support a secure software design and implementation. One thing we have noticed over the past years is that many current applications and frameworks suffer from the fact that their security-related code is scattered throughout the program, and tangled with other code that is not at all related to security. From all the talk about AOP, we know that scattering and tangling can have detrimental effects, but this is especially true when talking about security. The repeated news reports about zero-day vulnerabilities in the JDK, for example, are just one instance of that problem.

Aspects are meant to modularize crosscutting concerns. So why not just use AspectJ to modularize all security code? In principle yes, I guess that would be a step into the right direction. But it cannot solve the whole problem. One problem is the well-known fragile pointcut problem. As base logic changes, pointcuts need to be updated. One of the problems with the JDK, for instance, was that new code was added without putting appropriate security checks in place. That’s pretty much the same problem we are talking about. Someone still needs to say where checks need to go!

In addition, AspectJ still has some problems that defeat the very nature of secure coding. First and foremost, AspectJ’s type system is unsound. Even though your base code and aspect may compile correctly, you may get type errors at composition time (weave time), yielding ClassCastExceptions, etc. In AspectJ, this unsoundness is by design, as it buys flexibility.

In a TOSEM paper that has just been accepted for publication, Eric Tanter, Milton Inostroza and I write about Join Point Interfaces (JPIs), a novel mechanism (and implemented language extension to AspectJ) to really decouple aspects from base code. Our system is type safe, and nevertheless it gives you virtually the same flexibility as AspectJ. Also we deal with the fragile pointcut problem by moving pointcuts closer to the base code. In our system, aspects are ideally free of pointcuts. They reference join points through nominal types. It is then the task of the base-code maintainer to instantiate these types with pointcuts or other constructs. In result, one obtains a system that is safe to use. Moreover, JPIs support gradual adoption and tight interaction between aspects and base code – something that’s important when talking about the implementation of security concerns.

We will demo JPIs at the AOSD conference. You can read our brief demo submission here. Opposed to the TOSEM paper, it gives just a very brief overview of the main language features.