Submitted by Bogdan Calin on September 3, 2010 – 8:09 pm

While beta testing the latest version of Acunetix WVS v7, we found a large number of security vulnerabilities in various web applications. In the following days we will publish some of these vulnerabilities.  Note that we will not publish vulnerabilities found in applications that are not commonly used or in beta stage.

One of the tested web applications is Pligg;

Pligg is an open source CMS (Content Management System) that you can download and use for free. Pligg CMS provides social publishing software that encourages visitors to register on your website so that they can submit content and connect with other users.

The following web vulnerabilities were found in Pligg CMS Version 1.0.4;

1. SQL injection in “/pliggcms_1_0_4/login.php“, parameter “email“.
2. Cross-site Scripting vulnerability in “/pliggcms_1_0_4/user.php“, parameter “category“.

Technical details about each web vulnerability are below;

1. SQL injection in “/pliggcms_1_0_4/login.php“, parameter “email“.

Source file: /var/www/pliggcms_1_0_4/libs/db.php line: 222

Additional details:

SQL query:

“mysql_query” was called.

Stack trace:

Sample HTTP Request:

2. Cross-site Scripting vulnerability in “/pliggcms_1_0_4/user.php”, parameter “category”.

Attack details

URL encoded GET input categorywas set to ” onmouseover=prompt(938687) bad=”
The input is reflected inside a tag element between double quotes.
The input is reflected inside a tag element between single quotes.

Sample HTTP Request:

These vulnerabilities were reported to the Pligg team on 22/7/2010 via the contact form from their website and they were fixed in latest version of Pligg.  If you are using Pligg, download the latest version from their website.

New scanning engine with improved vulnerability detection AND verification makes finding and fixing security issues in web applications easier.

September 1, 2010 – Acunetix, a market leader in web application security scanning technology, today announced version 7 of its popular Web Vulnerability Scanner. With the new human like vulnerability verifying techniques, revolutionary scanning engine and support for a wider variety of web applications, Acunetix re-establishes its technology lead in web application security. Acunetix WVS Version 7 also features improved performance, less false positives and detection of a wide range of new web vulnerability types.

“With Acunetix WVS v7 we focused on finding more vulnerabilities, reducing false positives, and on improving scanner performance,” said Robert Abela, Acunetix Technical Manager. “As a result, Acunetix 7 is now 300% faster, can reduce false positives up to 50% and detects new vulnerabilities such as stored directory traversal. This helps businesses reduce the time and resources needed to secure their web applications significantly.”

Unique vulnerability verifying technique reduces false positives
Acunetix v7 includes new advanced vulnerability verifying techniques which result in much less false positives, and thus saves time of security administrators trying to reproduce such situations. Such accuracy is achieved by sending a number of test inputs to the web application, and depending on the response, Acunetix v7 will automatically determine which web vulnerability checks to launch against the web application.

New faster scanning engine reduces time to scan a website by up to 300%
Acunetix Web Vulnerability Scanner Version 7 includes a new fast multi-threaded scanner that can scan on more threads at a time and more efficiently. Scans that could take hours to complete now can be done in minutes, depending on website structure and web applications.

Acunetix 7 reduces time needed to fix security vulnerabilities

When a web security threat is discovered, Acunetix WVS Version 7 presents the developers with a more precise and understandable technical and vulnerability remediation information, to help them fix the issue in a much shorter time. To improve understanding, different variants of the vulnerability are gathered in one detailed vulnerability report. Acunetix v7 can also re-check a fix for a particular vulnerability, without having to rescan the entire website.

Detect more web vulnerabilities

Thanks to the new revolutionary scanning engine and website crawler, Version 7 is able to find much more vulnerabilities than ever before. The new site crawler’s in-depth analysis of the website presentation layer discovers more website parameters and inputs. Acunetix 7 is therefore capable of finding many more vulnerabilities in a larger variety of different web applications.

Scan a wider range of web applications
Acunetix v7 is also able to crawl and scan a wider variety of web technologies. Support for Web 2.0 applications has been improved, and also session handling. All of the advanced penetration testing tools have been rewritten to support Web 2.0 requests, such as JSON, XML and more.

HTTP authentication
Acunetix WVS v7 now supports more than a single pair of HTTP credentials for the same host. Thanks to the new HTTP authentication settings node, one can pre-define credentials per host, directory and even file.

Easily create your own vulnerability checks

Acunetix v7 now has improved support for creating custom vulnerability checks. Vulnerability checks are written in JavaScript, the most popular scripting language with web developers, and can thus be easily adjusted or extended. A scripting tool and SDK are also available to assist developers in writing custom web vulnerability and security checks.

Lower cost subscription licenses

Subscription based licenses now also include the maintenance agreement and are thus significantly cheaper. In addition free support and free version upgrades are included.

Other Features

■New graphical scan status interface shows more information about a web scan in progress
■Avoid the lengthy process of manually analyzing the code by specifying the label or tag instead of actual parameter name
■Verify that AcuSensor Technology is correctly installed with a simple click of a button
■During a scan, less bandwidth is consumed and less stress is put on the server thanks to improved network traffic handling
■A number of new network security checks have been added and other ones improved.

Acunetix WVS Trial Edition
Download Acunetix Web Vulnerability Scanner v7 trial edition from here

Acunetix is pleased to announce that the much awaited Acunetix Web Vulnerability Scanner Version 7 release is approaching!

Be sure to check our Acunetix Blog to keep updated with the latest news and release date of the BETA!

Acunetix WVS V7 is 75% faster, and ships with a more intelligent and faster scanning engine. Below is a summary of the top new features that will be available;

* New revolutionary scanning engine detects a wider range of web vulnerabilities
* Less false positives and false negatives; human like vulnerability verifying techniques!
* Improved web 2.0 applications support; better handling and parsing of JSON and XML
* Improved handling and detection techniques of links and input parameters
* Consolidation of vulnerabilities to facilitate coordination of vulnerability remediation

Alliance Technology Partners is a leading Acunetix partner.  Visit our Acunetix Web Vulnerability Resource Page for the latest information on the Acunetix Web Vulnerability Scanner and for the best prices on Acunetix software.

Directory Traversal Attacks

What is a Directory Traversal attack?
Properly controlling access to web content is crucial for running a secure web server. Directory Traversal is an HTTP exploit which allows attackers to access restricted directories and execute commands outside of the web server’s root directory.

Web servers provide two main levels of security mechanisms:

• Access Control Lists (ACLs)
• Root directory

An Access Control List is used in the authorization process. It is a list which the web server’s administrator uses to indicate which users or groups are able to access, modify or execute particular files on the server, as well as other access rights.

The root directory is a specific directory on the server file system in which the users are confined. Users are not able to access anything above this root.

For example: the default root directory of IIS on Windows is C:\Inetpub\wwwroot and with this setup, a user does not have access to C:\Windows but has access to C:\Inetpub\wwwroot\news and any other directories and files under the root directory (provided that the user is authenticated via the ACLs).

The root directory prevents users from accessing sensitive files on the server such as cmd.exe on Windows platforms and the passwd file on Linux/UNIX platforms.

This vulnerability can exist either in the web server software itself or in the web application code.

In order to perform a directory traversal attack, all an attacker needs is a web browser and some knowledge on where to blindly find any default files and directories on the system.

What an attacker can do if your site is vulnerable
With a system vulnerable to Directory Traversal, an attacker can make use of this vulnerability to step out of the root directory and access other parts of the file system. This might give the attacker the ability to view restricted files, or even more dangerous, allowing the attacker to execute powerful commands on the web server which can lead to a full compromise of the system.

Depending on how the website access is set up, the attacker will execute commands by impersonating himself as the user which is associated with “the website”. Therefore it all depends on what the website user has been given access to in the system.

Example of a directory traversal attack via web application code
In order to perform a directory traversal attack, all an attacker needs is a web browser and some knowledge on where to blindly find any default files and directories on the system.

Example of a directory traversal attack via web application code
In web applications with dynamic pages, input is usually received from browsers through GET or POST request methods. Here is an example of a GET HTTP request URL:

http://test.webarticles.com/show.asp?view=oldarchive.html

With this URL, the browser requests the dynamic page show.asp from the server and with it also sends the parameter “view” with the value of “oldarchive.html”. When this request is executed on the web server, show.asp retrieves the file oldarchive.htm from the server’s file system, renders it and then sends it back to the browser which displays it to the user. The attacker would assume that show.asp can retrieve files from the file system and sends this custom URL:

http://test.webarticles.com/show.asp?view=
../../../../../Windows/system.ini

This will cause the dynamic page to retrieve the file system.ini from the file system and display it to the user. The expression ../ instructs the system to go one directory up which is commonly used as an operating system directive. The attacker has to guess how many directories he has to go up to find the Windows folder on the system, but this is easily done by trial and error.

Example of a directory traversal attack via web server
Apart from vulnerabilities in the code, even the web server itself can be open to directory traversal attacks. The problem can either be incorporated into the web server software or inside some sample script files left available on the server.

The vulnerability has been fixed in the latest versions of web werver software, but there are web servers online which are still using older versions of IIS and Apache which might be open to directory traversal attacks. Even tough you might be using a web werver software version that has fixed this vulnerability, you might still have some sensitive default script directories exposed which are well known to hackers.

For example, a URL request which makes use of the scripts directory of IIS to traverse directories and execute a command can be:

http://server.com/scripts/..%5c../Windows/System32/
cmd.exe?/c+dir+c:\

The request would return to the user a list of all files in the C:\ directory by executing the cmd.exe command shell file and run the command “dir c:\” in the shell. The %5c expression that is in the URL request is a web server escape code which is used to represent normal characters. In this case %5c represents the character “\”.

Newer versions of modern web server software check for these escape codes and do not let them through. Some older versions however, do not filter out these codes in the root directory enforcer and will let the attackers execute such commands.

How to check for Directory Traversal vulnerabilities
The best way to check whether your web site & applications are vulnerable to Directory Traversal attacks is by using a Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for Directory Traversal vulnerabilities. It will report the vulnerability and how to easily fix it.. Besides Directory Traversal vulnerabilities a web application scanner will also check for SQL injection, Cross site scripting & other web vulnerabilities.

The Acunetix Web Vulnerability Scanner scans for SQL injection, Cross site scripting, Google hacking and many more vulnerabilities. For more information & a trial download click here.

Preventing directory traversal attacks
First of all, ensure you have installed the latest version of your web server software, and sure that all patches have been applied.

Secondly, effectively filter any user input. Ideally remove everything but the known good data and filter meta characters from the user input. This will ensure that only what should be entered in the field will be submitted to the server.

Check if your website is vulnerable to attack with Acunetix Web Vulnerability Scanner

Acunetix Web Vulnerability Scanner ensures website security by automatically checking for SQL injection, Cross site scripting, Directory Traversal  and other vulnerabilities. It checks password strength on authentication pages and automatically audits shopping carts, forms, dynamic content and other web applications. As the scan is being completed, the software produces detailed reports that pinpoint where vulnerabilities exist. Take a product tour or download the evaluation version today!

Scanning for XSS vulnerabilities with Acunetix WVS Free Edition!
To check whether your website has cross site scripting vulnerabilities, download the Free Edition from http://www.acunetix.com/cross-site-scripting/scanner.htm. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site).

Alliance Technology Partners is now offering an expanded inventory of HP Renew Proliant Servers, Desktops, Laptops, Workstations, and Procurve Networking products. SAVE an average of 30-50%!

Alliance Technology Partners is a leading reseller of HP Factory Refurbished products including Refurbished Proliant Servers, Refurbished Procurve Networking Products, Refurbished HP Notebooks, Refurbished HP Computers, Refurbished HP Workstations, and more! In addition, Alliance is Gold ProPartner for Veeam Software. Alliance sells the entire Veeam Product Line including Veeam Backup and Replication, Veeam Reporter Enterprise, Veeam Essentials, Veeam Monitor, Veeam Management Pack for VMware, Veeam Management Suite, Veeam nworks Smart Plug-in for VMware 5.0, and More. Alliance also specializes in web security with the Acunetix Web Vulnerability Scanner.

See our inventory of HP Refurbished Proliant Servers, Notebooks, and Computers

Acunetix Web Vulnerability Scanner placed first in a paper released by Adam Doup´e, Marco Cova, and Giovanni Vigna from the University of California, Santa Barbara.  In the paper “Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners”, the authors compared the capalities of eleven black box web security scanners (both commercial and open source) against a realistic test web application called WackoPicko.

 “In comparison, our work, to the best of our knowledge, performs the largest evaluation of web application scanners in terms of the number of tested tools (eleven, both commercial and open-source), and the class of vulnerabilities analyzed. In addition, we discuss the effectiveness of different configurations and levels of manual intervention, and examine in detail the reasons for a scanner’s success or failure.”

“we decided to create our own test application, called WackoPicko. It is important to note that WackoPicko is a realistic, fully functional web application.  As opposed to a simple test application that contains just vulnerabilities, WackoPicko tests the scanners under realistic conditions. To test the scanners’ support for clientside JavaScript code, we also used the open source Web Input Vector Extractor Teaser (WIVET). WIVET is a synthetic benchmark that measures how well a crawler is able to discover and follow links in a variety of formats, such as JavaScript, Flash, and form submissions.”

Download the paper “Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners” from here.

Should you scan a website through a web application firewall?
Submitted by Robert Abela on May 25, 2010 – 6:58 pm

Unfortunately, it is of frequent occurrence that people launch a security scan against a website or web application sitting behind a web application firewall, or some other kind of web security gateway device.  Scanning a website through a “man in the middle” device or software, will only give a false sense of security.

First and most importantly of all, one would be scanning the web farm’s perimeter network and not the website itself.  Therefore if the scope is to secure a website, this is not the right approach.  If the target website is vulnerable to a SQL injection attack, a web application firewall sitting in front of the website might block the scanner’s requests, resulting in the vulnerability not being discovered and reported.

Some might also argue that there is no need to scan a website when there is a WAF sitting in front of it.  After all, it’s from where the attacker has to go in, right?  As a rule of thumb, security is as weak as your weakest point on the network.  Apart from that, there are a number of other reasons why one still has to scan and audit his website directly, and not through its perimeter network, or nothing at all.

• As we’ve seen in the past, web application firewalls can be exploited and bypassed with a number of freely available tools and scripts.   For a malicious user, bypassing a perimeter network and finding an insecure web application is like discovering a hidden golden treasure.  It will only take him a couple of more minutes until he gains control over the website, the web server and penetrates deeper into the corporate network.
• A web application firewall will only delay attacks, and should not be used as a standalone security solution, as recommended by a number of web application firewall vendors themselves.  Usually a web application firewall is used to help beef up the security of the perimeter network, but never as a website or web application audit replacement.  If the budget permits, it is always a good practise to install one.  New attack vectors are frequently discovered, and unless your web application is properly secured, your application can still be hacked, even if it is sitting behind a web application firewall.
• A web application should always function as it was intended to function.  Simple isn’t it?  E.g. if the “Send Email” button in a web form is clicked, and by mistake an email is sent to support@acunetix.com, instead to sales@acunetix.com, then there is a problem which needs to be fixed.  A web vulnerability is a website malfunction, a problem which has to be fixed, always!

Therefore if the scope of the penetration test or security audit is to secure a website or web application, the security scan must always be launched directly against the target, without any ‘man in the middle’ device or software.  The best practise, as always, is to tackle the problem at source, and not trying to hide it or delay its consequences.  In this case then, one should always secure the web application itself.

Posted from http://www.acunetix.com/blog/web-security-zone/articles/scan-website-web-application-firewall/

Get More Information about the Acunetix Web Vulnerability Scanner at http://www.alliancetechpartners.com/acunetix

Purchase the Acunetix Web Vulnerability Scanner at http://www.alliancetechpartners.com/acunetix/pricelist.htm

SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. It occurs when user input is either incorrectly filtered for escape characters or unexpectedly executed. Lately, this kind of attack was used in the much publicized Heartland breach, so even people outside the IT industry wanted to know what it consists of and how to prevent it. Here is a book that answers those questions.

More at: SQL Injection Attacks and Defense Book
Alliance Technology Partners – Acunetix Web Vulnerability Scanner

The CRLF Injection Attack (sometimes also referred to as HTTP Response Splitting) is a fairly simple, yet extremely powerful web attack.  Hackers are actively exploiting this web application vulnerability to perform a large variety of attacks that include XSS cross-site scripting, cross-user defacement, positioning of client’s web-cache, hijacking of web pages, defacement and a myriad of other related attacks.  A number of years ago a number of CRLF injection vulnerabilities were also discovered in Google’s Adwords web interface.

CRLF Injection attacks and HTTP Response Splitting

The CRLF Injection Attack (sometimes also referred to as HTTP Response Splitting) is a fairly simple, yet extremely powerful web attack.  Hackers are actively exploiting this web application vulnerability to perform a large variety of attacks that include XSS cross-site scripting, cross-user defacement, positioning of client’s web-cache, hijacking of web pages, defacement and a myriad of other related attacks.  A number of years ago a number of CRLF injection vulnerabilities were also discovered in Google’s Adwords web interface.
 
Sounds scary to you? You bet. Are you vulnerable? Quite possibly, and this is why.

CRLF Injection Mechanism

CRLF (Carriage Return and Line Feed) is a very significant sequence of characters for programmers. These two special characters represent the End Of Header marker (EOH) for many Internet protocols, including, but not limited to MIME (e-mail), NTTP (newsgroups) and more importantly HTTP.  When programmers write code for web applications they split headers based on where the CRLF is found. If a malicious user is able to inject his own CRLF sequence into an HTTP stream, he is able to maliciously control the way a web application functions.

A simple CRLF Injection example

Suppose you run a vulnerable website that has a member section. An attacker will send an email to one of your members containing a CRLF-crafted link. This link appears to be legitimate; after all it points to your own website.  The link might look something like the one below:

http://www.yoursite.com/somepage.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3EHacker Content%3C/html%3E

When the victim clicks on the link he will be served with the following HTML page:
 
<html>Hacker Content</html>

This attack appears to simply show the words “Hacker Content” on the victim’s machine however the danger is that YOUR server has generated this HTML code, so effectively the hacker has injected HTML code into the victims browser via YOUR web server! Ouch.  More sophisticated variations of this example can lead to poisioning of the client’s web-cache, cookies, XSS, temporary or permanent defacement of web pages and even information theft.

Example insight

If you look closely at the malicious URL you might notice a few occurences of the pattern %0d%0a. This pattern is the HTTP equivalent of CRLF and is the reason why we call this technique it a CRLF Injection Attack.

Known countermeasures

The only effective countermeasure is to properly sanitize URLs that point to web pages on your site containing any server re-direction code. Finding these holes is not a trivial task; most web applications today are littered with server-side redirects so the location of these vulnerabilities is not always clear, and it is very easy to miss most of them. Normally it can take hundreds of man-hours to test all your web page redirects and therefore it is very common to use an automated tool such as a web vulnerability scanner to find such web vulnerabilities.

Check if your website is vulnerable to CRLF injection

Acunetix Web Vulnerability Scanner ensures website security by automatically checking for CRLF Injection, SQL injection, Cross site scripting attacks and other vulnerabilities. It checks password strength on authentication pages and automatically audits shopping carts, forms, dynamic content and other web applications. As the scan is being completed, the software produces detailed reports that pinpoint where vulnerabilities exist. Take a product tour or download the evaluation version today!

Scanning for XSS vulnerabilities with Acunetix WVS Free Edition!

To check whether your website has cross site scripting vulnerabilities, download the Free Edition from here. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site). http://www.acunetix.com/websitesecurity/crlf-injection.htm

SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks

Incorrectly filtered escape characters

This form of SQL injection occurs when user input is not filtered for escape characters and is then passed into an SQL statement. This results in the potential manipulation of the statements performed on the database by the end user of the application.

The following line of code illustrates this vulnerability:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

This SQL code is designed to pull up the records of the specified username from its table of users. However, if the “userName” variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code author intended. For example, setting the “userName” variable as

a' or 't'='t

renders this SQL statement by the parent language:

SELECT * FROM users WHERE name = 'a' OR 't'='t';

If this code were to be used in an authentication procedure then this example could be used to force the selection of a valid username because the evaluation of ‘t’='t’ is always true.

The following value of “userName” in the statement below would cause the deletion of the “users” table as well as the selection of all data from the “userinfo” table (in essence revealing the information of every user), using an API that allows multiple statements:

a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

This input renders the final SQL statement as follows:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

While most SQL server implementations allow multiple statements to be executed with one call in this way, some SQL APIs such as PHP’s mysql_query() do not allow this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn’t stop them from modifying queries.

[edit] Incorrect type handling

This form of SQL injection occurs when a user supplied field is not strongly typed or is not checked for type constraints. This could take place when a numeric field is to be used in a SQL statement, but the programmer makes no checks to validate that the user supplied input is numeric. For example:

statement := "SELECT * FROM userinfo WHERE id = " + a_variable + ";"

It is clear from this statement that the author intended a_variable to be a number correlating to the “id” field. However, if it is in fact a string then the end user may manipulate the statement as they choose, thereby bypassing the need for escape characters. For example, setting a_variable to

1;DROP TABLE users

will drop (delete) the “users” table from the database, since the SQL would be rendered as follows:

SELECT * FROM userinfo WHERE id=1;DROP TABLE users;

[edit] Vulnerabilities inside the database server

Sometimes vulnerabilities can exist within the database server software itself, as was the case with the MySQL server’s mysql_real_escape_string() function^[2]. This would allow an attacker to perform a successful SQL injection attack based on bad Unicode characters even if the user’s input is being escaped. This bug was patched with the release of version 5.0.22 (released on 24th May 06).

[edit] Blind SQL injection

Blind SQL Injection is used when a web application is vulnerable to an SQL injection but the results of the injection are not visible to the attacker. The page with the vulnerability may not be one that displays data but will display differently depending on the results of a logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must be crafted for each bit recovered. There are several tools that can automate these attacks once the location of the vulnerability and the target information has been established.^[3]

[edit] Conditional responses

One type of blind SQL injection forces the database to evaluate a logical statement on an ordinary application screen.

SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1;

will result in a normal page while

SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2;

will likely give a different result if the page is vulnerable to a SQL injection. An injection like this may suggest to the attacker that a blind SQL injection is possible, leaving the attacker to devise statements that evaluate to true or false depending on the contents of another column or table outside of the SELECT statement’s column list.^[4]

[edit] Conditional errors

This type of blind SQL injection causes an SQL error by forcing the database to evaluate a statement that causes an error if the WHERE statement is true. For example,

SELECT 1/0 FROM users WHERE username='Ralph';

the division by zero will only be evaluated and result in an error if user Ralph exists.

[edit] Time delays

Time Delays are a type of blind SQL injection that cause the SQL engine to execute a long running query or a time delay statement depending on the logic injected. The attacker can then measure the time the page takes to load to determine if the injected statement is true.

[edit] Preventing SQL injection

To protect against SQL injection, user input must not directly be embedded in SQL statements. Instead, parameterized statements must be used (preferred), or user input must be carefully escaped or filtered.

[edit] Parameterized statements

With most development platforms, parameterized statements can be used that work with parameters (sometimes called placeholders or bind variables) instead of embedding user input in the statement. In many cases, the SQL statement is fixed, and each parameter is a scalar, not a table. The user input is then assigned (bound) to a parameter. This is an example using Java and the JDBC API:

PreparedStatement prep = conn.prepareStatement("SELECT * FROM USERS WHERE USERNAME=? AND PASSWORD=?");
prep.setString(1, username);
prep.setString(2, password);
prep.executeQuery();

Similarly, in C#:

using (SqlCommand myCommand = new SqlCommand("SELECT * FROM USERS WHERE USERNAME=@username AND PASSWORD=HASHBYTES('SHA1',
 @password)", myConnection))
    {
        myCommand.Parameters.AddWithValue("@username", user);
        myCommand.Parameters.AddWithValue("@password", pass);

        myConnection.Open();
        SqlDataReader myReader = myCommand.ExecuteReader())
        ...................
    }

In PHP version 5 and above, there are multiple choices for using parameterized statements. The PDO^[5] database layer is one of them:

$db = new PDO('pgsql:dbname=database');
$stmt = $db->prepare("SELECT priv FROM testUsers WHERE username=:username AND password=:password");
$stmt->bindParam(':username', $user);
$stmt->bindParam(':password', $pass);
$stmt->execute();

There are also vendor-specific methods; for instance, using the mysqli^[6] extension for MySQL 4.1 and above to create parameterized statements^[7]:

$db = new mysqli("localhost", "user", "pass", "database");
$stmt = $db -> prepare("SELECT priv FROM testUsers WHERE username=? AND password=?");
$stmt -> bind_param("ss", $user, $pass);
$stmt -> execute();

In ColdFusion, the CFQUERYPARAM statement is useful in conjunction with the CFQUERY statement to nullify the effect of SQL code passed within the CFQUERYPARAM value as part of the SQL clause.^[8][9]. An example is below.

<cfquery name="Recordset1" datasource="cafetownsend">
SELECT *
FROM COMMENTS
WHERE COMMENT_ID =<cfqueryparam value="#URL.COMMENT_ID#" cfsqltype="cf_sql_numeric">
</cfquery>

These solutions do not always work with parameters whose value is a table, such as the right side of an IN expression. For example, many environments do not allow SELECT * FROM ex_users WHERE username IN ('alice', 'bob') to be parameterized as SELECT * FROM ex_users WHERE username IN ? with ? referring to an array supplied by the application. One workaround involves building SQL at run time, looping through an array and escaping each element (see below). Another involves packing into a string in the application and unpacking them with a stored procedure on the server.^[10]

[edit] Enforcement at the database level

Currently only the H2 Database Engine supports the ability to enforce query parameterization.^[11] However, one drawback is that query by example may not be possible or practical because it’s difficult to implement query by example using parametrized queries.

[edit] Enforcement at the coding level

Using object-relational mapping libraries avoids the need to write SQL code. The ORM library in effect will generate parameterized SQL statements from object-oriented code.

[edit] Escaping

A straight-forward, though error-prone, way to prevent injections is to escape characters that have a special meaning in SQL. The manual for an SQL DBMS explains which characters have a special meaning, which allows creating a comprehensive blacklist of characters that need translation. For instance, every occurrence of a single quote (') in a parameter must be replaced by two single quotes ('') to form a valid SQL string literal. In PHP, for example, it is usual to escape parameters using the function mysql_real_escape_string before sending the SQL query:

$query = sprintf("SELECT * FROM Users where UserName='%s' and Password='%s'",
                  mysql_real_escape_string($Username),
                  mysql_real_escape_string($Password));
mysql_query($query);

This is error prone because it is easy to forget to escape a given string.

[edit] Real-world examples

• On November 1, 2005, a high school student used a SQL injection to break into the site of a Taiwanese information security magazine from the Tech Target group and steal customers’ information.^[12]

• On January 13, 2006, Russian computer criminals broke into a Rhode Island government web site and allegedly stole credit card data from individuals who have done business online with state agencies.^[13]

• On March 29, 2006, Susam Pal discovered a SQL injection flaw in an official Indian government tourism site.^[14]

• On March 2, 2007, Sebastian Bauer discovered a SQL injection flaw in the knorr.de login page.^[15]

• On June 29, 2007, a computer criminal defaced the Microsoft U.K. website using SQL injection. ^[16][17]. U.K. website The Register quoted a Microsoft spokesperson acknowledging the problem.

• In January 2008, tens of thousands of PCs were infected by an automated SQL injection attack that exploited a vulnerability in application code that uses Microsoft SQL Server as the database store. ^[18]

• On April 13, 2008, the Sexual and Violent Offender Registry of Oklahoma shut down its website for ‘routine maintenance’ after being informed that 10,597 Social Security numbers from sex offenders had been downloaded via a SQL injection attack^[19]

• In May 2008, a server farm inside China used automated queries to Google’s search engine to identify SQL server websites which were vulnerable to the attack of an automated SQL injection tool. ^[18][20]

• In 2008,at least April through August, a sweep of attacks began exploiting the SQL injection vulnerabilities of Microsoft’s IIS web server and SQL Server database server. The attack doesn’t require guessing the name of a table or column, and corrupts all text columns in all tables in a single request. ^[21] A HTML string that references a malware JavaScript file is appended to each value. When that database value is later displayed to a website visitor, the script attempts several approaches at gaining control over a visitor’s system. The number of exploited web pages is estimated at 500,000^[22]

• On August 17, 2009, the United States Justice Department charged an American citizen Albert Gonzalez and two unnamed Russians with the theft of 130 million credit card numbers using an SQL injection attack. In reportedly “the biggest case of identity theft in American history”, the man stole cards from a number of corporate victims after researching their payment processing systems. Among the companies hit were credit card processor Heartland Payment Systems, convenience store chain 7-Eleven, and supermarket chain Hannaford Brothers.^[23]

• In December 2009, an attacker breached a RockYou! plaintext database containing the unencrypted usernames and passwords of about 32 million users by using a SQL injection attack.^[24]

[edit] References

[edit] External links

• WASC Threat Classification – SQL Injection Entry, by the Web Application Security Consortium
• Why SQL Injection Won’t Go Away, by Stuart Thomas
• SQL Injection Attacks by Example, by Steve Friedl

http://en.wikipedia.org/wiki/SQL_injection

Acunetix Scanner
Acunetix Web Vulnerability