Query manipulation

We consider SQL injection (SQLI), XPath injection (XPathI), LDAP injection (LDAPI) and NoSQL injection (NoSQLI) vulnerabilities as belonging to the same category. They are asso- ciated to the construction of queries or filters that are executed by some kind of engine, e.g., a database management system (DBMS). SQLI is the best known and exploited vulnerability (Williams & Wichers, 2013). The other three vulnerabilities behave similarly to SQLI, i.e., if a query is constructed with unsanitized user inputs containing malicious characters, then it is possible to modify the behavior of the executed query (OWASP, 2014b; Scambrayet al., 2011). Next, each vulnerability is presented.

SQL injection

SQL injection (SQLI) vulnerabilities are caused by the use of string-building functions to create SQL queries. SQLI attacks mix normal characters with metacharacters to alter

2.1 Input Validation Vulnerabilities in Web Applications

the structure of the query and read or write the database in an unexpected way. Listing 2.1 shows PHP code vulnerable to SQLI. This script inserts in a SQL query (line 4) the username and password provided by the user (lines 2, 3). If the user is malicious, he can provide as usernameadmin’ - - , causing the script to execute a query that returns information about the user adminwithout the need to provide a password: SELECT * FROM users WHERE username=‘admin’ - - ’ AND password=‘foo’ (note that - - cause the characters to its right to be interpreted as a comment).

1 $conn = mysql_connect("localhost", "username", "password");

2 $user = $_POST[’user’];

3 $pass = $_POST[’password’];

4 $q = "SELECT * FROM users WHERE username=’$user’ AND password=’$pass’";

5 $result = mysql_query($q);

Listing 2.1: PHP login script vulnerable to SQLI.

This vulnerability can be removed either by sanitizing the inputs (e.g., preceding with a backslash metacharacters such as the prime) or by using prepared statements. Sanitization depends on the sensitive sink, i.e., on the way in which the input is used. For the MySQL engine, PHP provides the mysql_real_escape_stringfunction. The username could be sanitized in line2: $user = mysql_real_escape_string($_POST[’user’]);

(note that the same should be done in line 3 to protect the password).

XPath injection

XPath injection (XPathI) works similarly to SQLI, but data is injected in XML docu- ments. XML documents are usually used to store application configuration data or applica- tion user information such as user credentials, roles, and privileges (Stuttard & Pinto, 2007).

Unlike SQL, XPath does not have a comment character, so if a query contains more than one input parameter the injected code has to be sufficient to build a valid query. Listing 2.2 shows PHP code vulnerable to XPathI. This script inserts in a XPath query (line 4) the username and password provided by the user (lines 2, 3). An attacker can provide as usernameadmin’ or 1=1 or ’a’=’b, causing the script to execute a query that returns information about the useradminwithout the need of giving a password: //addresses[susername/text()=

’admin’ or 1=1 or ’a’=’b’ and password/text()=”]/creditCard/text()

1 $xml = simplexml_load_file("addresses.xml");

2 $user = $_POST[’user’];

3 $pass = $_POST[’password’];

4 $query = "//addresses[susername/text()=’".$user."’ and password/text()=’".$pass."’]/creditCard/text()";

5 $result = $xml->xpath($query);

Listing 2.2: PHP login script vulnerable to XPathI.

This vulnerability can be prevented by checking if the user input contains the following malicious characters: ( ) = ’ [ ] : , * /. For the above example, the input would be rejected because the prime character is matched.

LDAP injection

LDAP (Lightweight Directory Access Protocol) injection (LDAPI) vulnerabilities are also exploited by providing metacharacters to string-building functions. Their exploitation aims to modify the structure of the filter and retrieve data from a directory (a hierarchically organized data store (Stuttard & Pinto, 2007)) service over the network, in an unexpected way. However, unlike SQL, LDAP does not contain the comment character, meaning that the malicious input has to be inserted in the first parameter of the filter and contain some filter structure that will cause the intended filter structure to be ignored (Alonsoet al., 2009).

The PHP code presented in the Listing 2.3 validates an user in a directory using the user- name and password credentials provided by the user. This script inserts in a filter (line 6) the required credentials (lines 4, 5). If an attacker provides as usernameBob)(&))and as passwordanyWord, he causes the script to execute a filter that returns information (userID, name, mail and creditCard) about the user Bob without the need of providing a correct password. The resulting filter: (&(username=Bob)(&)) does not contain the second pa- rameter ((password=$pass)) because it is substituted by(&). A solution to prevent this vulnerability is to validate the user inputs, checking if they match with some of the following characters( ) ; , * | & =(Stuttard & Pinto, 2007).

2.1 Input Validation Vulnerabilities in Web Applications

1 $ds = ldap_connect("ldap.server.com");

2 $r = ldap_bind($ds);

3 $dn = "ou=Bank foo of city XXX,o=Bank foo,c=PT";

4 $user = $_POST[’user’];

5 $pass = $_POST[’password’];

6 $filter = "(&(username=$user)(password=$pass))";

7 $fields = array("userID", "name", "mail", "creditCard");

8 $result = ldap_search($ds, $dn, $filter, $fields);

Listing 2.3: PHP login script vulnerable to LDAPI.

NoSQL injection

NoSQL is a common designation for non-relational databases used in many large-scale web applications. There are various NoSQL database models and many engines that im- plement them. MongoDB (MongoDB, 2015) is the most popular engine implementing the document store model (DB-Engines, 2015). Thereby, we opted for studding the NoSQL injection (NoSQLI) vulnerability in PHP web applications that connect to MongoDB. Mon- goDB executes queries in JSON format, which is well defined, simple to encode/decode and has good native implementations in many programming languages (Ronet al., 2015). There- fore, a PHP application receives user inputs, represents them as an associative array, and then implicitly encodes the array in JSON.

1 $conn = new MongoClient("mongodb.server.com");

2 $db = $conn->selectDB(’foo’);

3 $collection = new MongoCollection($db, ’users’);

4 $user = $_POST[’user’];

5 $pass = $_POST[’password’];

6 $query = array("username" => $user, "password" => $pass);

7 // line 9 does the following codification implicitly:

8 // $query = "{username: ’" + $user + "’, password: ’" + $pass + "’}";

9 $result = $collection->find($query);

Listing 2.4: PHP login script vulnerable to NoSQLI.

Listing 2.4 shows PHP code vulnerable to NoSQLI. This script aims to find a user in the MongoDB database after the username and password are provided by the user (lines 4, 5). If the user is malicious he can sent the following payloaduser=admin&password[$ne]=1,

assigning admin to the user parameter (line 4) and changing the password parameter to password[$ne] and assigning it the value 1 (line 5). This malicious code generates an associative array array(“username“ => “admin”, “password” => array(“$ne”

=> 1)) (line 6). It is encoded in JSON as ^{username: ’admin’, password: {

$ne: 1 }}and sent to be executed by MongoBD (line 9). The query returns information about the user admin without the need of giving a correct password, since $ne is the not equal condition in MongoDB.

Defending against this vulnerability is possible using one of three measures: (1) casting the parameters received from the user to the proper type (Ronet al., 2015); In Listing 2.4 the username would be cast tostringby changing$user = (string)$_POST[’user’];

(line 4); (2) using the mysql_real_escape_stringPHP sanitization function to invali- date the same malicious characters as SQLI, such as the prime; (3) validating the user inputs, checking if they match with some of the following characters< > & ; / { } : ’ *

“(OWASP, 2014b).