1BO4r2U

127 128
Web Application Penetration Testing
Web Application Penetration Testing
where name is the .mdb filename and table is a valid database table. In
case of password protected databases, multiple software utilities can
be used to crack the password. Please refer to the references.
Blind SQL Injection Testing
Blind SQL Injection vulnerabilities are by no means the most easily exploitable
SQL injections while testing real-life applications. In case of
recent versions of MS Access, it is also not feasible to execute shell
commands or read/write arbitrary files.
In case of blind SQL injections, the attacker can only infer the result of
the query by evaluating time differences or application responses. It is
supposed that the reader already knows the theory behind blind SQL
injection attacks, as the remaining part of this section will focus on MS
Access specific details.
The following example is used:
http:/www.example.com/index.php?myId=[sql]
where the id parameter is used within the following query:
SELECT * FROM orders WHERE [id]=$myId
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%201=0%20
OR%20’a’=IIF((select%20MID(LAST(username),1,1)%20
from%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
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.
With normal SQL injection, a similar vulnerability would allow an attacker
to execute arbitrary SQL commands - exposing or manipulating
data at will. However, because JavaScript is a fully featured language,
not only does this allow an attacker to manipulate data, but also to
run arbitrary code. For example, instead of just causing an error when
testing, a full exploit would use the special characters to craft valid JavaScript.
This input 0;var date=new Date(); do{curDate = new Date();}while(cur-
Date-date