Interaction with relational databases takes place through a textual language, the Structured Query Language ('SQL'). The most recent standard is ANSI SQL-92 and forms the basis around which most
SQL dialects are based today. See SQL syntax diagrams for a visualization of SQL syntax. Data extraction from the
database takes place through a 'query', which is a collection of SQL statements. An SQL query returns the data in a so-called 'result set'.
SQL statements are divided into two general categories: those that can modify the structure (Data Definition Language statements, or 'DDL') and those that can manipulate the contents of databases
(Data Manipulation Language statements, or 'DML'). SQL Injection occurs when an attacker is able to insert a series of SQL statements into a 'query' by manipulating data input into an application
(see Advanced SQL Injection in SQLServer Applications).
The typical scenario of an SQL Injection goes like this: an SQL statement like (taken from mainfile.php)
SELECT active FROM ".$prefix."_modules WHERE title='$module'
|
is used to retrieve the 'active' column from the 'nuke_modules' table (assuming that $prefix is set to 'nuke' in config.php, see Section 3.7), returning in the
'result set' only the row that matches the module $module. An important point to note here is that the string literal '$module' is delimited with single quotes. Presuming that $module is taken from
the URL or from user input and was not subjected to further scrutiny, one could use a "module name" of
' UNION ALL SELECT user_password FROM nuke_users WHERE "='
|
and the 'query string' would become:
SELECT active FROM ".$prefix."_modules
WHERE title=" UNION ALL SELECT user_password FROM nuke_users WHERE "="
|
The database server would execute the first part
SELECT active FROM ".$prefix."_modules WHERE title="
|
and would find no modules with empty title. It would then combine this empty result set with the outcome of
SELECT user_password FROM nuke_users WHERE "="
|
which selects all passwords (since the WHERE clause is tautologically true, comparing an empty string with itself), returning the "cartesian product" (UNION) of the two - i.e. the set of all
passwords. If the outcome of such a query is supposed to be printed somewhere, the user will be able to see sensitive information.
If the "module name" passed on unchecked were
' ; DROP TABLES WHERE "='
|
the consequences would be catastrophic: the database server would execute
SELECT active FROM ".$prefix."_modules WHERE title=" ; DROP TABLES WHERE "="
|
Depending on the actual SQL query, you may have to try some of these possibilities for the WHERE clause:
' or 1=1--
" or 1=1--
or 1=1--
' or 'a'='a
" or "a"="a
') or ('a'='a
|
instead of
The general rule is that to "break out" of the quotes and manipulate the SQL query, while maintaining valid SQL syntax, your query string must start with a quote and end in a WHERE clause that
needs a query appended to it (see SQL Injection).
In PHP-Nuke, SQL injection has been reported in the following vulnerabilities:
-
The "cid" parameter isn't properly verified in the "Downloads" module. This can be exploited to manipulate the SQL query and may potentially allow bypassing authentication or reveal sensitive
information (see PHP-Nuke SQL Injection Vulnerability).
-
Numeric values in the Web_Links module aren't validated before they are used in SQL queries. Example:
/modules.php?op=modload&name=Web_Links&file=index&l_op=viewlink&cid=2%20malicious_SQL
|
(see PHP-Nuke SQL injection). You wonder how malicious_SQL might look like? Here is a real world example from my web server
logs:
/modules.php?name=Web_Links&l_op=viewlink&cid=2
%20UNION%20select%20counter,%20pwd,%20aid%20FROM%20nuke_authors%20
|
-
Several input validation errors, which could be exploited by malicious people to manipula te existing SQL queries by conducting SQL injection attacks against the application, see PHP-Nuke SQL Injection.
-
Input validation errors in the modules "Members_List" and "Your_Account", which can be exploited by conducting a SQL injection attack, see PHP-Nuke Multiple SQL Injection Vulnerabilities.
-
Vulnerabilities can be exploited to manipulate existing SQL queries, which can result in disclosure of the Admin user's password hash. This can afterwards be used to gain administrative priviliges
for PHP-Nuke, see PHP-Nuke Multiple SQL Injection Vulnerabilities.