PREVENTING INTRUSIONS
What you should know about web application vulnerabilities
By Andrew Stern

Today’s companies are increasingly moving their critical applications into web browsers, taking advantage of the cost-effectiveness and efficiency of web-based applications. Unfortunately, the very features that make browsers so convenient also make them incredibly insecure. These vulnerabilities open a door for hackers to gain access to corporate systems and private customer data. The resultant privacy and compliance concerns, including identity theft, have become concerns of both corporations and consumers.

“It’s essential that we protect our constituents’ personal information. And this is not a static concern, because hackers continue to adapt to progressively sophisticated technologies,” said Chad O’Neal, Web Technical Engineer with Blue Cross and Blue Shield of Kansas City. “To mitigate security risks, organizations need continuous visibility into who’s attempting to access what information.”

Companies are taking action to safeguard their applications, but traditional firewalls and other tools that protect at the network level do little to turn back probing attacks that exploit an application’s specific vulnerabilities. Most of the solutions available today only protect against known attacks. Relying on this kind of negative security logic exposes companies to dangerous and targeted hacker activity.

To successfully maintain data security, companies need to shore up their application security. Application firewalls that employ a positive security model (“deny all unless allowed”) can prevent targeted attacks, while automatically protecting applications from generalized attacks such as cross-site scripting, parameter tampering and buffer overflow.


Example of an application firewall product that employs a ‘positive’ security model to prevent targeted attacks

THE ROOT OF THE PROBLEM
Since web browsers can act in unexpected ways, web-based applications are inherently vulnerable. Once a user is logged into an application, the security of the application itself is the only thing restricting access to other users’ data.

Therein lies the problem. Most of the security holes in corporate IT infrastructure are based not on worms or viruses, but on vulnerabilities in the applications themselves. The majority of today’s client applications were written to work in tandem with a specific server application. This client-server model resulted in robust, secure applications.

In the late 1990s, many client-server applications were moved to the web, where deployment is free and clients are platform-independent. But fundamental differences between web applications and traditional client-server architectures exposed the newly ported applications to significant risks.

"Historically, the nature of a client-server environment provided a built-in level of security," explains Alan Murphy, Technical Marketing Manager for F5 Networks. "Users needed: 1) access to the network hosting the client-server application; 2) the client application; and 3) user-level access credentials. But with web applications, the ‘client’ is the common web browser, and network access is far more open over WANs, LANs, and the Internet—so two of three criteria are largely met due to web architecture and application design.”

APPLICATION DIFFERENCES AND EXPLOITS
Four key differences between client-server and web-based applications are the cause of most of the common security breaches that occur today. Hackers exploit the variations between the two types of applications using several common attack methods.

Difference 1: Heavy client versus browser
Client-server applications rely on the client to do the heavy lifting and perform the majority of data validation, which makes it difficult to modify input to the server. With browsers, the source of the client-side application is available to anyone accessing the web page, and is therefore easy to change.

Exploiting the Difference: Tricking the browser
Unlike heavy clients, browsers are easy to trick, opening the door for attacks such as buffer overflow and cross-site scripting.

Buffer overflow overruns a parameter’s memory allocation, which can compromise the entire application. For example, a field might always expect a 10-digit phone number, so developers will allocate just enough memory to handle those 10 digits. If hundreds of digits are entered, the server application will eat into memory allocated to different tasks, potentially causing a core dump and providing hackers with information stored in the server’s memory. Even more threatening, buffer overflows can also tunnel through the server to deeper infrastructure. A hacker who disables a system in this way could upload code to be executed by the server, as was the case with the Code Red and Slammer viruses.

Cross-site scripting is an attack that inserts malicious script into web pages viewed by others. The most common places to do this are on bulletin boards or auction sites, where users can submit comments. Malicious users could fill out an auction for an item, and at the bottom of the description include script that includes the current user’s cookie value on the image request. Anyone viewing this auction item will now send his or her cookie information to a web server of the hacker’s choosing, which can then be used to steal the identities of users by impersonating them on websites.

To protect against buffer overflow and cross-site scripting attacks, servers must carefully check all input from the client and monitor for malicious characters. Network devices that perform this function, however, generate many false negatives, since they do not understand where this kind of script might be allowed.

Difference 2: One program versus many scripts
Client-server applications typically have one program communicating with a client. In the web environment there are multiple scripts, running on many different web servers, with many different entry points.

Exploiting the difference: Jumping out of order
Because web applications use many different scripts and files, altering the URL in a browser will often allow hackers to jump over certain pages and gain access to restricted pages. An attack of this kind is called “broken access control” or “forceful browsing.”

A simple example of forceful browsing is skipping over a registration page to get to the pages behind it. Google search technology has made this problem acute, since it can find and create public links to interior pages of websites that should only be accessed after passing through authentication pages. Bookmarking creates similar problems.

"Forceful browsing has become more acute, in part, because processes used to be initiated and executed in a uniform, sequential manner over a single connection,” notes Michael Suby, Stratecast Program Director, Business Market Strategies. “By contrast, web applications are non-linear, and normally do not rely on previous processes to complete and notify the application before a 'next' process can begin. This non-linear nature is attractive to hackers because it creates multiple application entry points. An attacker can often bypass or compromise standard blocking procedures, such as login sequences, to access processes that would typically only be available to a user after producing the appropriate credentials."

Difference 3: State versus no state
In a client-server environment, there is a single, uninterrupted connection, so it’s easy to track where users have been and where they are going. Web protocols don’t have sessions (users literally drop off the grid until their next request), so developers have to find a different way to track a user’s so-called “state” within the application.

Exploiting the difference: Manipulating state tools
The most common tools developers use to track state are cookies, dynamic parameters and dynamic links, each of which is vulnerable to different types of attack.

Cookies, which contain a unique identification tag that enables a server to recognize a user, can be “poisoned” by using an intercept proxy or by modifying them directly on a hard drive before sending a request. By changing a cookie, hackers can fraudulently identify themselves to bypass authentication pages.

Dynamic parameters, or links, generate novel content for each user by running unique queries on databases behind an application every time a link is clicked. Page links on the bottom of a web page are examples of dynamic links. E-commerce applications also use dynamic links to connect users to their personal information. Dynamic parameters are vulnerable to tampering by altering the text behind a link. This kind of attack will often result in a hacker gaining access to other users’ private information.

Dynamic links are also vulnerable to hidden field manipulation and SQL injection attacks. Hidden fields are dynamic fields within an HTML form, which hackers attack by manipulating the source code. For instance, in a form where users input credit card information to make a purchase, hidden fields may contain inventory information and a price. By changing the price of an item in the source code of a hidden field, malicious users can successfully shoplift electronically.

SQL injection attacks simply enter SQL commands into dynamic fields, instead of legitimate data. In the case of a web application with a user name/password login screen, instead of entering a value such as “jsmith,” a hacker could insert an SQL command, causing the server to execute a malicious query that compromises the system.

To protect against cookie poisoning and dynamic field tampering, applications must be modified to use encrypted cookies to store information. In the case of cookie poisoning, code would have to be added in every instance where cookies are used—a relatively easy fix but a considerable expenditure of time and resources.

Difference 4: Hundreds of users versus millions of users
Applications built for the client-server environment were designed to handle hundreds of users. Web servers, by contrast, frequently handle millions of users, which increases the chances that a malicious attack will be successful.

Exploiting the difference: Playing the numbers game
Hackers use to their advantage an application’s millions of users by launching enumeration attacks, which force a server to list the various resources stored on it, such as user names and other database information. For example, to circumvent a website’s protocol that suspends usage rights after a set number of login attempts, a hacker could write a script that would use one Social Security number after another, with the same PIN. Using a common PIN, such as 123456 or PASSWORD, the script will get at least one account in a matter of hours and all accounts within days.

To solve the problem of enumeration, applications can be redesigned to monitor for abnormally high access of a login page, although the effect of this is to penalize all users by extending the response time for everyone.

PREVENTING INTRUSIONS
Combating the security threats posed by malicious attacks is time consuming, expensive and sometimes unreliable. Code reviews, extensive penetration testing and network monitoring devices are a few ways that companies are battling a growing problem. Unfortunately, most of these strategies take a defensive approach, adequately protecting applications from known, generalized attacks but doing little to safeguard against more malicious, targeted assaults.

Proactive application firewalls that can defend against unexpected browser activity provide companies with more reliable, cost-effective security, enabling them to deliver safe and dependable services to their customers.

About the Author:
Andrew Stern is the Director of Strategy for F5 Networks, a global provider of Application Delivery Networking products and security solutions.