On the usage of AOP for vulnerability mitigation

This blog entry is a follow-up of the previous entry presenting a novel eclipse plugin for vulnerability detection which leverage knowledge from involved parties : Security Vulnerabilities Detection and Protection Using Eclipse.

The approach we have described in the first blog entry comprises the automatic discovery of vulnerability and weaknesses in the code.  We integrate a protection phase tied to the analysis process which guides developers through the correct and semi-automatic correction of vulnerabilities previously detected. It uses information from the static analysis engine to know what vulnerabilities have to be corrected. Then it requires inputs from the developer to extract knowledge about the context, like in the first Figure. These steps allow to gather places in the code where to inject security correction. The security correction injection uses Aspect-Oriented Programming paradigm (AOP), which is a paradigm to ease programming concerns that crosscut and pervade applications. The goal is to bring proper separation of concerns for cross cutting functionalities, such as security. Thus, code related to a concern is maintained separately from the base application.  The main advantage using this technology is the ability to intervene in the control flow of a program without interfering with the base program code.

Fig 1. plugin view for gathering context for vulnerability protection

By adopting this approach, we reduce the time to correct vulnerabilities by applying semi-automatic and pre-defined mechanisms to mitigate them. We use the component to apply protection code which is mostly tangled and scattered over an application. In applications, correcting a security vulnerability is not trivial. Different refactoring are possible depending on the issue. For instance, the guides for secure programming advise SQL prepared statement to prevent SQL Injection. But developers might be constrained by their frameworks to forge SQL queries themselves. Therefore, developers would try another approach such as input validation and escaping of special characters.

We assist developers by proposing them the best automated solution possible.  For the previously mentioned correction, our integrated solution would propose to mitigate the vulnerability with an automatic detection of incoming, unsafe  and unchecked variables. The developer does not need to be security expert to correct vulnerabilities as our approach provides interactive steps to generate AOP protection code. An example of protection code is given in the second figure, with a fixed part corresponding to the behavior for protection (or the advice in AOP terms), then a second part which is more dynamic and error-prone corresponding to the places where protection code has to be activated (or the pointcuts in AOP terms). Although semi-automation simplify the process to introduce protection code, the technique can introduce several side-effects if the developers are not following closely what is generated. The plug-in gives an overview for the developer of all corrected vulnerabilities, allowing him to manage and re-arrange them in case of need. Currently, the prototype does not analyze interaction between the different protection code generated.

Fig 2. Example of correction snippet generated for a malformed input

We allow better understanding from an user point of view of the different vulnerabilities affecting the system, and we guide the developer towards more compliance in its application. The protection code can be deployed by security expert teams and change without refactoring. We presented in these two entries how to overcome several security vulnerabilities using a combination between a static analyzer that assists developers to report security vulnerabilities and a semi-automated correction of these findings with AOP. We have designed this plug-in for an improved awareness of security concerns from a developer point of view. The automated correction might not be the best choice everytime, and we encourage developers to look further in vulnerabilities’ descriptions. Also, we do not want developers believe our solution is bullet-proof. It leads to a false sensation of security which the opposite of our goal. We are still investing time to obtain more automation in systematic mitigation of security vulnerabilities.

Acknowledgment

This is a joint work with Marco Guarnieri, a former intern at SAP Labs France and Paul El’Khoury, member of SAP corporate security team in SAP AG Walldorf.