News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
Most Read Latest News Blog Resources

A Taxonomy of Coding Errors




June 1, 2006 — 
Programmers have the wrong idea about security. All too often, they see security as something that’s external to the program—something to do with firewalls and routers and viruses and trojans. In fact, almost all of the real security “exploits”—the ones that bring down not just Web sites but whole corporate networks, the ones that let hackers harvest sensitive client information from your database—come from exploiting bugs in your software.

Put another way, the only way for a system to really be secure is to build it to be secure, and to test it thoroughly with security in mind. The most secure

systems are the ones that are just plain built well: well thought out, well programmed, well tested. If you’re careful about both the software you’re building and the way you build it, the system will be inherently secure.

Unfortunately, most of the programs that are written nowadays are not exactly well done. The security problem is particularly nasty in the world of Web services, which are designed from the ground up to circumvent firewalls. This is what happens when you approach security in a wrongheaded way. “Oh, no,” says the IT security cop. “You can’t put a hole in my firewall for your paltry application!” “No problem,” says the wily programmer. “I’ll just tunnel everything through port 80.”

A Web service is really nothing but a way to make a function call directly into your application server right through the firewall, and I can guarantee that many of the functions called in this way will have exploitable bugs that can bring down your server, or worse. There are a bunch of standards out there attempting to address the access problem, but none of these standards protects you from bug-induced security holes.

AJAX provides another hole you can drive a truck through. The HTTP communication between an AJAX Web client and server is effectively a set of function calls wrapped in XML (or not). These AJAX calls have effectively no security infrastructure around them, so a hacker who’s pretending to be the Web page that you served has carte blanch to wreak havoc. The average hacker is not going to be nearly as polite with your AJAX infrastructure as the pages that you wrote.

So what’s a mother to do?
Brian Chess at Fortify Software, along with Katrina Tsipenyuk (also at Fortify) and Cigital’s Gary McGraw, have put together what amounts to a checklist of the most common errors that cause security vulnerabilities

(vulncat.fortifysoftware.com). Their paper, “Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors,” describes their goal nicely: “We want to help developers...understand common types of coding errors that lead to vulnerabilities. By organizing these errors into a simple taxonomy, we can teach developers to recognize categories of problems that lead to vulnerabilities and identify existing errors as they build software.”

It’s written to be accessible to programmers, unlike the vast majority of security-related verbiage. (Remember, most of the folks who write this stuff are into things like crypto—they like to obscure things.) The taxonomy is a list of programming problems and programming solutions—things that any programmer can understand immediately.

On the downside, the taxonomy needs many more examples and more in-depth explanations about why particular problems are indeed problems. It’s not clear, in places, what the security implications of a particular bug actually are. (“Yeah, it’s a bug, but so what?”)

For example, the taxonomy correctly points out that a finalize() call should always chain to super.finalize(). It does not talk about why it’s a security problem not to do so (base-class objects may not give up system-level resources since their finalizers won’t be called, and the system could eventually crash because too many resources are allocated).

Moreover, the taxonomy doesn’t discuss other important issues that surround finalize(). For example, you could argue that using finalize() at all is a security flaw, since it slows down garbage collection by a couple of orders of magnitude. An attacker who hit on a way to create many objects that required finalization could bring your system to its knees.

My hope, then, is that someone will take this already-valuable list and run with it, expanding it out into a full-blown book that describes these issues in depth. Even without this extra work, the list as it stands is immensely valuable.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/29344
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading