NoSQL Racket : A Testing Tool for Detecting NoSQL Injection Attacks in Web Applications

A NoSQL injection attack targets interactive Web applications that employ NoSQL database services. These applications accept user inputs and use them to form query statements at runtime. During NoSQL injection attack, an attacker might provide malicious query segments as user input which could result in a different database request. In this paper, a testing tool is presented to detect NoSQL injection attacks in web application which is called “NoSQL Racket”. The basic idea of this tool depends on checking the intended structure of the NoSQL query by comparing NoSQL statement structure in code query statement (static code analysis) and runtime query statement (dynamic analysis). But we faced a big challenge, there is no a common query language to drive NoSQL databases like the same way in relational database using SQL as a standardized query language. The proposed tool is tested on four different vulnerable web applications and its effectiveness is compared against three different well known testers, none of them is able to detect any NoSQL Injection attacks. However, the implemented testing tool has the ability to detect the NoSQL injection attacks. Keywords—NoSQL; injection attack; web application; web security; testing tool


I. INTRODUCTION
The recent advance in cloud computing and web applications has created the need to store large amount of data in multi-different databases that provide high availability and scalability.In last years, more and more of companies have adopted different types of non-relational databases, commonly referred to as NoSQL "Not only SQL" databases, and as the applications they serve emerge, they gain wide market interest.The NoSQL databases are not relational by definition and therefore they do not support full SQL functionality, instead of relational databases, they trade consistency and security for performance and scalability.As increasingly sensitive data is being stored in NoSQL databases, security issues become growing concerns [1]- [3].
In this paper we propose a web based tool named "NoSQL Racket".This tool has ability to detect and prevent NoSQL injection attacks in web applications.

II. RELATED WORK
Many researchers have contributed in the area of NoSQL security.Bryan Sullivan [4] explained security issues related to NoSQL databases and differences with relational databases, and what extra set of issues need to be considered when designing and developing systems using these types of data stores.He discussed injection techniques against MongoDB and then moved on to compelling examples of server-side JavaScript injection using Node.js as an example.He discussed risky constructs to look for, during code review and ways to avoid some typical pitfalls.Sooel S. et al. [5], describes the design and implementation of Diglossia, a tool detects code injection attacks on server-side Web applications generating SQL and NoSQL queries.To detect injected code in a generated query, Diglossia parses the query in tandem with its shadow and checks that the two parse trees are syntactically isomorphic, and all code in the shadow query is in shadow characters and, therefore, originated from the application itself, as opposed to user input.Okman, L. et al. [1], discusses two of the most common NoSQL databases (Cassandra and MongoDb) and outlines their main security weaknesses and problems.IBM eBook report [6], it provides a basic introduction to the topic of NoSQL and its rapid growth and adoption.In addition to, it"s focus on two primary areas around data security and protection, and how "IBM InfoSphere Guardium" solutions can help with both of them.
Adrian Lane [7], it examining security for "big data" environments, reviewing built-in protections and weaknesses of these systems which are depending on the Hadoop framework and the other common NoSQL databases (Cassandra, MongoDB, Couch, Riak, etc.).Amreen and Dadapeer [8], Present a reversible watermarking algorithm to provide the security for NoSQL by using a unique watermark to mark the data and by using www.ijacsa.thesai.orgreversible watermarking technique which allows recovery of original data along with the embedded watermark information.Aviv Ron and Alexandra Shulman-Peleg [9], Present a few techniques for attacking NoSQL databases such as injections and CSRF.Also, they present methodologies to mitigate these attacks.

III. INJECTION ATTACKS TYPES
"The OWASP Top 10" [10] and "The 2011 CWE/SANS Top 25" [11] lists injection attack as the most common security risk to web applications.Injection is an entire class of attacks that rely on injecting data into a web application in order to facilitate the execution or interpretation of malicious data in an unexpected manner.Examples of attacks within this class include Cross-Site Scripting (XSS), SQL/NoSQL queries, Header Injection, Log Injection and Full Path Disclosure.
OWASP 2010 defines injection as follows: "Injection flaws occur when an application sends untrusted data to an interpreter.Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc." [12].
But this definition was modified several times by OWASP from 2013 to 2017 and ended up defining injection which includes NoSQL and became as follows: "Injection flaws occur when an application sends untrusted data to an interpreter.Injection flaws are very prevalent, particularly in legacy code.They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc." [10], [13].
Injection attacks have ruled in the top of web application vulnerability reports for much of the past decade.The OWASP Top 10 Project (2013, 2017), which tests and evaluates the most critical threat categories against web applications, places "Unvalidated Input" in the top spot, followed by the related XSS Flaws and Injection Flaws in 3th and 8th place respectively.The CWE/SANS Top 25 Most Dangerous Software Errors list also places high risk on the same issues [11].But for the purpose of this paper, we will be focusing on NoSQL injection attack and will be discussed in the following section.

IV. NOSQL INJECTION ATTACK
NoSQL injection refers to an injection attack through the placement of malicious code (like other web attack ways) in NoSQL statements through web page input controls.The attacker takes the advantage of poorly filtered or not correctly escaped characters within part of NoSQL statements and injects arbitrary data into a string that"s eventually run by the NoSQL database engine (e.g. a login form) as shown in Fig. 1.Web based forms allow somewhat access to back-end NoSQL database to allow adding or modifying the stored data.Any web form, even a simple login form, signup form or search box (where user can input or modify data), might provide access to back-end NoSQL database.This means that there is a high probability for injecting malicious code and attacker can bypasses firewalls and endpoint defenses.
The common reason that a web application is vulnerable to NoSQL injection is incorrect filtering and poor validation for user input.Web forms are quite common to collect data from user.So, practically it is not suitable to lock all the entry points to bar NoSQL injection attackers.To prevent attacks, web developers must apply proper filtration/validation on all forms.For more clarifying, we will show in the following an example for NoSQL injection attack.
Let"s suppose that some PHP web application requests through the screen a user name and a password to access a private area.The application will pick these values and it will www.ijacsa.thesai.orgcollect a query to send to the NoSQL database (e.g.MongoDB).
The MongoDB collection "regusers" contains two documents for authorized users as shown in Fig. 2.
The PHP webpage might look like Fig. 3.  Supposing that is a PHP script selects a document from MongoDB.The following NoSQL query string verifies a username and password combination is valid or not: $collection->find(array("username" => $_GET['username'], "password" => $_GET['password'])); In this case, attacker user can write some texts that will be sent to the NoSQL database (MongoDB) without any verification.Given the case of a malicious user, he could write in the password field the string "$ne" =1 as shown in Fig. 4. In this case, the resulting query will be as follows: $collection->find(array("username" => "drhazem", "password" => array("$ne" => 1))); "$ne" selects the documents where the value of the field is not equal to "1".So, this query will produce the same result as if the admin user had introduced their password correctly.According to this example, the web application will allow the access to administration area to a user who doesn"t know the proper password.

V. PROPOSED TESTING TOOL "NOSQL RACKET"
There are now over 225 NoSQL databases available for use with web applications.Each one offers different features and limitations.So, we faced a big challenge because there is not a common language between web applications and NoSQL databases [10].
For this reason, our proposed tool offers a general testing mechanism for detecting all NoSQL injection attacks without depending on specific syntax and data model.To overcome this challenge, we will create a simple database table named "Driverstbl".The table "Driverstbl" contains all query string forms and its types such as reserved keywords, logical operators and relational operators as shown in Table 1.Each code query statement and runtime query statement transformed into comparative patterns format depending on "Driverstbl" table as shown in Fig. 5.
Step 3: Connect to nosqldbs and select all "String Type" and "Syntax" from "Driverstbl" table where NoSQL Database Type = DBT.
Step 4: Group and count words in S1 and S2 according to selected data in Step3.
Step 6: Set Inj =0 Step 7: For each item in S1 and S2 patterns, repeat until end of items.
Step 8: If Inj =1, then display error page and stop running, else continue running & execute query.
According to the results of matching patterns and input values, there are two decisions: If the patterns are matched, the web application will continue running.
If the patterns are not matched, the web application will be terminated and the proposed algorithm displays an error page.

VI. EXPERIMENTS AND RESULTS
To investigate the effectiveness of the proposed tool "NoSQL Racket", we will examine the detection ability through a comparative study with the most powerful testers for example, Netsparker, Vega and Skipfish.On the other hand, we will use four versions of web pages in our comparative study which covers all NoSQL databases types which are Document based, Column oriented and Key-valued.Each version connected to different NoSQL database which are (MongoDB, Cassandra, CouchDB and Amazon DynamoDB).Also, we will examine the performance for our proposed tool "NoSQL Racket" through performance testing tool called "LoadComplete".

A. Detection Ability Comparative Study
Four PHP web scripts are used for examination purpose and all of them are vulnerable for NoSQL injection attack.These scripts execute after submitting the user login button.When user is submitting with correct username and password against each NoSQL database, output will be "Authorized User", but on the other wise if any one of the field or both are incorrect then the output will be "You are not authorized".

1) MongoDB Detection Ability Results:
In MongoDB, it is possible to inject NoSQL keywords into submitted data from the login webpage.This could for example look like this http://127.0.0.1/phd/MongoDB/after_log.php?user=ahmed &pass[$ne]=1&sbumit1=Submit "$ne" selects the documents where the value of the field is not equal (i.e.!=) to "1".So, this query will produce the same result as if the admin user had introduced their password correctly.According to this example, the web application will allow the access to administration area to a user who doesn"t know the proper password.
The login web page scanned by giving URL to each following scanner tester tool: www.ijacsa.thesai.orgNetsparker testing results are figured out and shown in Fig. 6.Skipfish testing results are figured out are shown in Fig. 7.
Vega testing results are figured out and shown in Fig. 8.The login web page scanned by giving URL to Netsparker, Vega and Skipfish and none of them detect any issues related to NoSQL Injection.But when "NoSQL Racket" used, the NoSQL injection attack detected and testing results are figured out and shown in Fig. 9.

2) Cassandra Detection Ability Results:
In Cassandra, The attacker may enter any user name and a password of: ali'; DROP COLUMNFAMILY 'users This results in a CQL query of: ('select * from reg_users where username = ali and password = ali'; drop columnfamily 'users', ['usern' => ,'passw' => ali'; drop columnfamily 'users]) www.ijacsa.thesai.org The login web page scanned by giving URL to Netsparker, Vega and Skipfish and none of them detect any issues related to NoSQL Injection.But when "NoSQL Racket" used, the NoSQL injection attack detected and testing results are figured out and shown in Fig. 10.The login web page scanned by giving URL to Netsparker, Vega and Skipfish and none of them detect any issues related to NoSQL Injection.But when "NoSQL Racket" used, the NoSQL injection attack detected and testing result is figured out are shown in Fig. 11.

4) Amazon DynamoDB Detection Ability Results:
In Amazon DynamoDB, it is possible to inject NoSQL keywords into submitted data from the login webpage.This could for example look like this: http://127.0.0.1/phd/AmazonDynamoDB/after_log.php?use r=ahmed&pass[$gt]=1&sbumit1=Submit "$gt" selects those documents or keys where the value of the field is greater than (i.e.>) the specified value.Thus above statement compares password in database with empty string for greatness, which returns true.According to this example, the web application will allow the access to administration area to a user who doesn"t know the proper password.
The login web page scanned by giving URL to Netsparker, Vega and Skipfish and none of them detect any issues related to NoSQL Injection.But when "NoSQL Racket" used, the NoSQL injection attack detected and testing result is figured out are shown in Fig. 12. www.ijacsa.thesai.orgThe following Table 2 shows the comparison of detection ability for all testing tools with the proposed tool "NoSQL Racket" over the four NoSQL databases which are used in testing process.
According to scanning results, the most common application injection scanners such as Netsparker, Vega and Skipfish not are able to detect any issues related to NoSQL Injection.However, the proposed implemented approach was able to detect the NoSQL Injection attack.

B. Performance Testing for "NoSQL Racket"
Performance testing is performed on the "NoSQL Racket" using LoadComplete testing tool.The LoadComplete testing tool is the desktop tool for load, stress, testing of website and web application.
The testing process is applied by increasing the number of concurrent users every one second.In this work test is firstly conducted for single user.Then number of concurrent users is increased by 50 concurrent users every one second.The testing environment consists of a machine running Windows 8.1-x64 with Intel core i7 processor and 8 GB RAM.The testing results can be shown in the following graphs: Load Graph: The graph shown in Fig. 13 shows the relation between the number of concurrent users and the test execution time.As showed in the graph, it is observed that the proposed tool "NoSQL Racket" can load 50 simulated concurrent users every one second.Passed Requests Graph: The graph shown in Fig. 14 shows the relation between the number of concurrent users, the number of successfully passed requests and test execution time.As showed in the graph, it is observed that the proposed tool "NoSQL Racket" can pass 47 requests successfully from 50 requests every one second.Page Load Time Graph: Page load time is the time period to download the web page content, including all the HTML tags, images, scripts, CSS files, and so on.The graph shown in Fig. 16 shows the relation between the page load time and the number of concurrent users.As showed in the graph, the maximum page load time is 850 ms and the average page load time is 75 ms.Request Transfer Speed Graph: The request transfer speed refers to the speed of data transfer when the request was sent to the server.
The graph shown in Fig. 17 shows the relation between the number of concurrent users, the Request transfer speed metric and test execution time.As showed in the graph, the slowest speed for the requests transfer is 200 kB/s.Response Transfer Speed Graph: The Response transfer speed refers to the speed of data transfer when the server sent back the response.
The graph shown in Fig. 18 shows the relation between the number of concurrent users, the Response transfer speed metric and test execution time.As showed in the graph, the slowest speed for the responses transfer is 1.52 MB/s.

VII. CONCLUSION
This paper has presented a testing tool for detecting NoSQL Injection attacks which is called "NoSQL Racket", this tool implemented as a PHP function.If no any NoSQL injection attacks detected, it will continue running for the nosql query; if it fails and one or more NoSQL injection attacks detected, it will display error page and stop running for the nosql query.
The proposed tool "NoSQL Racket" has been applied on four different NoSQL Databases which are MongoDB, Cassandra, CouchDB and Amazon DynamoDB.Also, its ability for detection and prevention has been compared with the most powerful web application testing tools which are Netsparker, Vega and Skipfish.According to the scanning results, none of mentioned tools has been able to detect NoSQL

Fig. 1 .
Fig. 1.NoSQL injection attack in web applications.Through vulnerable Web applications, attacker can get unauthorized access to a NoSQL database and can modify or delete data.Currently almost all NoSQL databases such as MongoDB, Hadoop/HBase, Cassandra, CouchDB, and Riak are potentially vulnerable to NoSQL injection attacks.NoSQL injection attack can occur in web applications through some methods, such as Injection through web page input controls and cookie files.

TABLE II .
COMPARISON OF DETECTION ABILITY FOR ALL TESTING TOOLS