Hello all list member, OWASPers, and anyone else
interested. Attached there is a document
describing "Direct SQL Commands" submitted by
Rudi Carell which is part of the OWASP project.

This doc will be part of the "Input Validation" section
of the "Classes of Vulnerabilities" list.

As part of the peer review process for OWASP,
we are asking list members for input, suggestions,
comments, or anything that may contribute to
improvement of the text.

Your help is very much appreciated. Also, a big
thanks to Rudi for his contributions thus far

Jeremiah Grossman
OWASP member

Class: Input Validation

Attack Name: Direct SQL Commands

OWASP ID : OWASP-IV-DSC-1

Attack Target: Database - Backend and - or Presentation Layer (Web Server)

Mechanism: HTTP

Description:

Direct SQL commands or SQL-injection is used to alter existing
and/or create new SQL-queries with the aid of an unchecked
input parameter.

With such a technique, it is possible to retrieve sensitive information
from the database system or even from the underlying Operating
System (depending on the DB-libs, modules or classes the web
application uses).

Analysis:

Normally, within web applications, a SQL-query is a string
conglomerated of hard coded query pieces and pieces which are
taken from user input (html-form variables for example). After
such a query string is completed, it gets passed to the database
system, executed and committed (if necessary). The result are then
passed back to the application and can be used for further
processing.

If the application does not validate and/or sanitize the user input,
the SQL-query can be altered in various fashions.

With the aid of database and application error messages, it is
possible to obtain information on the database system.

Dependent on the database interface it is possible to:

- Mutilate a SQL-statement
- Alter a single SQL-statement
- Add additional SQL-statements
- Call functions and stored-procedures within altered statement
- Typecast and concatenate retrieved database data

This can be misused to:

- Obtain additional information on the software and systems
- Authenticate without providing credentials
- Extract sensitive database information
- Change the flow/sequence of applications
- Identify the table and database structures
- Gain access to used operating-system

Stated below are short summaries of problems with popular
database-systems:

MYSQL
- Supports 'INTO OUTFILE'
- Runs often as "root", including modules and libs do not support
multiple statements.

ORACLE
- Subselects possible
- UNION possible
- Comes with many stored procedures (utf_file!)
and no multiple-statements

DB2
- Subselects possible
- UNION possible
- Stored procedures
and no multiple-statements

POSTGRES
- Supports COPY (if superusermode)
- Subselects possible
- UNION possible
- Stored procedures
- Multiple statements are possible!

MSSQL

- Subselects possible
- UNION possible
- Stored procedures
- Multiple statements are possible!
- Many dangerous default-stored-procedures
(xp_cmdshell, sp_adduser)

It is rarely possible to perform a DOS attack with the
help of SQL-Commands (by creating a huge VIEW for example).

Test:
View the testing methodology section on SQL-Injection

Countermeasures:

-Never pass unchecked user input to database queries.
-Validate and sanitize every user variable passed to the database.
-Check if given input has the expected data type.
-Quote user input which is passed to the database.

Most of the common database-libraries, modules and classes provides the
programer with proper working quoting-mechanisms.

-Do not output error messages and exceptions in a
production environment.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]