Section 27.4. DISCUSSION

27.4. DISCUSSION

27.4.1. A Positive Experience

Optimizing the separation between application and security logic is an important objective. Our experience with aspect-oriented programming confirms that this technology enables us to achieve this goal. Several smaller case studies made us confident about the potential of this technology, but the actual implementation of the FTP server lifted our confidence. This is not a toy application. Nevertheless, we were able to fully extract security-related code, producing an isolated basic application. This was done despite the fact that the FTP server was not our own code.

AOP has two important advantages for security. Compared to the well-known technique of modularizing the security mechanism, AOP allows us to raise the level of separation by explicitly focusing on the binding between application and security infrastructure. As a result, the average application developer is no longer involved with security (i.e., he no longer has to invoke security mechanisms himself). This job can be left completely to a focused security expert. A second key advantage relates to the security policy rather than to the infrastructure. Using AOP, the overview of the actual security deployment policy (i.e., defining which mechanisms are used and where they are used) is gathered into a few configuration files. Consequently, compared to object-oriented security engineering, a security expert can more easily verify whether a required security policy is valid within a concrete application.

Some practical limitations of the current tools limit the success of our approach. During different case studies, we experienced some technological restrictions with (version 1.1 of) AspectJ, including limitations of the mechanism to select join points, as well as some essential restrictions in the generalization phase toward the framework. To briefly sketch the first problem, a pointcut is conceptually equivalent to a query on an abstract syntax tree representation of the program. The AspectJ tool provides a set of keywords to describe pointcuts. Unfortunately, some queries (e.g., all the classes that override one or more methods of their parent classes) cannot be expressed using this keyword set, which leads to the construction of less elegant workarounds. Regarding the second problem, aspects, and in particular pointcuts, can be made abstract, but they can only be reused in child aspects of the abstract aspect in which they were defined. In our opinion, the primary cause of this restriction is the forced combination of the specification of behavior and composition logic. Since AspectJ aspects are not fully polymorphic, aspect reuse is hard to achieve. We refer to [10, 12, 31] for a more in-depth discussion of these problems. Some of the restrictions we encountered (e.g., the first one) are due to the current implementation of the tool, while others (the second one) are more fundamental issues that are inherent to the basic concepts behind the tool. As AOP is an active research area, this is what one should expect. Case studies, as included in this chapter, should drive the environments to the next stage. Instead of focusing on specifics related to AspectJ, we will focus in the next paragraphs on the requirements for the AOP domain as a whole.

27.4.2. Requirements for AOP Environments

Define the optimal design process

AOP is a new programming paradigm building on established paradigms such as object-oriented programming. Unfortunately, this hinders the average programmer trying to become productive. Conceptually clean and understandable design processes can help alleviate this problem. Obviously, the rapidly changing character of the AOP technology as it is today does not simplify the development of such clean processes. Even with the existence of such processes, the implementation of security aspects still requires detailed knowledge of the security infrastructure. Apart from enabling improved modularization, AOP technology does not help here.

Watch performance

With AOP, the modules of a program are composed into an executable artifact. Many tools currently transform an aspect-based program into a classical (class-based) object-oriented program. This results in extra methods and extra method invocations relative to the equivalent handcrafted program. Moreover, execution of a transformed program often requires extra run-time libraries. Development and language support often involve a trade-off between efficiency and ease of use. Historically, the transition from procedural to object-oriented programming involved the same trade-off. The important issue here is that these languages or tools disable some of the optimization capabilities of the programmer and replace them with a more expressive programming model. While we did not experience unacceptable penalties when testing and deploying the aspect-based FTP server, we stress the relevance of this subject matter in the long run, as technology and tools mature.

For AspectJ in particular, the definition of advice on security-sensitive methods results in the insertion by the AspectJ compiler of one or more extra calls. For instance, a before advice is implemented using a method proxy, which requires extra indirection. Therefore, the generated code is less efficient and introduces more overhead than a direct implementation. Unfortunately, this is the price of generality. Building a less general aspect and a more complex combination tool could improve this situation.

Support testing and debugging

Debugging involves code assessment and correction. In a typical design process, all sorts of tests (black box, white box, stress, and so forth) are used to validate modules. Likewise, when using AOP, the programmer should have the ability to test aspects. This testing must include both the behavior of the aspect, which is part of the security infrastructure, and the binding within different environments (the security policy). Testing aspect behavior is comparable to but different from traditional object testing. Testing the binding is difficult. It must include both information about the deployment environment (type information and possibly context information) and specific application binding information (specific state transferred between different aspects). Today, research on aspect testing is in a very early state, and practical tools are non-existent. Locating erroneous code is complicated by the fact that the running code does not correspond to the written code. Fortunately, current AOP research also focuses on tools that provide a clear visualization of the run-time interaction between aspects and the core application.

Toward trusted code

From a security viewpoint, the explicit separation and consequent composition of security aspects and application objects raise the extra risk of introducing new security holes. In particular, the specific combination mechanisms used in the tool and the tool itself must be part of the trusted computing base, and therefore, they are a primary target for attacks. Let us consider the case of authorization: It should not be possible for a client to directly invoke the end-functionality of a server, circumventing the authorization policy. In this respect, security demands absolute guarantees that the combination process (a.k.a. weaving) cannot be bypassed. At the moment, it is not clear how such guarantees can or will be enforced. This is an important topic for further research.

Specifically, in the context of AspectJ, the output of the actual tool cannot be trusted because the original functionality, without the new aspect code, is simply moved into a new method with a special name. Clever attackers knowing the modus operandi of the tool can exploit the code very easily. As explicitly stated by the tool manual, this problem only arises if not all source code is under the control of the AspectJ compiler. Unfortunately, for practical real-world situations, such as large development processes or dynamic modification of an application, this requirement is often impossible to fulfill.