Aspect-oriented programming and security

Working together

By Rohit Sethi, SecurityFocus • Get more from this author

Posted in Software & Security, 31st October 2007 19:35 GMT

Free whitepaper – Straight Talk with Dell: Sending out an SaaS

What's even better is that I now have a central piece of code that I can change easily. For instance, suppose I find that my particular white-list is vulnerable to a newly-discovered form of XSS, then I can modify the list in one place and have it automatically propagate. Moreover, if I find other parts of my code are vulnerable to the same XSS, I simply define additional pointcuts and I'll quickly be defending against those attacks as well. In addition, if I find there are several different white lists that I need in my application (e.g. one that accepts only alpha, one that accepts alphanumeric, etc.) then I can define multiple regular expressions within the same aspect.

There are also architectural gains to using AOP for security. For example, one of the biggest challenges with input validation today is that there are so many interfaces to a complex application. Many large enterprise applications have more than just a single Web HTML interface. A single Web application could have entry points through:

Web services
Rich clients (e.g. applications, applets)
Enterprise-Java Beans
CORBA connections
Other middle-tier connections

Building input validation controls in just one interface (e.g. implementing servlet filters for Web clients) does not prevent attacks from entering in another interface (e.g. Web services). At the same time, attacks such as cross-site scripting only affect certain interfaces (e.g. Web browsers) and not others (e.g. rich applications). With AOP, you define the defenses such as regular expressions in aspects and then define where they should be implemented through pointcuts. This means that some defenses could be pointed at interface code, whereas others could be pointed at business logic (as we did in the NewLead example).

Implementation Details and Performance Impact

So how exactly does AOP work? Well, that depends on the platform you are using. I've discussed AspectJ here for a few very specific reasons:

It is very easy to integrate AspectJ into existing Java applications. AspectJ simply adds Aspects into Java binaries by using a technique called "weaving", which essentially changes the compiled code to add advice at the specified pointcuts. At runtime for Web applications you just need to add the aspectjrt.jar library to your project's WEB-INF\lib
If you are using the Eclipse Integrated Development Environment (IDE), converting an existing Java application to AspectJ is trivial with AspectJ Development Tools [5]
Since AspectJ works at compile time (or at least prior to load/execution time), it is very efficient and does not generally incur significant performance impact

As I mentioned at the start of this article, the Spring Framework also provides AOP support. There are a few major by-design differences with Spring AOP and AspectJ, most notably that Spring works on top of Java and does not require a different compiler. Since Spring's AOP occurs during runtime, there can be a substantial performance penalty. Moreover, Spring AOP support is designed for Spring-controlled beans, which means integrating it into an existing non-Spring-based application can be difficult. That being said, Spring's AOP is still very valuable when AspectJ is not feasible or in applications already using Spring. Spring developers intentionally provided support to integrate Spring's Inversion of Control capabilities with AspectJ's powerful AOP [6].

Next page: What's next?