Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Vista
      Digg this story   Add to del.icio.us   (page 2 of 3 ) previous  next 
Five common Web application vulnerabilities
Sumit Siddharth, Pratiksha Doshi 2006-04-28

Article continued from Page 1

Here is an example of vulnerable code in which the user-supplied input is directly used in a SQL query:

<form action="sql.php" method="POST" />
<p>Name: <input type="text" name="name" /><br />
<input type="submit" value="Add Comment" /></p>
</form>
<?php
$query = "SELECT * FROM users WHERE username = '{$_POST['username']}"; 
$result = mysql_query($query);
?>

The script will work normally when the username doesn't contain any malicious characters. In other words, when submitting a non-malicious username (steve) the query becomes:

$query = "SELECT * FROM users WHERE username = 'steve'"; 

However, a malicious SQL injection query will result in the following attempt:

$query = "SELECT * FROM users WHERE username = '' or '1=1'";

As the "or" condition is always true, the mysql_query function returns records from the database. A similar example, using AND and a SQL command to generate a specific error message, is shown in the URL below in Figure 1.

Figure 1. Error message displaying the MS SQL server version.

It is obvious that these error messages help an attacker to get a hold of the information which they are looking for (such as the database name, table name, usernames, password hashes etc). Thus displaying customized error messages may be a good workaround for this problem, however, there is another attack technique known as Blind SQL Injection where the attacker is still able to perform a SQL injection even when the application does not reveal any database server error message containing useful information for the attacker.

Countermeasures:

  1. Avoid connecting to the database as a superuser or as the database owner. Always use customized database users with the bare minimum required privileges required to perform the assigned task.
  2. If the PHP magic_quotes_gpc function is on, then all the POST, GET, COOKIE data is escaped automatically.
  3. PHP has two functions for MySQL that sanitize user input: addslashes (an older approach) and mysql_real_escape_string (the recommended method). This function comes from PHP >= 4.3.0, so you should check first if this function exists and that you're running the latest version of PHP 4 or 5. MySQL_real_escape_string prepends backslashes to the following characters: \x00, \n, \r, \, ', "and \x1a.
References for standard SQL Injection:

  1. Steve's SQL Injection attack examples
  2. SQL Injection Whitepaper (PDF)
  3. Advanced SQL Injection paper

Blind SQL Injection:

  1. SPI Dynamics blind SQL Injection paper (PDF)
  2. iMperva blind SQL Injection article

2.3 Format String Vulnerabilities

This vulnerability results from the use of unfiltered user input as the format string parameter in certain Perl or C functions that perform formatting, such as C's printf().

A malicious user may use the %s and %x format tokens, among others, to print data from the stack or possibly other locations in memory. One may also write arbitrary data to arbitrary locations using the %n format token, which commands printf() and similar functions to write back the number of bytes formatted. This is assuming that the corresponding argument exists and is of type int * .

Format string vulnerability attacks fall into three general categories: denial of service, reading and writing.

Rating: rating3 Moderate to Highly Critical

Previously vulnerable products:
McAfee AV, Usermin, Webmin, various Apache modules, winRar, ettercap, and others.

  • Denial-of-service attacks that use format string vulnerabilities are characterized by utilizing multiple instances of the %s format specifier, used to read data off of the stack until the program attempts to read data from an illegal address, which will cause the program to crash.
  • Reading attacks use the %x format specifier to print sections of memory that the user does not normally have access to.
  • Writing attacks use the %d, %u or %x format specifiers to overwrite the instruction pointer and force execution of user-supplied shell code.

Here is the piece of code in miniserv.pl which was the cause of a vulnerability in Webmin:

if ($use_syslog && !$validated) 
{
        syslog("crit",
               ($nonexist ? "Non-existent" :
                $expired ? "Expired" : "Invalid").
               " login as $authuser from $acpthost");
        }

In this example, the user supplied data is within the format specification of the syslog call.

The vectors for a simple DoS (Denial of Service) of the Web server are to use the %n and %0(large number)d inside of the username parameter, with the former causing a write protection fault within Perl – and leading to script abortion. The latter causes a large amount of memory to be allocated inside of the perl process.

A detailed Webmin advisory that was used for this example is available and provides more information.

Countermeasure:

Edit the source code so that the input is properly verified.

References:

  1. tiny FAQ
  2. Wiki definition

2.4 Cross Site Scripting

The success of this attack requires the victim to execute a malicious URL which may be crafted in such a manner to appear to be legitimate at first look. When visiting such a crafted URL, an attacker can effectively execute something malicious in the victim's browser. Some malicious Javascript, for example, will be run in the context of the web site which possesses the XSS bug.

Rating: rating2 Less to Moderately Critical

Previously vulnerable products:
Microsoft IIS web server, Yahoo Mail, Squirrel Mail, Google search.

Cross Site Scripting is generally made possible where the user's input is displayed. The following are the popular targets:

  1. On a search engine that returns 'n' matches found for your '$_search' keyword.
  2. Within discussion forums that allow script tags, which can lead to a permanent XSS bug.
  3. On login pages that return an error message for an incorrect login along with the login entered.

Additionally, allowing an attacker to execute arbitrary Javascript on the victim's browser can also allow an attacker to steal victim's cookie and then hijack his session.

Article continued on Page 3 



SecurityFocus accepts Infocus article submissions from members of the security community. Articles are published based on outstanding merit and level of technical detail. Full submission guidelines can be found at http://www.securityfocus.com/static/submissions.html.
    Digg this story   Add to del.icio.us   (page 2 of 3 ) previous  next 
Comments Mode:







 

Privacy Statement
Copyright 2008, SecurityFocus