Aspect-Oriented Programming’s Ironical Relation to Information Security

September 14, 2018

by Bradley C. Watson, Ph.D., Program Chair, Management Information Systems

Software programming methodologies come, and, presumably, though not yet proven, they go. Existent evidence points in the opposite direction, methodologies never go – to this day, many would-be programmers first learn to employ the methodology of the programming pioneers fondly known as “spaghetti coding,” or, said differently, write a bunch of lines of code, and pray it works. And this is true despite decades of attempts to eradicate this approach by very capable, very venerable theorists and practitioners of the trade*. Given the lack of final success in achieving a universally accepted approach to software construction, in this text, we will forge on towards the goal, focusing on a recent entrant into the field of programming methodologies: “Aspect-Oriented Programming” (AOP). Specifically, our subject of interest will be the relationship of AOP and information security.

The Aspect-Oriented Programming paradigm was developed to solve the problem of cross-cutting concerns. For instance, in an organization, some people might be paid by the hour, that is, they are hourly workers. Hourly workers can be found in all functional departments of most organizations – human resources, finance, marketing, production, etc. Keeping track of hours worked by hourly workers is not a function integral to the functions of any of the departments. It is, therefore, a cross-cutting concern – a function that is necessary to the organization that must be performed across all departments but is only a distraction from the actual work of each department. In the world of programming such cross-cutting concerns are not reliably dealt with in any traditional methodology before the advent of AOP.

As it happens, in the world of software, the function of providing information security is a cross-cutting concern. There is no part of a program that does not have to behave in such a way as information security is maintained. Which means, given that Aspect-Oriented Programming is intended for implementation of code to handle cross-cutting concerns and information security is a cross-cutting concern, then the obvious conclusion is that AOP should be used to implement information security within software. But there is a catch, a quite serious catch.

To understand the catch, it is necessary to understand the basic mechanism that allows AOP code to handle cross-cutting concerns: post-development time injection of code into programs needing support for cross-cutting concerns. In other words, application programmers develop their code, ignoring cross-cutting concerns such as information security. Then other programmers create AOP code that is injected into the application code at all the right places for handling cross-cutting concerns. This code can be injected statically, as part of the compilation process or dynamically, as part of the launch process. The latter approach is the one most often used when it is important to make sure the absolute latest version of code is running. Injecting security code is such a case. Which fact leads to the catch inherent in using AOP to handle security in software.

To dynamically inject code into a live program, there must exist a mechanism that makes that happen. Once there is such mechanism, then a door is opened for injection of code that either is itself some form of malware or is subject to being successfully attacked by malware. And so there now exists the problem of who is watching the watcher.

AOP is the best answer today to implementing code that handles cross-cutting concerns, such as information security. But using AOP to implement security enforcement leads to the opening of a door for malware to enter the programs being secured. Which means we need a watcher to watch the watcher.

  *For instance, in March 1968, Dr. Edsger Dijkstra, argued very convincingly, including employing mathematical proofs that the primordial coding methodology should be anathema to all programmers. As a substitute, Dr. Dijkstra, in his now highly honored letter to the editor of Communications of the ACM entitled “Go To Statement Consider Harmful,” recommended a then new form of programming known as “structured programming”. That was 50 years ago. Fast-forward to now, and what one sees is that structured programming was but the start of the quest for “The Programming Methodology”.

References

Dijkstra, Edsger W. (March 1968). "Go To Statement Considered Harmful". Communications of the ACM (PDF). 11 (3): 147–148.