Oh What a Tangled Web

By Peter Piazza

The next time you check your account balance at your bank's Web site, stop for a moment and consider who created and coded the software application that will validate your login information and then reach into the bank's database to retrieve your account information. How much did that person know about--and consider--possible security vulnerabilities in the code? Can hackers exploit those weaknesses? For security professionals, the larger question is: Are these issues addressed at your own company's Web site?

According to experts in testing the security of Web applications, the answers to these questions are alarming. They say that many Web applications, from complex online banking pages to simple Web forms, are rife with exploitable weaknesses, and malicious attackers are frequently and successfully using those holes to obtain access to whatever sensitive information may be inside the exploited database, from credit card numbers to passwords.

Traditional network-protection tools, such as firewalls, are useless in protecting against Web application attacks. And while some targeted solutions do exist, broader mitigation efforts, such as greater education and greater use of testing software and services, are in the early stages of being implemented and may take years to pay off.

Companies must take a proactive approach. And the first step toward that end is to begin to understand the vulnerabilities and the ways in which they can be exploited. The next step is to close those vulnerabilities if possible.

Of all the possible Web application exploits, two present the most serious exposures: The first exploit is called SQL injection (SQL is pronounced "sequel"); the second is called session hijacking.

SQL injection. To understand the threat that SQL injection can pose, it's first necessary to look briefly at what SQL is and how it's used. Originally known as "structured query language," SQL is a specialized computer language used to retrieve information from a database. It's frequently used to code Web forms that allow a user to enter information.

In an online banking scenario, a visitor to a bank's Web site would see boxes for a username and password. After the user enters information into the proper fields and presses the enter key, the bank's Web server reads the SQL queries in those fields and then checks the username and password against its database. If the content in the username and password fields is correct, the user can then continue to his or her account information.

Caleb Sima, co-founder and chief technology officer of SPI Dynamics, a Web application security testing firm, explains that these types of pages are frequently coded improperly. For example, a field that asks for a password should be coded to accept digits and nothing else. If the field doesn't reject other characters immediately, and sends off those characters to the database, the application becomes vulnerable because it gives an attacker a way to access the database. "You can actually create your own SQL statements in that [field] and then have the database do something completely different," from what it was originally programmed to do, he says. For example, an attacker with knowledge of SQL could, instead of inserting a password, insert a command that would provide access to all records in a database.

Phil Brass, senior security consultant at Internet Security Systems (ISS) and a member of ISS's X-Force Penetration Testing Team, says that SQL injection is only beginning to become recognized as a problem to software code writers. "It's very well known in the security community, but less so in the application development community," Brass says. He adds he's seen "plenty of people develop banking applications" that are vulnerable to SQL injection.

Dave Gruber, product manager for Macromedia's popular ColdFusion product (a software package used to build Web applications and services), says that application developers are aware of the importance of application and data security. He adds that servers using ColdFusion can automatically detect SQL injection attacks and stop the action by recognizing some of the typical clues of a SQL injection, such as single quotes followed by text, and rewriting them before they are sent to the database. "This prevents the database engine from interpreting the malicious input as a valid SQL end statement," Gruber explains.

Sima acknowledges that ColdFusion offers protection against some variants of SQL injections. But, he says, his experience has shown that there are still many other variations that remain a threat, even to ColdFusion customers.

Moreover, many earlier versions of off-the-shelf products that are still in use don't offer any such protection. For example, Brass says, some older versions of Microsoft's Site Server, a software program that helps businesses set up e-commerce sites by using a "wizard" to automatically generate a Web site, created sites with built-in SQL injection problems.

Sima says that Microsoft and other large software vendors have gotten much better at writing secure code, but the problem is still extant in legacy systems. "You're looking at hundreds of millions of applications that have been developed for years and years that have huge amounts of exploits and holes like SQL injection," he says.

Session hijacking. Session hijacking is a high-tech form of identity theft. To explain how it works, Sima lays out a simple scenario. Imagine that you visit a new online business and decide to make a purchase. You're prompted to input personal information to create an account, and since you're creating the very first account, the business's Web server assigns you an ID number of 1. The server then creates a cookie, a small text file that includes your registration information, and puts it into a file on your computer. From now on, whenever you visit that site you won't need to sign in; your Web browser will look through your cookies to see if one matches the site you're visiting. If it finds one, any stored registration information is delivered to the Web site, making it more convenient for you to shop.

Now another user visits the same site and creates an account. Since he's the second user, he gets an account ID number of 2, and all subsequent users similarly receive incremental account numbers. But these incremental numbers make it a simple process for attackers to compromise every account, Sima says; all they would have to do is go to the "My Account" page and change the account number in the URL, or if more tech savvy could rewrite their cookie to mimic another account's cookie.

That's how session hijacking works. Of course, it should be obvious that no Web site should set up such an easy-to-break numbering system--but unfortunately, it has happened, says Phil Brass. "I've seen sequential ones," he says with incredulity. "It was in a $100-million-per-day funds-trading organization. They created a new record in their database with one of these auto-increasing fields, so every new record had a new number that was just one number above the record above it, and that was your ID."

Most developers try to avoid this problem by using programs that will create random account numbers. However, sometimes numbers created by these generators appear random, but really aren't. Sima explains that in some cases these programs make numbers appear to be random (by, say, multiplying each subsequent account number by 55), but an attacker will see through this. Account numbers must be truly random to be secure.

Similar problems can arise for applications that don't use cookies at all, but rather put account data into the URL at the top of a Web page. "This is not a recommended practice," Gruber says, "but in the event a developer makes this choice, the user would be susceptible to another user looking over their shoulder to read the ID from the URL."

Other vulnerabilities. While SQL injection and session hijacking are the most common types of Web application attacks, hackers can exploit many other holes. Often, application developers simply don't consider how savvy attackers can be. And it's not only Web commerce sites that are vulnerable; Sima says that he's seen mistakes on the simplest Web sites that can still cause major problems.

He gives as an example a law firm's Web site that had no e-commerce content at all, but merely provided a series of attorney biographies. This apparently harmless site contained enough information for Sima to compromise the law firm's internal network.

Sima explains that the first step in the penetration test was to browse the Web site and look at all the pages. He noticed that the administrator had kept backup files of each bio on the server so that he would have a copy of each file handy in case he needed to make a change. Each backup file had the suffix ".old." Because that suffix is not recognized by Web browsers, the administrator believed these backup files would remain invisible to those surfing the site. However, when Sima entered the proper file name with the .old suffix into the URL, the Web server responded by showing him the page's source code, which should have been hidden--particularly since the administrator had, in the "comments" field of the source code, included his username and password. Sima took that information, logged into the administrator's e-mail server, and downloaded his e-mail, which included usernames and passwords for every attorney on the network. That information gave Sima access to the network. Again, what sounds like an elementary error--putting sensitive information into the comments field of the source code--is not at all uncommon, Sima says.

The dangers.
Network administrators have an array of high-tech tools, including firewalls and intrusion detection systems, to help defend their networks against traditional hackers and viruses. Web application attacks are, however, not thwarted by these protective measures, and compromised Web applications provide direct and unfettered access to sensitive database information that network administrators may think are well protected by their firewalls. To help understand these points, let's look first at how a typical network is defended.

Firewalls, IDS failure. Sima explains that a firewall is used to deny access to certain ports, or connections, on a computer. The most typical open port is port 80, which allows Web traffic in and out of the network. "But what the firewall doesn't make a distinction about is the fact that once you open a port, such as port 80 for the Web," it's open for all Web traffic, good or bad. "That's where the firewall's job stops, and so it's going to allow any traffic to and from your Web server," Sima says. An attacker trying a SQL injection attack will get access to a Web site unhampered by a firewall because the firewall recognizes all of the Web traffic coming through as legitimate.

Another common defense mechanism is the intrusion detection system (IDS). An IDS typically looks for signatures of known attacks, while more sophisticated intrusion prevention systems can also look for and stop anomalous behavior. But SQL injection and session hijacking attacks don't have any typical signature, nor do they appear to be unusual behavior.

To an IDS, a Web application attack looks like a legitimate user carrying out a legitimate action, such as entering information into a form. While some Web application software programs (such as ColdFusion, as explained earlier) have built-in protections that look for anomalies within form entries, network protection products do not.

The network's heart. In terms of the danger posed by these vulnerabilities, Brass points out that Web application attacks can often bring an attacker directly into the heart of a network more easily than a traditional attack exploiting network holes. That's because of the way that networks are configured.

A company with a Web site wants to get visitors to that site, so its Web server must be located someplace that's accessible from the Internet yet won't allow hackers easy access to the network. Therefore, a Web server is usually located in an area called the DMZ, or what Brass terms a "network cage," that isolates Web servers from the primary network. This helps lock in an intruder who can compromise the Web server and prevents him or her from getting easy access to sensitive data.

But since a Web application attack actually targets a database that is typically located inside the network, rather than in the DMZ, the potential for significant loss is high. Not only are obvious targets, such as credit card numbers, exposed but also sensitive customer information such as Social Security numbers, Brass says. This puts customers at risk for identity theft if a Web application is breached--even if the site merely sends out catalogs and doesn't perform e-commerce.

The solutions.
The solution to Web application problems begins with the developers of applications ensuring that security is considered and built into each new program, as Dave Gruber says ColdFusion has done. There are also some newer technological solutions, such as Web application firewalls, becoming available.

Build security in. Gruber says that one problem developers have faced is that companies often modify requirements for Web applications under development, which sometimes causes security issues. "Applications that are well designed from the start typically include a set of security objectives, which designers use to ensure that security is designed into an application," he says.

But it frequently happens that an application is initially created to process data that need not be kept confidential, then later the application is modified to include data that needs to be secured. This situation often results in the modification of a Web application without proper consideration of the new security implications, Gruber says.

As developers give more attention to Web application problems, new generations of software products will likely be more resistant to attacks. The best first step is to understand the potential problems, says Brass, and build the solutions in. Those who want to set up a Web site "are going to get the biggest bang for their buck" by researching and understanding these problems in advance. "It might save them one hundred times what it costs them to fix it later if they can just stop the problem from being written and make sure that developers add security into the application first."

Companies that develop Web applications should have strict processes in place for ensuring that security is being addressed as the software is written. Macromedia, for example, "uses independent, third-party security audit teams to complete in-depth security audits for all of its products well in advance of release," Gruber says. The company also has a team that tracks new threats; that team then discusses the issues with developer teams, and they consider what new precautions should be taken to counter those threats.

Application firewalls. There are Web application firewalls that can help mitigate the risk. These, Sima explains, are placed in front of a Web site or application so that a form being submitted to a database must pass through the firewall first; similar to intrusion detection systems, the task of these firewalls is to "try as much as possible to understand how your Web application works," and identify what's good behavior, and deny everything that's bad behavior, he says.

Although application firewalls are one good step toward being able to protect Web applications, Sima warns that Web application firewalls are only part of the solution for Web application problems. "I think it's a good measure for being able to practice defense in depth, but the proper way to secure and fix your vulnerabilities is to make sure you go back to your developers," he says, and make sure they code securely in the first place. This task includes security testing during the quality assurance cycle.

Scanners. Some products can locate common vulnerabilities in Web applications that are custom-written for the company. For example, SPI Dynamics has software called WebInspect that checks Web applications for vulnerabilities so that developers can correct any errors. For smaller companies that have used an off-the-shelf software product to create their Web application, Sima says that it may be worthwhile to pay for an assessment (his and other companies offer such services) and get a report that will explain any problems. "If it's an existing problem in the application that you don't have access to, then it comes down to us contacting the vendor itself and notifying them of the problem. We'd wait for a patch to be resolved and then contact the customer and tell them how to fix it," and provide a workaround solution in the meantime, he says.

Macromedia's Gruber agrees that, given the speed at which new vulnerabilities can occur, the end user must be proactive in securing its applications. "Most organizations now have some level of formal auditing that takes place periodically for existing and new applications," he says. "These audits help development organizations become aware of potential issues in both current and future systems."

It is clear that any online business and any organization with a Web site is vulnerable to hackers who seek out Web application weak points to steal information or penetrate the inner workings of a network. Getting offline isn't really a practical option. But ensuring that the company's window to the online world is open securely is hard work. To paraphrase Thomas Jefferson's reference to the cost of liberty, the price of being online securely is constant vigilance.

Peter Piazza is associate editor of Security Management.



The Magazine — Past Issues


Beyond Print

SM Online

See all the latest links and resources that supplement the current issue of Security Management magazine.