Top 25 Programming Errors That Kill Network Security

by Don Sears

MediumTraffic accidents occur when two vehicles attempt to use the exact same resource at almost exactly the same time, like the same part of the road. Race conditions in your software aren’t much different, except an attacker is consciously looking to exploit them to cause chaos or get your application to cough up something valuable. In many cases, a race condition can involve multiple processes in which the attacker has full control over one process.

HighIf you are handling sensitive data or you need to protect a communication channel, you may be using cryptography to prevent attackers from reading it. You may be tempted to develop your own encryption scheme in the hopes of making it difficult for attackers to crack. This kind of grow-your-own cryptography is a welcome sight to attackers.

HighMany Web applications have implemented redirect features that allow attackers to specify an arbitrary URL to link to, and the Web client does this automatically. This may be another of those features that are “just the way the Web works,” but if left unchecked, it could be useful to attackers in a couple important ways. First, the victim could be automatically redirected to a malicious site that tries to attack the victim through the Web browser. Alternately, a phishing attack could be conducted, which tricks victims into visiting malicious sites that are posing as legitimate sites. Either way, an uncontrolled redirect will send your users someplace that they don’t want to go.

HighWhile software often runs under hard limits of the system (memory, disk space, CPU), it’s not particularly polite when it uses all these resources to the exclusion of everything else. And often, only a little bit is ever expected to be allocated to any one person or task. The lack of control over resource allocation is an avenue for attackers to cause a denial of service against other users of your software, possibly the entire system. In some cases, this can be leveraged to conduct other more devastating attacks.

MediumIf you have critical programs, data stores or configuration files with permissions that make your resources readable or writable by the world, thats just what they’ll become. While this issue might not be considered during implementation or design, sometimes that’s where the solution needs to be applied. Leaving it up to a harried system administrator to notice and make the appropriate changes is far from optimal, and sometimes impossible.

MediumMaybe you only access a download site that you trust, but attackers can perform all sorts of tricks to modify that code before it reaches you. They can hack the download site, impersonate it with DNS spoofing or cache poisoning, convince the system to redirect to a different site, or even modify the code in transit as it crosses the network. This scenario even applies to cases in which your own product downloads and installs its own updates. When this happens, your software will wind up running code that it doesn’t expect, which is bad for you but great for attackers.

CommonIn countless action movies, the villain breaks into a high-security building by crawling through heating ducts or pipes, scaling elevator shafts, or hiding under a moving cart. This works because the pathway into the building doesn’t have all those nosy security guards asking for identification. Software may expose certain critical functionality with the assumption that nobody would think of trying to do anything but break in through the front door. But attackers know how to case a joint and figure out alternate ways of getting into a system.

HighIn languages such as C, where memory management is the programmer’s responsibility, there are many opportunities for error. If the programmer does not properly calculate the size of a buffer, then the buffer may be too small to contain the data that the programmer plans to write—even if the input was properly validated. Any number of problems could produce the incorrect calculation, but when all is said and done, you’re going to run headfirst into the dreaded buffer overflow.

CommonIn the real world, 255+1=256. However, to a computer program, sometimes 255+1=0, or 0-1=65535, or maybe 40,000+40,000=14464. You don’t have to be a math whiz to smell something fishy. Actually, this kind of behavior has been going on for decades, and there’s a perfectly rational and incredibly boring explanation. Ultimately, its buried deep in the DNA of computers, which cant count to infinity even if it sometimes feels like they take that long to complete an important task. When programmers forget that computers don’t do math like people, bad things ensue—anywhere from crashes, faulty price calculations, infinite loops and execution of code.

HighIf you use chatty error messages, then they could disclose secrets to any attacker who dares to misuse your software. The secrets could cover a wide range of valuable data, including personally identifiable information (PII), authentication credentials and server configuration. Sometimes, they might seem like harmless secrets that are convenient for your users and administrators, such as the full installation path of your software. Even these little secrets can greatly simplify a more concerted attack that yields much bigger rewards, which is done in real-world attacks all the time. This is a concern whether you send temporary error messages back to the user or if you permanently record them in a log file.

HighMurphy’s Law says that anything that can go wrong will go wrong. Yet it’s human nature to always believe that bad things could never happen, at least not to you. Securitywise, it pays to be cynical. If you always expect the worst, then you’ll be better prepared for attackers who seek to inflict their worst. By definition, they’re trying to use your software in ways you don’t want.

CommonIf you use untrusted inputs when calculating an index into an array, then an attacker could provide an index that is outside the boundaries of the array. If you’ve allocated an array of 100 objects or structures, and an attacker provides an index that is -23 or 978, then “unexpected behavior” is the euphemism for what happens next.

CommonWhile many of the Top 25 on the list are not unique to a single programming language, here is??ía notable exception. The idea was simple enough: You can make a lot of smaller parts of a document (or program), then combine them all together into one big document (or program) by “including” or “requiring” those smaller pieces. This is a common enough way to build programs. Combine this with the common tendency to allow attackers to influence the location of the document (or program)—perhaps even on an attacker-controlled Website, if you’re unlucky enough—then suddenly the attacker can read any document (or run any program) on your Web server. This feature has been removed or significantly limited in later versions of PHP, but despite the evidence that everything changes on the Internet every two years, code is forever.

CommonA popular insult is: “Take a long walk off a short pier.” One programming equivalent for this insult is to access memory buffers using an incorrect length value. Whether you’re reading or writing data as you march down that pier, once you’ve passed the boundaries of the buffer, you’ll wind up in deep water.

MediumHard-coding a secret password or cryptographic key into your program is bad manners, even though it makes it extremely convenient—for skilled reverse engineers. While it might shrink your testing and support budgets, it can reduce the security of your customers to dust. If the password is the same across all your software, then every customer becomes vulnerable if (rather, when) your password becomes known. Because it’s hard-coded, it’s usually a huge pain for system administrators to fix.

HighWhenever sensitive data is being stored or transmitted anywhere outside of your control, attackers may be looking for ways to get to it. Thieves could be anywhere—sniffing your packets, reading your databases and sifting through your file systems. If your software sends sensitive information across a network, such as private data or authentication credentials, that information crosses many different nodes in transit to its final destination. Attackers can sniff this data right off the wire, and it doesn’t require a lot of effort. All they need to do is control one node along the path to the final destination, control any node within the same networks of those transit nodes, or plug into an available interface.

MediumYour software is often the bridge between an outsider on the network and the internals of your operating system. When you invoke another program on the operating system, but you allow untrusted inputs to be fed into the command string that you generate for executing that program, then you are inviting attackers to cross that bridge into a land of riches by executing their own commands instead of yours.

CommonYou may think you’re allowing uploads of innocent images (rather, images that won’t damage your system—the Interweb’s not so innocent in some places). But the name of the uploaded file could contain a dangerous extension such as .php instead of .gif, or other information (such as content type) may cause your server to treat the image like a big honkin’ program. So, instead of seeing the latest paparazzi shot of your favorite Hollywood celebrity in a compromising position, you’ll be the one whose server gets compromised.

WidespreadWhile data is often exchanged using files, sometimes you don’t intend to expose every file on your system while doing so. When you use an outsider’s input while constructing a filename, the resulting path could point outside of the intended directory. An attacker could combine multiple “..” or similar sequences to cause the operating system to navigate out of the restricted directory and into the rest of the system.

HighIn countries where there is a minimum age for purchasing alcohol, the bartender is typically expected to verify the purchaser’s age by checking a driver’s license or other legally acceptable proof of age. But if somebody looks old enough to drink, then the bartender may skip checking the license altogether. This is a good thing for underage customers who happen to look older. Driver’s licenses may require close scrutiny to identify fake licenses, or to determine if a person is using someone else’s license. Software developers often rely on untrusted inputs in the same way, and when these inputs are used to decide whether to grant access to restricted resources, trouble is just around the corner.

HighSuppose you’re hosting a house party for a few close friends and their guests. You invite everyone into your living room, but while you’re catching up with one of your friends, one of the guests raids your fridge, peeks into your medicine cabinet and ponders what you’ve hidden in the nightstand next to your bed. Software faces similar authorization problems that could lead to more dire consequences. If you don’t ensure that your software’s users are only doing what they’re allowed to, then attackers will try to exploit your improper authorization and exercise unauthorized functionality that you only intended for restricted users.

HighYou know better than to accept a package from a stranger at the airport. It could contain dangerous contents. Plus, if anything goes wrong, then it’s going to look as if you did it because you’re the one with the package when you board the plane. Cross-site request forgery is like that strange package, except the attacker tricks a user into activating a request that goes to your site. Thanks to scripting and the way the Web works in general, the user might not even be aware that the request is being sent. But once the request gets to your server, it looks as if it came from the user, not the attacker. This might not seem like a big deal, but the attacker has essentially masqueraded as a legitimate user and gained all the potential access that the user has.

HighBuffer overflows are Mother Nature’s little reminder of that law of physics that says: If you try to put more stuff into a container than it can hold, you’re going to make a mess. The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. However, copying an untrusted input without checking the size of that input is the simplest error to make in a time when there are much more interesting mistakes to avoid. That’s why this type of buffer overflow is often referred to as “classic.” It’s decades old, and it’s typically one of the first things you learn about in Secure Programming 101.

HighThese days, it seems as if software is all about the data: getting it into the database, pulling it from the database, massaging it into information, and sending it elsewhere for fun and profit. If attackers can influence the SQL that you use to communicate with your database, then suddenly all your fun and profit belongs to them. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security. They could modify the queries to steal, corrupt or otherwise change your underlying data. They’ll even steal data one byte at a time if they have to, and they have the patience and know-how to do so.