Security is Everybody’s Business

Don't get caught with vulnerable code. These books can help you spot potential holes.

• By Mike Gunderloy
• 03/01/2005

Koch was referring to the collective security of the European nations, but the quotation is just as apt, these days, for the application developer. It seems like all of us really need to understand application security, whether or not that was part of our original training. Fortunately, a pair of new books have recently crossed my desk, purporting to help with this need: Programmer’s Ultimate Security DeskRef by James C. Foster (Syngress) and The .NET Developer’s Guide to Windows Security by Keith Brown (Addison-Wesley). Should you have these titles on your shelf?

Threats Lurking Everywhere
The first of these books, Programmer’s Ultimate Security DeskRef is not designed to be read cover-to-cover. Rather, as the title should tip you off, it’s a reference -- in this case, to dangerous functions that you need to think twice before calling. Foster covers a raft of languages here:

• ASP
• C
• C++
• C#
• ColdFusion
• JavaScript
• Jscript
• LISP
• Perl
• PHP
• Python
• VBA
• VBScript

For each potentially vulnerable function -- for example, swprintf in C -- Foster gives an analysis broken down into standardized parts. There’s a function prototype and an explanation of the use of the function. After that comes an analysis of the risk: What attacks are you opening yourself up to if this function appears in your code? Foster also recommends alternatives or mitigation practices, and rates the impact of each potential hole.

Browsing the section of the book for your chosen language may introduce you to some attacks you hadn’t thought about. For example, if errors automatically log a disk file, can bad people fill your hard drive by just provoking lots of errors? Is a naïve random number generator that lets people guess the next number a problem? (What if you use it to generate random passwords?)

I see this one mainly as a book for developers who are new to the concept of writing secure code. While it’s true that there are dangerous functions in almost any language, a good static code-analysis tool will warn you of them -- and such a tool doesn’t require you to read and remember. But as a survey of what can go wrong, this book might help.

Back to Basics
The .NET Developer’s Guide to Windows Security is also a reference title in that it’s a compendium of short bits of information rather than a single unified story. However, Keith Brown’s writing is engaging enough that many developers will probably want to read the book straight through. That’s a good thing, because most of us will learn things from the exercise.

Note the title of the book carefully: This is not a guide to .NET security. So you won't find code access security or the details of setting up your web.config file to support impersonation here (for that sort of code-slinging topic, try Programming .NET Security by Adam Freeman & Allen Jones (O’Reilly, 2003)). What you will find is a great set of explanations of fundamental security concepts as they are implemented on Windows. This is information that just about every developer needs, but very few comprehend fully.

Here's a quick test. You do not need this book if you can easily define all of the terms in this list: Window station, null session, security descriptor, ACL, protocol transition, token, CurrentPrincipal. Confused? Lost? Then read on.

The book is broken up into 75 short topics arranged in six parts:

• The Big Picture
• Security Context
• Access Control
• COM(+) and Enterprise Services
• Network Security
• Miscellaneous

This arrangement makes it really easy to open up and read just the few pages you need when you're struggling with something like storing passwords or running a program as another user. Keith's writing is exceptionally clear and his instructions and examples (and fairly rare bits of code) are all illuminating.

Along the way, he makes a strong pitch for running as a non-admin in your day to day development work. This is a somewhat-controversial recommendation, because many of the tools we use are not written so as to work when used in that fashion. Still, it's a worthwhile exercise, and the instructions here will help you get over the bumps faster. The payoff is threefold: You learn how painful software is for non-admins, you learn how to write software that non-admin users can run, and you protect your own computer from raging malware.

Books Are Not Enough
No matter how many books you read about application security, though, books alone are not enough to make you a developer of secure code. Here are some other recommendations that I think will help:

• Stay informed. The security landscape is far from static. No matter how much you know about today’s common attacks, the reality is that a whole new class of vulnerabilities might be discovered tomorrow. In addition to this sort of broad knowledge, you also need to keep track of the micro level: what’s been reported lately with the applications that you actually use on a day-to-day basis? Security mailing lists, such as BugTraq http://www.securityfocus.com and NTBugTraq http:ntbugtraq.com are a good starting point. Another good (though overwhelming) resource is Infosec Daily http://infosecdaily.net/, which brings together security news from a variety of sources.
• Use Code Reviews. One of the best tools for catching bugs of all types (not just security bugs) is the code review. In a formal code review, a team sits down to look over the code of a procedure, searching for problems according to a standard checklist. More informal code reviews, sometimes consisting of of just having a more experienced developer look over code before it’s checked in, can also help. The basic notion is that a fresh pair of eyes can spot problems that you’ve long since ceased to see in your own work. Getting this sort of reality check is a useful thing.
• Use Automated Tools. With the rise of security concerns in recent years, there has been a corresponding rise in tools that look over your code for problems. These range from free tools like Microsoft’s FxCop http://www.gotdotnet.com/team/fxcop/ to more expensive commercial offerings such as DevPartner SecurityChecker http://www.compuware.com/products/devpartner/securitychecker.htm from CompuWare. These tools may check for problems beyond security issues, and use a variety of techniques, from static code analysis to deliberately attempting to exploit known vulnerabilities in a running application. An automated tool can be an excellent way to get warnings of security issues and to prevent regression bugs in this area.
• Keep Security in Mind. If secure code is your goal, then secure code needs to be one of your criteria right from the start of the project. Rather than attempting to bolt on security features at the time of the final test pass, you need to design with security in mind right from the start. The first specification of the product is a good time for the first security review, and you should keep your security plan updated as you move through the entire development process.

There are times when I think we’re on the verge of turning a corner in our quest for secure code. Between the tools and the development environments, more and more security is being baked in for us. But tool support doesn’t excuse you from needing to know what’s going on in your own products. Whether you start with one of the books here, a mailing list, or a Web site, I urge you to get informed (and stay informed) about the security landscape.

Are you sick of security? Or still eagerly learning? Write me at [email protected]. I’ll use the most interesting comments in a future column.