Information Security

Defending the digital infrastructure


Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Web Application Break-In

THREATS It's time to protect online assets from increasing attacks.

It's time to protect online Assets from increasing attacks.

The statistics are alarming: Gartner estimates 75 percent of attacks against Web sites take place at the application layer. Most of the vulnerabilities documented by Symantec in the second half of 2005 were found in Web application technologies. And a majority of the 20 most severe vulnerabilities in the US-CERT database are Web application flaws.

While companies have focused on securing their network perimeters, Web applications remain vulnerable to attack. Cybercriminals are growing more and more adept at exploiting their interactive nature to bypass traditional perimeter security defenses. By moving up the network protocol stack and communicating at layer 7, attackers can interface directly with an application's processes, and pass data designed to masquerade as legitimate application requests or commands through normal request channels such as scripts, URLs and form data. This can easily lead intruders to a wealth of valuable data without them having to break into any servers.

More information from

Learn more about Web application attacks and how to defend against them with this Learning Guide.

Test your knowledge of Web application threats and vulnerabilities with this 10-question multiple-choice quiz.

Visit our resource center for news on the latest Web application attacks.

Enterprises have a wide range of Web application attacks to worry about. Some of the more common ones include buffer overflows, SQL injection and denial of service (DoS) attacks, while a lesser-known type of threat is email injection. Intruders also use a technique called fingerprinting to zero in on their targets. The tactics are different, but the results can be equally devastating--from theft of confidential data and complete system compromise to business disruption.

By waking up to these threats and implementing methods and strategies to deflect them, enterprises can protect their most precious assets.

Preventing SQL Injection
A simple way to check if your site is vulnerable to SQL injection is to use the single quote mark trick: Complete a form on your Web site but add a single quote mark to one of the input boxes.

For example, if the form requires a username, you would enter John Doe'. This will typically return either a site-specific error message saying something like

"Page Not Found," or a SQL or programming error that may include language like "unhandled exception." If the latter is returned, your application may well be susceptible to SQL injection because this error response shows that user input is not being validated and cleaned correctly.

You should validate all user-supplied input for type, length, format and range. You also need to clean it of any characters or strings that could possibly be used maliciously. The best way to filter data is with a default deny regular expression. The filter must be narrow and specific, allowing only the type of characters that your application requires and expects. If you are expecting an integer, check that it is an integer. If it is not an integer, reject it. As an example, in the logon form below, unless the application verifies that the PIN number only consists of integers, an attacker could possibly inject an OR criteria into the SQL query to make the WHERE clause always resolve to true.

Logon Form
Name: False Name
PIN: 1234 OR 1=1

For example, SELECT * FROM users WHERE Name= 'False Name' AND PIN=1234 OR 1=1. This allows an attacker to log on without knowing a valid username and PIN.

Never write one validation script and use it throughout your site, as different data will require different validation. The validation process for a username and password, for instance, will be different from that of a product ID number. All data validation must be done on a trusted server or under control of your application. Your application should never rely on client-side data validation as it can be easily bypassed. Use it only to reduce round trips to the server and to improve the user experience.

--Michael Cobb

Poor Programming
Although many Web-based application security vulnerabilities are product-specific, many more are flaws in the design and use of an application, not necessarily in the underlying product itself. According to the Open Web Application Secu- rity Project (OWASP), Web application attacks are succeeding because of the following problems:

  • Invalidated input
  • Broken access control
  • Broken authentication and session management
  • Cross-site scripting flaws
  • Buffer overflows
  • Injection flaws
  • Improper error-handling
  • Insecure storage
  • DoS attacks
  • Insecure configuration management

Clearly, most of these problems are due to applications being poorly written or implemented, with only DoS attacks taking advantage of the way Internet protocols actually work.

Buffer Overflows and Path Traversal Attacks
One of the most common vulnerabilities caused by poor programming is a buffer overflow, which exists when a program process fails to limit the amount of user-supplied data, allowing an attacker to force the vulnerable process to store more data than it was intended to. The excess data overwrites other critical values stored in memory, and the attacker can then control the process and insert and execute malicious instructions.

With third-party products, the ways to protect against this type of attack are to apply the most recent security patches to your system, and to monitor security announcements and patch releases for all applications that run on your Web server.

Web servers generally are set up to restrict public access to a specific portion of the Web server's file system, typically called the "Web document root" directory. This directory contains the files intended for public access and the scripts necessary to provide Web application functionality. However, attackers can potentially access files such as password lists and other confidential data outside of this directory by launching a path traversal attack, which involves manipulating URL input parameters, cookies and HTTP request headers using special-character sequences.

To prevent path traversal attacks, you need to lock down and harden your Web servers and ensure that your access control lists are based on the least privilege methodology. The easiest way to tighten a Microsoft IIS Web server against this type of attack is to download and run the IIS Lockdown Tool free from

SQL and Email Injection
Another attack method clearly on the rise--and that can cause severe damage--is the injection attack. SQL injection attacks represent a serious threat to any Web site with a database back end and require nothing more than port 80 to be open. The methods behind these attacks are easy to learn and can lead to a complete system compromise, even if a system's patches are up to date.

SQL injection occurs when attackers take advantage of sites that generate SQL queries from user-supplied data without first checking or pre-processing it to verify that it's valid. By modifying the expected Web application parameters, an attacker can submit SQL queries and pass commands directly to a database.

A less-publicized injection attack that also profits from weak user input validation is email injection. If you have an email form on your Web site--such as a feedback or contact form--it basically acts like an SMTP proxy. Spammers will try to hijack it, turning your Web form into a spam relay. This type of attack often goes unnoticed until antispam filters blacklist the offending server's IP address.

The email injection attack works with any code that builds the message's mail headers when processing a Web form. For example, the PHP mail function requires a target address, a subject line and some form of message content. An optional parameter allows you to specify other mail headers, such as From, Cc and Bcc. Many PHP mail scripts use this fourth parameter to insert the sender's email address into the From header. If the script accepts a name and email address and formats them into the From field, spammers can use these form fields to manipulate the mail headers and insert a subject line, content and extra email addresses.

Again, the problem here is a failure to check user input properly and highlights the fact that Web developers need to fully understand the server-side language functions they use. To ensure your email forms are not open to abuse, your script should filter all user input using regular expressions or string functions to remove any line feeds or carriage returns.

Resources & Tools
Open Web Application Security Project (OWASP)

Web Application Security Consortium (WASC)

IIS Lockdown Tool

Google Webmasters FAQ

SANS Top 20 Vulnerabilities

Cross-Site Scripting
Unlike many application layer attacks, cross-site scripting attacks target an application's users, often with the aim of stealing personal data. They affect all Web applications that make use of scripting and aim to indirectly compromise an application's infrastructure.

Scripting attacks work by injecting code, usually a client-side script such as JavaScript, into a Web application's output. Merely viewing the output will execute the script, running it on the browser as though the trusted site generated it because browsers cannot distinguish between legitimate and malicious content served up by a Web application. The victim may not even be aware that the script has executed.

Most Web sites have numerous possible injection points, making them vulnerable to this attack method. And although client-side scripts are not able to directly affect server-side information, they can still compromise a site's security by altering form values or switching the form action to post the submitted data to the attacker's site. The most common purpose of XSS attacks, however, is to gather cookie data. Cookies are commonly--and often incorrectly--used to store information intended to be persistent during a browser session, or from session to session, such as session IDs, user preferences and login information. If input to your dynamically generated Web pages is not validated either before being processed or published, you could fall prey to an XSS attack.

DDoS Attacks
Unlike XSS, SQL injection and other attacks that steal information, distributed denial of service (DDoS) attacks aim to "deny" everyone from using the application by overwhelming servers and network devices, such as routers and firewalls, with bogus traffic. DDoS is the attack of choice for extortion and electronic protests against companies or organizations; the tools for launching DDoS attacks are widely available on the Internet. A recent survey of ISPs from around the world revealed that more than 90 percent believes simple DDoS floods are their biggest day-to-day hassle. By some estimates, DDoS attacks account for more than half the traffic across Internet backbones.

Unfortunately, DDoS attacks are a symptom of shortcomings in the Internet infrastructure, as they work by taking advantage of Internet protocols and consequently are among the most difficult attacks to defend against. There are several types of DDoS attacks, but their methods are similar in that they rely on a large group of compromised systems to direct a coordinated attack against a particular target.

The two most basic types of DDoS attacks are bandwidth and application attacks. Bandwidth attacks consume resources such as network bandwidth and equipment by overwhelming them with a high volume of packets. Application attacks, on the other hand, exploit the expected behavior of protocols such as TCP and HTTP by tying up computational resources and preventing them from processing genuine transactions or requests. HTTP half-open and HTTP error attacks are a couple of examples of application attacks.

It is important to evaluate your firewall rules and filters to ensure their effectiveness against these exploits. For example, egress filtering will prevent your network from being the source of spoofed packets, and will make it easier for you to uncover the source of any internal agents.

Before hackers can launch a successful attack against a Web application, they need to gather as much information as possible about the application and the infrastructure on which it resides.

Identifying the applications running on a remote Web server is known as fingerprinting. One of the simplest ways is to send a request to the server and review the information sent in the response banner, which generally contains the exact version of the Web server software running on the server. This information leakage can be addressed by configuring the server not to display the banner at all, or by changing it to make the server look like something else. There are a number of tools that help fake the banner, such as URLScan for IIS Web servers and mod_security for Apache Web servers.

Unfortunately, there are tools that fingerprint Web servers without relying on banners, and hackers are now even using search engines such as Google to help find and fingerprint vulnerable machines. This is commonly known as Google hacking. By using Google's advanced search operators, hackers can retrieve fingerprint information from Google's cache without ever connecting to their intended target. (See the March 2006 Information Security feature "Google Hacking" for more information.)

To find out what hackers can discover about your site, you can also use the Gooscan tool (with expressed permission in advance from Google) from http://johnny.ihack, which also hosts the Google Hacking Database. Or, you can check the Google Webmasters FAQ at provides information about how to properly protect and expose your site to Google.

Holistic Protection
To effectively combat Web application attacks, you need a holistic approach; tackling one vulnerability will often strengthen your defenses against another. At the core of your application security strategy should be a policy that enforces secure coding practices, ensuring that vulnerability detection and assessments are performed during any application development or deployment.

Start by identifying the places where data enters or exits the application, and ensure that validation occurs for every part of the HTTP request before letting it anywhere near your scripts, data access routines and SQL queries. Next, you need to review the trust levels assigned to application entry and exit points and define the privileges that external users and processes are granted to access the system. A useful exercise is to create a data flow diagram that tracks how data flows through the application. If there is system or application failure, make sure your application doesn't return specific details about the error as this can provide useful information to an attacker.

The Web application itself needs to run under the least amount of privileges necessary for it to function correctly. Certainly, never use the default account, such as SQL Server's "sa" account. Ensure that any connection to a database or other resource is made using a least-privileged account, and you must lock down your database and Web servers. Remove non-required features such as example databases and test pages; disable unneeded stored procedures; and monitor and back up your database server in the same way as your Web server.

This process should involve running a vulnerability scanner on a regular basis. Many scanners are now automated, and many can scan for XSS vulnerabilities and Google hacks. SANS has a list of tools and services that find and fix the top 20 vulnerabilities at 2005/tools.pdf.

If you use third-party packages, you should always check for known vulnerabilities with the vendor before installation, and then keep up to date on patches and advisories. Even if your Web applications are relatively secure when first deployed, changes to the system's infrastructure or configuration and new threats mean that your applications won't remain secure for long. Therefore, it is essential that your security policies are regularly reviewed for relevance and effectiveness.

You should also review the effectiveness of your firewall--packet-filtering firewalls can no longer provide the level of protection a Web application requires. Although routers and stateful packet-filtering network firewalls can be deployed to ensure that only approved transmission ports and protocols are open or allowed, attacks at the application layer require an examination of the application layer commands and data. Only at the application level is it possible to accurately determine what the real behavior will be with regard to a specific context.

It is important to develop an incident response plan; having a detailed and well-rehearsed plan will help you handle attacks in an orderly, effective manner and minimize their impact on your network.

Improvement Ahead
Because so many applications and services are delivered over the Internet, application security must be built into your organization's security policy. Fortunately, the Web community is also looking at ways to help improve the overall security of Web-based applications.

The Web security threat classification and security statistics projects by the Web Application Security Consortium will certainly help application developers and security professionals to focus their efforts, which will, in turn, improve application development processes and speed up response times to vulnerabilities. Meanwhile, vulnerability classification will enable better automated assessments of threats posed by Web application flaws.

Until these efforts pay off, though, Web applications will likely remain a favorite target of attackers. Companies must remain alert and vigilant or risk becoming the next victim.

Article 9 of 19

Dig Deeper on Web application and API security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Information Security

Access to all of our back issues View All