1. Authentication
  1. Brute Force

  2. Insufficient Authentication

  3. Weak Password Recovery Validation

2. Authorization
  1. Credential/Session Prediction

  2. Insufficient Authorization

  3. Insufficient Session Expiration

  4. Session Fixation

3. Client-side Attacks
  1. Content Spoofing

  2. Cross-site Scripting

4. Command Execution
  1. Buffer Overflow
  2. Format String Attack
  3. LDAP Injection
  4. OS Commanding
  5. SQL Injection
  6. SSI Injection
  7. XPath Injection
5. Information Disclosure
  1. Directory Indexing

  2. Information Leakage

  3. Path Traversal

  4. Predictable Resource Location

6. Logical Attacks
  1. Abuse of Functionality

  2. Denial of Service

  3. Insufficient Anti-automation

  4. Insufficient Process Validation

SQL Injection

SQL Injection is an attack technique used to exploit web sites that construct SQL statements from user-supplied input.

Structured Query Language (SQL) is a specialized programming language for sending queries to databases. Most small and industrial- strength database applications can be accessed using SQL statements. SQL is both an ANSI and an ISO standard. However, many database products supporting SQL do so with proprietary extensions to the standard language. Web applications may use user-supplied input to create custom SQL statements for dynamic web page requests.

When a web application fails to properly sanitize user-supplied input, it is possible for an attacker to alter the construction of backend SQL statements. When an attacker is able to modify a SQL statement, the process will run with the same permissions as the component that executed the command. (e.g. Database server, Web application server, Web server, etc.). The impact of this attack can allow attackers to gain total control of the database or even execute commands on the system.

The same advanced exploitation techniques available in LDAP Injection can also be similarly applied to SQL Injection.

A web based authentication form might have code that looks like the following: SQLQuery = "SELECT Username FROM Users WHERE Username = '" & strUsername & "' AND Password = '" & strPassword & "'" strAuthCheck = GetQueryResult(SQLQuery) In this code, the developer is taking the user-input from the form and embedding it directly into an SQL query. Suppose an attacker submits a login and password that looks like the following: Login: ' OR ''=' Password: ' OR ''=' This will cause the resulting SQL query to become: SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''='' Instead of comparing the user-supplied data with entries in the Users table, the query compares '' (empty string) to '' (empty string). This will return a True result and the attacker will then be logged in as the first user in the Users table.

There are two commonly known methods of SQL injection: Normal SQL Injection and Blind SQL Injection. The first is vanilla SQL Injection in which the attacker can format his query to match the developer's by using the information contained in the error messages that are returned in the response.

Normal SQL Injection
By appending a union select statement to the parameter, the attacker can test to see if he can gain access to the database:


The SQL server then might return an error similar to this: Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]All queries in an SQL statement containing a UNION operator must have an equal number of expressions in their target lists. This tells the attacker that he must now guess the correct number of columns for his SQL statement to work.

Blind SQL Injection
In Blind SQL Injection, instead of returning a database error, the server returns a customer-friendly error page informing the user that a mistake has been made. In this instance, SQL Injection is still possible, but not as easy to detect. A common way to detect Blind SQL Injection is to put a false and true statement into the parameter value.

Executing the following request to a web site:


should return the same web page as:


because the SQL statement 'and 1=1' is always true.

Executing the following request to a web site:


would then cause the web site to return a friendly error or no page at all. This is because the SQL statement "and 1=0" is always false.

Once the attacker discovers that a site is susceptible to Blind SQL Injection, he can exploit this vulnerability more easily, in some cases, than by using normal SQL Injection.


"SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics http://www.spidynamics.com/support/whitepapers/WhitepaperSQLInjection.pdf

"Blind SQL Injection: Are your Web Applications Vulnerable" - SPI Dynamics

"Advanced SQL Injection in SQL Server Applications", Chris Anley - NGSSoftware

"More advanced SQL Injection", Chris Anley - NGSSoftware

"Web Application Disassembly with ODBC Error Messages", David Litchfield - @stake

"SQL Injection Walkthrough"

"Blind SQL Injection" - Imperva

"SQL Injection Signatures Evasion" - Imperva
http://www.imperva.com/application_defense_center/white_papers/ sql_injection_signatures_evasion.html

"Introduction to SQL Injection Attacks for Oracle Developers" - Integrigy

To receive your Free Application Vulnerability Assessment for testing of one attack vulnerability of your choice, please submit your payment of $1999.00 for a second SQL Injection attack vulnerability test.

Business Name:
Contact Information:
Email Address:
URL or IP address:

Other members of our business group:

COPYRIGHT (C) 2000 - 2013 InfoSecPro.com ALL RIGHTS RESERVED