email article printer friendly more resources

Reduce Your Code Vulnerability
Take advantage of these eight, simple tips to reduce your code’s vulnerability to attacks ranging from buffer overflow, to SQL injection attacks, to decompilation.
by Josh Holmes and Gabriel Torok

February 21, 2006

Technology Toolbox: Visual Basic, C#, SQL Server

Creating secure, reliable applications is an important aspect of any developer’s job.

The hard part, of course, is learning what practices lead to building secure, reliable applications from the outset, as opposed to attempting to graft security onto existing applications. This aspect can be especially daunting because not everyone agrees on what practices create the most secure, reliable applications possible. That said, there is much you can do to reduce the vulnerability of any applications you create, on a variety of levels, from how you design to how you code your applications.

Implementing the eight steps described in this article will go a long way toward helping you not only reduce your code’s vulnerability to attacks, but also help you assess your level of vulnerability to potential attacks—whether from buffer overflows, SQL injections, or something as basic as someone running a decompiler on your application’s binary. Each of these has attacks has potentially serious implications for a given application, as well as your company. The good news is that following some simple, practical steps and guidelines can help you address many of the common mistakes developers make that leave their applications and respective companies open to attacks from a wide variety of sources.

Note that you as a developer don’t work in a vacuum, but in conjunction with one or more designers and testers. It is often your job to integrate efforts laid out by your designers and testers, whose concerns are often slightly different from your own. For example, a designer typically concentrates on things such as making sure that threat models are built, the product has layer defenses, that security failures are logged, and so on. A tester worries about testing attacks that have worked in the past, and known exploits. A developer has a broad set of concerns that include protecting the database, protecting data, and protecting the application. All three entities have important roles to play in your company’s security. As a developer, you often find yourself in the role of helping the designer and tester with their own roles.

Once upon a time, in the not too distant past, security for applications was typically the concern of the developer only. But with the advent of the Web and increased connectivity forming the basis of many businesses partnerships, your security isn’t just the business of your company, but of everyone that does business with your company. It’s important to get the details—large and small—exactly right. These tips will help you do that.

1. Create Your Applications, So They Require the Least Amount of Privilege Necessary.
Most of your users are non-administrators, so they don’t need admin-level privileges. Using limited accounts helps your users and your larger organization protect both your users’ data, as well as the company’s larger interests. For this reason, most good network administrators restrict their users severely.

For example, limited users can’t install ActiveX controls or shell add-ins, so using this option alone can help you eliminate most spyware. Limited users can’t access other user’s data folders, making it impossible for them to delete, manipulate, or read other users’ sensitive data.

But working in an environment where users have limited privileges puts extra pressure on you to make sure your users can use all your application’s capabilities in the intended manner. Little will frustrate a user more than using an application whose features are crippled by their level of network access.

Unfortunately, sometimes you don’t learn what won’t work under your network’s limited access settings until you get your application to a test lab. Worse, running back and forth from your development environment to the test lab to see whether you’ve addressed the issues limited access presents wastes too many cycles. One way to solve this issue is to run tests of your own code as a non-admin, so you find out early in the process what parts of your application don’t work when run with limited privileges.