Web Application Break-In


This article can also be found in the Premium Editorial Download "Information Security magazine: Special manager's guide: Monitoring identities."

Download it now to read this article plus other related content.

Preventing SQL Injection

    Requires Free Membership to View

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 www.microsoft.com/downloads.

This was first published in August 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: