Customer Success Testimonial: Recovery is Everything

Comment Aspect-oriented programming (AOP) is a paradigm that is quickly gaining traction in the development world. At least partially spurred by the popularity of the Java Spring framework [1], people are beginning to understand the substantial benefits that AOP brings to development.

While several others have tied AOP to security [2][3], I aspire to raise awareness amongst my information security colleagues that AOP can have a substantially beneficial impact on application security. I'm convinced that, if more of us understand it, we'll be in a better place to work with developers to create secure applications and perhaps, more importantly add security into existing insecure applications.

What is AOP?

Many people don't really understand what AOP is. I used to think that AOP was a replacement for object-oriented programming (OOP), so I categorically rejected it without further examination. This notion is completely wrong: AOP compliments OOP. It centers on cross-cutting concerns, or aspects - parts of code that are common to many different objects, of which logging is the canonical example. Using an AOP language (such as AspectJ) or libraries (such as Spring), programmers can code this functionality once and then define where to weave it into existing objects. An example should help clarify this. Suppose we have the following Java classes:

Here we can see that logging functionality is exactly duplicated in two different classes. With AOP we do something like this (note syntax is simplified for clarity):

We now create a LogInterceptor aspect that we inject before and after any call to any Class (ignore details on how this injection happens for now, we'll discuss this shortly). We have essentially created a proxy for method calls. The important thing to note about this example is that both MyFirstClass and MySecondClass have no knowledge and no dependency on LogInterceptor. In a real application that logging code is probably replicated in hundreds of different class files, so centralizing it like this will reduce a substantial amount of source code. This has major ramifications, since we can now add security aspects to applications without having to modify existing code.

Security Implications

Several security-relevant cross-cutting concerns are found scattered throughout the application logic:

• Logging
• Access control
• Error handling
• Transaction management
• Session management (in some cases)
• Input/output validation

Using AOP, we can separate a good large chunk of these concerns from the code base and centralize them. Sure there will be some cases where centralization is not possible (e.g. very specific error handling), but by and large, AOP allows developers to concentrate on the elusive Plain Old Java Object (or whatever language you are using). A POJO is essentially the code that developers were taught to write from day one; code that only focuses on business logic and not other concerns such as input validation, logging, access control, and complex error handling. Cleaner code is less prone to bugs - including security bugs.

Another implication of this is that subject matter experts can be responsible for coding the security aspects. People who have been specifically trained, and have experience in a domain such as session management or access control, can handle the lion's share of that code in an entire project or one component of the project.

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery

Next page: Real Example: Adding Input Validation to a Legacy Application