4.0

130Web Application Penetration Testingpossible to extract the first character of the username on a specificallyselected row. As the inner query returns a set of records, and not justone, it is not possible to use it directly. Fortunately, we can combinemultiple 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 usingthe following query:SELECT TOP 10 username FROM usersThen, using this subset, we can extract the last row by using theLAST function. Once we have only one row and exactly the rowcontaining our string, we can use the IFF, MID and LAST functionsto infer the actual value of the username. In our example, we employIFF to return a number or a string. Using this trick, we candistinguish whether we have a true response or not, by observingapplication error responses. As id is numeric, the comparison witha string results in a SQL error that can be potentially leaked by 500Internal Server Error pages. Otherwise, a standard 200 OK pagewill be likely returned.For example, we can have the following query:http: /www.example.com/index.php?id=’%20AND%201=0%20OR%20’a’=IIF((select%20MID(LAST(username),1,1)%20from%20(select%20TOP%2010%20username%20from%20users))=’a’,’a’,’b’)%00that is TRUE if the first character is ‘a’ or false otherwise.As mentioned, this method allows to infer the value of arbitrarystrings 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 charactersTime-based blind SQL injections are also possible by abusingheavy 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_AccessTesting for NoSQL injectionSummaryNoSQL databases provide looser consistency restrictions thantraditional SQL databases. By requiring fewer relational constraintsand consistency checks, NoSQL databases often offerperformance and scaling benefits. Yet these databases are stillpotentially vulnerable to injection attacks, even if they aren’t usingthe traditional SQL syntax. Because these NoSQL injection attacksmay execute within a procedural[1] language , rather than inthe declarative[2] SQL language, the potential impacts are greaterthan traditional SQL injection.NoSQL database calls are written in the application’s programminglanguage, a custom API call, or formatted according to acommon convention (such as XML, JSON, LINQ, etc). Maliciousinput targeting those specifications may not trigger the primarilyapplication sanitization checks. For example, filtering out commonHTML special characters such as < > & ; will not prevent attacksagainst a JSON API, where special characters include / { } : .There are now over 150 NoSQL databases available[3] for usewithin an application, providing APIs in a variety of languages andrelationship 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 willneed to familiarize themselves with the syntax, data model, andunderlying programming language in order to craft specific tests.NoSQL injection attacks may execute in different areas of an applicationthan traditional SQL injection. Where SQL injection wouldexecute within the database engine, NoSQL variants may executeduring within the application layer or the database layer, dependingon the NoSQL API used and data model. Typically NoSQL injectionattacks 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 concurrencychecks within a NoSQL database. These are not covered underinjection testing. At the time of writing MongoDB is the mostwidely used NoSQL database, and so all examples will featureMongoDB APIs.How to TestTesting for NoSQL injection vulnerabilities in MongoDB:The MongoDB API expects BSON (Binary JSON) calls, and includesa secure BSON query assembly tool. However, according to MongoDBdocumentation - unserialized JSON and JavaScript expressionsare permitted in several alternative query parameters.[4]The most commonly used API call allowing arbitrary JavaScriptinput is the $where operator.The MongoDB $where operator typically is used as a simple filteror check, as it is within SQL.db.myCollection.find( { $where: “this.credits == this.debits”} );Optionally JavaScript is also evaluated to allow more advancedconditions.db.myCollection.find( { $where: function() { return obj.credits- obj.debits < 0; } } );Example 1If an attacker were able to manipulate the data passed into the$where operator, that attacker could include arbitrary JavaScriptto be evaluated as part of the MongoDB query. An example vulnerabilityis exposed in the following code, if user input is passed