Year Of Security for Java – Week 38 – Create A Reusable Security Framework

No Gravatar

What is it and why should I care?
Software reuse is a ubiquitous practice in software development. One study says that “80% of the code in today‚Äôs applications comes from libraries and frameworks”. That’s a lot. There is already a lot of research about software reuse and its benefits.

While the research exists, there’s no need to read it to get the basic answer, as any developer will tell you that it’s imperative to create and use reusable code in order to save time and increase quality. We don’t have time to re-write every basic function every time, and if you do that, you also won’t get the benefit of making a single function/feature more robust over time by sending it through all the rigorous quality measures you would with reusable code that’s been evaluated in lots of ways.

Given that reusable code is a must for software development in general, it follows that it would make sense to use it for security-sensitive code as well, right? While that logic seems sound, I’ve seen too much code to believe that it’s happening regularly in many organizations. Usually, at best, what you end up seeing is almost every project has a class named something like “SecurityUtils”, and it will have a couple “filterXYZ” or “escape/encodeXYZ” methods in it. That is the extent of software reuse for security for many, many applications.

Let’s be clear: Fixing XSS is hard. Performing proper access control across your site is hard. Performing appropriate input validation across your application is hard. These things require people, process and technology to be used to solve them properly, and even then, it’s still going to be a difficult process. Security is a difficult thing to get right (just like other aspects of software), so we may as well take any help we can get.

What should I do about it?
In order to help with some of these hard problems, we can leverage reusable frameworks for security. The idea is simple: those controls you put in place to protect your application, say from CSRF (like CSRFGuard), are likely useful for other applications in your organization. Of course, other teams might have a better solution for a different problem, such as a good context-aware encoding solution for XSS (like JXT). If you pool your resources across developers on your team, organization, or even the world (open source software), you get a lot of reuse of code. Additionally, the code is more likely to be good code necessarily since, with many people seeing it and using it, bad code should get weeded out more quickly. If you’re applying your other good processes, such as code review and testing, the quality continues to go up.

I do want to make a special note at this point. I’ve heard lots of folks (including my younger self) argue that we need more secure coding examples, ie. snippets. While I think there is certainly value in this approach (especially for those writing the reusable frameworks), I’ve come to believe that this in and of itself is not particularly useful. A developer will use your framework if it’s useful, provides value to him/her, and doesn’t get in the way (buggy or too difficult to use). A developer will, in general, NOT come and grab your snippet of code for doing XYZ. Snippets can work in very constrained environments and use cases, but I think the general approach should be towards the framework model.

At this point, I’d be remiss if I didn’t mention the excellent ESAPI library. It has about 10 useful controls that cover various parts of security across your applications. It’s in the process of being re-architected to make it more modern, but the idea that there is a security library that offers a holistic approach to security is awesome. If you’re not using ESAPI, give it a try or at least a look. If you’re responsible for building a security related framework, start with ESAPI or at least look at it for inspiration. It will certainly provide value.

In conclusion, software reuse is an old tried and true concept. There are lots of benefits to be realized from it. It’s common for standard application development frameworks, but there aren’t a lot of security libraries out there. Reuse applied to security makes sense just like it does for other features. Building a framework with a comprehensive approach to security is a big win for both development and security, so give it a try.

Be Sociable, Share!

Technorati Tags: , ,

One thought on “Year Of Security for Java – Week 38 – Create A Reusable Security Framework

Leave a Reply

Your email address will not be published. Required fields are marked *