Endpoint Protection

 View Only

Aspect-Oriented Programming and Security 

Oct 16, 2007 02:00 AM

by Rohit Sethi

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.

 

Real Example: Adding Input Validation to a Legacy Application

Of course, using AOP to its full potential on existing applications would entail a near re-write of the application -- something that is often not feasible. What should be more interesting to the security community is how to use AOP in an existing code base for security functions that are not already implemented.

Let's take a look at an existing Customer Relationship Management (CRM) application that has several Cross-site Scripting (XSS) vulnerabilities. When I try to enter in a new sales lead in one of the web forms with the description <script>alert(document.cookie)</script>.

I get:

This form is vulnerable to XSS. Since I know there are several parts to the code that share this vulnerability, I decide that I want to protect the NewLead object in the business layer by adding input validation to any time that a setter method on a String attribute is called. Here is a snippet of the NewLead class that has several setter methods:

I created the following code in programming language AspectJ, which can be easily integrated into existing Java applications -- to mitigate the XSS in the application. Don't worry if this looks confusing. I'll explain the example in detail:

public aspect InputValidator-

An Aspect in AspectJ closely resembles a class. It can have instance variables and methods inside of it. There are some key differences, however, including pointcuts and advice.

pointcut myPointcut(String argument): execution(* NewLeadBean.set*(String)) && args(argument)-

A pointcut in AOP defines where we want our aspects to interact with the rest of the code. In this case, our pointcut myPoint() is invoked anytime anyone calls setName(), setSalesStage(), etc. from the NewLeadBean class. The syntax NewLead.set*(String) is intuitive: any method that is part of the NewLead class, begins with "set", and has a single string parameter.

The && args(argument) part is saying that we want to save the string parameter to a variable named argument (e.g., if somebody called myNewLeadObject.setName("rohit") then rohit would be saved to the variable argument). Pointcuts can get quite complicated -- for a detailed discussion please see the AspectJ programming guide[4].

before (String argument): myPointcut(argument)

This is what we call "advice". It is saying, before the invocation of myPointcut (i.e. before NewLead.set*() is called), execute the following code. Note we could also have specified after or around (i.e. both before and after) innovation of the pointcut. The argument is the string that's passed in as a parameter. This example shows that we are taking the string argument (in our case, "rohit") and checking it to see if it passes white-list validation [7] with a regular expression checker. If I had entered in something along the lines of <script>alert(document.cookie)</script> as the name of my sales lead, I would have seen the following page on screen:

This shows that the aspect successfully stopped the attack.

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].

What's Next?

The potential uses for Aspect-oriented programming in application security are enormous. Here are a couple of other applications AOP in security:

  • Implement access control independently of application logic. Instead of having explicit checks such as checkAccess(User) in each sensitive function, you can achieve this through aspects and let developers focus on business logic
  • Implement application security policies such as explicitly forbidding programmers from calling dynamic SQL libraries (e.g. executeQuery()). Whenever that library is called, you can use aspects to throw an exception and record exactly where the offending call came from

Developers are already moving towards adopting AOP. JBoss, WebSphere, and WebLogic either have existing functionality to integrate AOP or have made announcements to do so in the future. Now the application security community needs to follow suite by providing guidance on how AOP can be used in a security context.

We can achieve this by ensuring we add AOP to our application security training curriculums (something we’ve included in our new class for SANS and I hope other training companies do the same), do more research on how AOP works at securing applications in production (including benchmarks for performance impact), and providing more example code for developers to learn from.

Footnotes

  1. Aspect-oriented programming with Spring; Spring Framework: http://www.springframework.org/docs/reference/aop.html
  2. Applying Aspect-Oriented Programming to Security; Viega, Bloch, and Chandra; Cutter IT Journal: http://www.ccs.neu.edu/home/lieber/courses/csg379/f04/resources/aop-cutter.pdf
  3. Towards a security aspect for Java; Farías, Andrés: http://www.emn.fr/x-info/emoose/alumni/thesis/afarias.pdf
  4. AspectJ: http://www.eclipse.org/aspectj/
  5. AsjectJ Development Tools: http://www.eclipse.org/ajdt/
  6. Using AspectJ with Spring Applications; Spring Framework Reference Guide, http://static.springframework.org/spring/docs/2.0.x/reference/aop.html#aop-using-aspectj
  7. Data Validation, OWASP, http://www.owasp.org/index.php/Data_Validation#Accept_known_good
    public class MyFirstClass { public void amethod (String bar) { 		Logger.doLoggingBefore(); 		//business logic goes here 		Logger.doLoggingAfter(); 	} } public class MySecondClass { 	public void function (Object arg) { 		Logger.doLoggingBefore(); 		//business logic goes here 		Logger.doLoggingAfter(); 	} } public aspect LogInterceptor {  public Object invoke(){ Logger.doLoggingBefore(); 		method.execute();  		Logger.doLoggingAfter(); 	  } } public class MySecondClass { 	public void function (Object arg) { 		//business logic goes here 	} } public class MyFirstClass { 	public void amethod (String bar) {	       		//business logic goes here 	} }

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.