Of course you can re-factor code instead. The big difference is that that the existing code becomes tightly coupled to the security mechanisms. As soon as you enter authorization calls on your methods or you sanitize input within business logic, you begin to scatter code - and code scattering has been proven to lead to more defects (one such study can be found here: http://www1.cs.columbia.edu/~eaddy/publications/Identifying,%20Assigning,%20and%20Quantifying%20Crosscutting%20Concerns.slides.pdf).
Perhaps more important, each security aspect is centralized. Yes there will be different advice for different fields, but in most applications many of the fields can be categorized together and use the same advice (e.g. text in comment fields, addresses, etc.).

What about using AOP for OWASP Top 10? That’s a paper on it’s own, but let me talk about XSS. Output encoding is one of the most common defenses, and the OWASP Reform project (part of ESAPI if I remember correctly) is a great tool for this. If you can identify the objects that will be used in the presentation tier then you can use AOP to call Reform and encode them just before they are passed to the presentation tier. You could also do this with simple code changes, but the difference with AOP is that you are encapsulating that security concern away from the code. A developer who understands the code base and has a strong application security background could be assigned to develop these aspects.

Logging is properly not the best poster child for AOP because you are right that sometimes it is so context sensitive that it needs to be put within the method code. On the other hand, there are many cases in large applications where standardized logging is happening consistently across many different objects (e.g. “Entering method ..” for all methods within the service layer). Why not take out that standardized logging statement away from each individual object and modularize it? There will still be some logging left in the object, but the code will be less scattered.

ESAPI is a great set of tools. I think it is even better when (some parts of it) are applied with AOP to occur transparently from the rest of the code. I’d also point out that I don’t think AOP can be used for ALL application security concerns (e.g. you can’t use AOP to convert dynamic SQL to prepared statements - that has to be built in).

As for securing WebGoat, I think that is a fantastic idea and something I will implement when I get some free time.

So yes it may be faster to secure code directly, but there are certainly advantages to fixing much of the application without actually changing the code.

I don’t think that AOP and WAF are different implementations of the same thing. A WAF is external to the application, whereas AOP is internal and that alone is a critical difference. The powerful pointcut syntax with mature AOP languages offer developers a degree of granulaity that’s just not possible outside of the application. I also disagree that you need to build the entire functionality from scratch. You do have to build security aspects once, but after they’re built it’s a simple process to reuse them in other applications with different pointcuts and small tweaks to the actual advice. The toolkits you’re talking about are just that, and we hope to have a few of these aspects up for general use on our website later this year.

As you correctly stated, and as mentioned in the article, AOP isn’t a good fit when you don’t understand the application’s internals.

Cheers,

Rohit

AOP just seems like such a cumbersome way of doing security. The root of the problem is that you can’t just mash in security calls according to some pattern. You actually have to think. You need a lot of context too.

For example, in your article, you apply a single regex to an input field to stop XSS. But every field needs a different regex! You can’t use the same rule for output encoding either - you need to encode for the location within the HTML. Even logging (the AOP poster child) needs a custom log message for whatever is happening in the code - particularly for security logging.

For almost every example I can think of (validation, encoding, access control, logging, encryption, concurrency, direct object references, etc…) it would be faster and better to just update the code. Try using something like ESAPI to refactor security into an application instead.

By the way, in response to:

> With a WAF, you can protect against SQL
> injection by stripping out malicious
> characters; with AOP, you can strip out those
> characters and additionally throw an
> exception/error anytime a dynamic SQL method
> is invoked.

I think that transforming input data in any way is very dangerous and nearly impossible to get right. To do it properly you have to have complete knowledge of what the application is doing with the input. If you know this you are better off fixing the application itself. Either that, or you are desperate, in which it is all right because you have no choice.