4.0

130
Web Application Penetration Testing
possible to extract the first character of the username on a specifically
selected row. As the inner query returns a set of records, and not just
one, it is not possible to use it directly. Fortunately, we can combine
multiple functions to extract a specific string.
Let’s assume that we want to retrieve the username of the 10th row.
First, we can use the TOP function to select the first ten rows using
the following query:
SELECT TOP 10 username FROM users
Then, using this subset, we can extract the last row by using the
LAST function. Once we have only one row and exactly the row
containing our string, we can use the IFF, MID and LAST functions
to infer the actual value of the username. In our example, we employ
IFF to return a number or a string. Using this trick, we can
distinguish whether we have a true response or not, by observing
application error responses. As id is numeric, the comparison with
a string results in a SQL error that can be potentially leaked by 500
Internal Server Error pages. Otherwise, a standard 200 OK page
will be likely returned.
For example, we can have the following query:
http: /www.example.com/index.php?id=’%20AND%20
1=0%20OR%20’a’=IIF((select%20MID(LAST(username),1,1)%20from%20(select%20TOP%2010%20username%20from%20users))=’a’,’a’,’b’)%00
that is TRUE if the first character is ‘a’ or false otherwise.
As mentioned, this method allows to infer the value of arbitrary
strings within the database:
[1] By trying all printable values, until we find a match
[2] By inferring the length of the string using the LEN function,
or by simply stopping after we have found all characters
Time-based blind SQL injections are also possible by abusing
heavy queries.
References
• http: /nibblesec.org/files/MSAccessSQLi/MSAccessSQLi.html
• http: /packetstormsecurity.com/files/65967/Access-Through-
Access.pdf.html
• http: /seclists.org/pen-test/2003/May/74
• http: /www.techonthenet.com/access/functions/index_
alpha.php
• http: /en.wikipedia.org/wiki/Microsoft_Access
Testing for NoSQL injection
Summary
NoSQL databases provide looser consistency restrictions than
traditional SQL databases. By requiring fewer relational constraints
and consistency checks, NoSQL databases often offer
performance and scaling benefits. Yet these databases are still
potentially vulnerable to injection attacks, even if they aren’t using
the traditional SQL syntax. Because these NoSQL injection attacks
may execute within a procedural[1] language , rather than in
the declarative[2] SQL language, the potential impacts are greater
than traditional SQL injection.
NoSQL database calls are written in the application’s programming
language, a custom API call, or formatted according to a
common convention (such as XML, JSON, LINQ, etc). Malicious
input targeting those specifications may not trigger the primarily
application sanitization checks. For example, filtering out common
HTML special characters such as < > & ; will not prevent attacks
against a JSON API, where special characters include / { } : .
There are now over 150 NoSQL databases available[3] for use
within an application, providing APIs in a variety of languages and
relationship models. Each offers different features and restrictions.
Because there is not a common language between them,
example injection code will not apply across all NoSQL databases.
For this reason, anyone testing for NoSQL injection attacks will
need to familiarize themselves with the syntax, data model, and
underlying programming language in order to craft specific tests.
NoSQL injection attacks may execute in different areas of an application
than traditional SQL injection. Where SQL injection would
execute within the database engine, NoSQL variants may execute
during within the application layer or the database layer, depending
on the NoSQL API used and data model. Typically NoSQL injection
attacks will execute where the attack string is parsed, evaluated,
or concatenated into a NoSQL API call.
Additional timing attacks may be relevant to the lack of concurrency
checks within a NoSQL database. These are not covered under
injection testing. At the time of writing MongoDB is the most
widely used NoSQL database, and so all examples will feature
MongoDB APIs.
How to Test
Testing for NoSQL injection vulnerabilities in MongoDB:
The MongoDB API expects BSON (Binary JSON) calls, and includes
a secure BSON query assembly tool. However, according to MongoDB
documentation - unserialized JSON and JavaScript expressions
are permitted in several alternative query parameters.[4]
The most commonly used API call allowing arbitrary JavaScript
input is the $where operator.
The MongoDB $where operator typically is used as a simple filter
or check, as it is within SQL.
db.myCollection.find( { $where: “this.credits == this.debits”
} );
Optionally JavaScript is also evaluated to allow more advanced
conditions.
db.myCollection.find( { $where: function() { return obj.credits
- obj.debits < 0; } } );
Example 1
If an attacker were able to manipulate the data passed into the
$where operator, that attacker could include arbitrary JavaScript
to be evaluated as part of the MongoDB query. An example vulnerability
is exposed in the following code, if user input is passed