NoSQL Injection Attack Detection in Web Applications Using RESTful Service

This paper presents an independent RESTful web service in a layered approach to detect NoSQL injection attacks in web applications. The proposed method is named DNIARS. DNIARS depends on comparing the generated patterns from NoSQL statement structure in static code state and dynamic state. Accordingly, the DNIARS can respond to the web application with the possibility of NoSQL injection attack.

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/331577742
NoSQL Injection Attack Detection in Web Applications Using RESTful Service
Article in Programming and Computer Software · November 2018
DOI: 10.1134/S036176881901002X
CITATIONS
0
READS
83
4 authors:
Some of the authors of this publication are also working on these related projects:
Landmines detection using mobile robotsView project
Intelligent applications in smart citiesView project
Ahmed M. Eassa
Modern Technology and Information University
3 PUBLICATIONS5 CITATIONS
SEE PROFILE
Mohamed Elhoseny
Mansoura University
154PUBLICATIONS1,560CITATIONS
SEE PROFILE
Hazem M El-Bakry
Mansoura University
347PUBLICATIONS2,963CITATIONS
SEE PROFILE
Ahmed S. Salama
Sadat Academy for Management Sciences
16PUBLICATIONS162CITATIONS
SEE PROFILE
All content following this page was uploaded by Ahmed M. Eassa on 07 March 2019.
The user has requested enhancement of the downloaded file.

435
ISSN 0361-7688, Programming and Computer Software, 2018, Vol. 44, No. 6, pp. 435–444. © Pleiades Publishing, Ltd., 2018.
NoSQL Injection Attack Detection
in Web Applications Using RESTful Service1
Ahmed M. Eassaa,b,
*, Mohamed Elhosenya, Hazem M. El-Bakrya,
and Ahmed S. Salamac,d
aFaculty of Computers and Information, Mansoura University, Mansoura, Egypt
bManagement Information Systems Department, Faculty of Management, MTI University, Cairo, Egypt
cComputer and Information Systems Department, Sadat Academy for Management Sciences, Cairo, Egyp
dInformation Systems Department, Faculty of Computing and Information Technology, University of Jeddah, Jed
*e-mails: [e-mail]
Received June 20, 2018
Abstract—Despite the extensive research of using web services for security purposes, there is a big challe
towards finding a no radical solution for NoSQL injection attack. This paper presents an independent REST-
ful web service in a layered approach to detect NoSQL injection attacks in web applications. The proposed
method is named DNIARS. DNIARS depends on comparing the generated patterns from NoSQL statement
structure in static code state and dynamic state. Accordingly, the DNIARS can respond to the web applica-
tion with the possibility of NoSQL injection attack. The proposed DNIARS was implemented in PHP plain
code and can be considered as an independent framework that has the ability for responding to different
requests formats like JSON, XML. To evaluate its performance, DNIARS was tested using the most common
testing tools for RESTful web service. According to the results, DNIARS can work in real environme
where the error rate did not exceed 1%.
Keywords: web service, RESTful, NoSQL, injection attack, web application, web security
DOI: 10.1134/S036176881901002X
1. INTRODUCTION
RESTful web service has become one of the most
important technologies that support web applications
to communicate with each other via API and for com-
municating with the other web services. RESTful web
services are basically REST architecture based web
services.REST standsfor RepresentationalState
Transfer.In REST architectureeverythingis a
resource. Each RESTful service has a set of URIs that
communicate with other services or web applications
directly through some HTTP verbs or methods such as
POST, GET, PUT, PATCH, and DELETE [1]. The
RESTful service can handle different formats when
requesting a service or responding to a request such as
JSON and XML and each RESTful service may return
either JSON or XML depending upon the request [2].
Some of the web applications connected to one or
more web services and databases to request, response
and hold data and information that needed and recall
it when necessary. Some organizations have adopted
different types of new databases, known as NoSQL
databases, NoSQL databases designed to support the
requirements of Big Data and cloud applications by
offering a more flexible, scalable, and less expensive
alternative to relational databases (RDBMS). With
increasingly sensitive data being stored in NoSQL
databases, there have been growing concerns about
security [3]. Many of web applications deployed by
organizations for e-business operations involve high
reliability,efficiencyand confidentiality.But on
another side, the attackers may exploit some security
holes where they can gain access to a web application
as anauthorized user. And thus, they have the ability to
access data and information within the web applica-
tion. Injection attacks have been classified as the top of
web application attacks in vulnerability reports for
much of the past decade. Although there are many
types of injection attacks has been explored and dis-
cussed by many researchers, but the NoSQL injection
attackstill doesn’ttake enoughattentionby the
researchers. So, we will be focusing on NoSQL injec-
tion attackas the main purposeof this paper.
A NoSQL injectionattacktargetsinteractiveWeb
applications that are connected to any type of NoSQL
databases. This type of attack allows an attacker to
inject code into a NoSQL query which could result in
a different database request that can read or modify a
NoSQL database, or change data on a web application1 The article is published in the original.

436
PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
EASSA et al.
[4–7]. In general, web forms allow an end user to
manipulate back-end NoSQL databases directly by
adding, modifying, or deleting data. For example,
when an end user searches for a specific product from
the web application, the query is encapsulated with the
required data in the web form. Here lies the risk, where
the attacker can inject malicious code that is encapsu-
lated with the query statement and therefore the query
will apply another function [8].
In this paper, we propose an independent RESTful
service. This service has the ability to detect and pre-
vent NoSQL injection attacks in web applications.
The rest of this paperis organizedas follows:
We discuss related work in Section 2. In Sections 3 and 4,
we introduce our motivation and the main challenge
of detecting NoSQL injection attacks. Section 5 dis-
cusses the most common variants of NoSQL injection
attacks. Sections 6 and 7 discuss the DNIARS archi-
tecture and its implementation. Section 8 presents the
results of our evaluation. Finally, we conclude in Sec-
tion 9.
2. RELATED WORK
There are many researches related to our research
and it will be discussed in three main directions. On
the first direction, many researchers have contributed
in the area of web application security. For example,
and not as a limitation, Victor Prokhorenko et al. [9]
presented a novel classification for the web application
protection techniques and also discuss some issues
and limitations that are related to the current protec-
tion techniques. Osama M. Rababah et al. [10], pre-
sented a framework for the detecting and preventing of
web threats such as SQL injection, XSS, DDos and
user suspicious behavior. Atefeh Tajpour et al. [11],
investigated the ability of detecting SQL injection
attack using some detecting tools such as AMNESIA,
SecuriFly and SQLPrevent. Gajanan P. et al. [12], pre-
senteda surveyof varioustraditionaland recent
approaches for detecting and preventing web application
attacks and provide the limitation for each approach.
On the second direction, many researchers have
presented different usages of web services for security
purposes. Specifically, the using of web service for
detecting many types of injection attacks in web appli-
cations and web services itself like SQL Injection
attack. Shri V. Shanmughaneethi et al. [13], presented
an independentlayeredweb serviceapproachfor
detecting the SQL Injection attacks in a web applica-
tion via analyzing SQL query structure and validate
the user inputs. Sadeeq Jan et al. [14] provided an
approach for the automated security testing of web
applications that they act as front-ends to the web ser-
vices with a focus on XMLi vulnerabilities. Rahul
Shrivastava et al. [15] presented a survey on different
classesof SQLIA and some of the important
approaches for detection of SQLIA and also present a
techniquewhich is called Web ServiceOriented
XPATH Authentication Technique. Varsha R Mouli
and KP Jevitha [16] presented a survey on the most
common web service attacks by analyzing morethan
35 papers, and the most addressed attacks are Denial-
of-Service attacks followed by XML injection attacks.
On the third direction, many researchers have con-
tributed in NoSQL security. Ahmed M. Eassa et al.
[4], presented a testing tool for detecting NoSQL
injection attacks in web Applications. This tool offers
a general testing mechanism for detecting all NoSQL
injection attacks without depending on specific syntax
and data model. Okman, L. et al. [5], discusses the
main functionality and security features of the most
common NoSQL databases which are (Cassandra and
MongoDB) and outlines their main security weak-
nesses and problems. IBM eBook report [17], it pro-
vided a basic introduction to NoSQL and the security
implications for NoSQL with a focus on two primary
areas around data security and protection. Adrian
Lane [18] examined the security for Big Data environ-
ments which are depending on the Hadoop framework
and the other common NoSQL databases (Cassandra,
MongoDB, Couch, Riak, etc.). Amreen and Dadap-
eer [19], presented a reversible watermarking tech-
nique to provide more protection and security for
NoSQL databases in terms of ownership protection
and tamer proofing for a wide range of data formats.
Aviv Ron and Alexandra Shulman-Peleg [20], pre-
sented a few techniques for attacking NoSQL data-
bases such as injections and CSRF and analyze the
source of these vulnerabilities and present methodol-
ogies to mitigate the attacks. Neha Gupta and Rashmi
Agrawal [21], presented a chapter that discuss the
security features of the most common NoSQL data-
bases and also provide some techniques to mitigate the
attacks on NoSQL databases. Boyu Hou et al. [22],
examined the maturity of security measures for one of
the NoSQL databases which is MongoDB and dis-
cusses two methods for preventing NoSQL injection
attack. S. Priyadharshini and R. Rajmohan [23], pro-
vided a model for design appropriate security mecha-
nism for securing NoSQL databases using network
authenticationprotocolwhich is called Kerberos.
Ebrahim Sahafizadeh et al. [24] present some security
issues in big data and highlight the security and privacy
challenges in big data infrastructures and NoSQL data-
bases. Sooel S. et al. [25], described the design an
implementation of a tool which is called Diglossia. This
tool detects code injection attacks on server-side web
applications generating SQL and NoSQL queries.
According to the related work, there is no relevant
study contributes to the area of detecting NoSQL
injection attack using web services. Thus this research
covers a new area which is not covered before.

PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
NoSQL INJECTION ATTACK DETECTION 437
3. BACKGROUND
AND PROBLEM STATEMENT
The Open Web ApplicationSecurityProject
(OWASP) is a worldwidenon-profit organization
focused on generating security reports about the most
critical web application security risks. Since 2003,
OWASP has been releasing the OWASP Top 10 list
every four/three years. During 2013, The OWASP
organization released a new report of the most com-
mon security attacks, and the injection attack was
indexed in the first position in this report as the most
common attack type in web applications, in addition
to, a new type of injection attacks appeared in the defi-
nition of injection attack category, which is NoSQL
injection where it has not been shown in the 2010
report. In the 2017 report, the injection attack is still
ranked in the first position [26], and the definition of
injection attack still contains NoSQL injection attack
[27]. NoSQL injection refers to an injection attack
through the embedding of malicious code (like other
web attack ways) in NoSQL queries through web page
input form and cookie files as shownin Fig. 1 [27, 28].
In Fig. 1, we are assuming that an attacker is trying
to access the NoSQL database as an authorized user.
The NoSQL database type that connected to the web
application is MongoDB. The web application checks
the username and password of each user throughthe
application’s home page. The attacker entering any
username and will enter “$ne” => 1 instead of enter-
ing the password. The web application generates the
following query to send it to the database:
$collection->find(array
(“username” => “ahmed”,"password" =>
array(“$ne” => 1)));
In MongoDB, “$ne” is an operator used for select-
ing the documents where the value of the document is
not equal or doesn’t include the specified value. This
means that there is a high probability of injecting mali-
cious code and an attacker can bypass firewalls and
endpoint defenses. So, the attacker can manipulate the
database as an authorized user.
It is important to stress that this example represents
an extremely simple kind of attack and we present it for
illustrative purposes only. In addition, there are now
over 225 NoSQL databases available for use with web
applications and each one offer different features and
limitations[29–31].Currently,almostall NoSQL
databases such as MongoDB, Hadoop/HBase, Cas-
sandra, CouchDB, and Riak are potentially vulnera-
ble to NoSQL injection attacks [17–20, 32, 33].
The RESTful service supports all basic operations
on data such as create, retrieve, update, delete [34].
These operations are achieved through some methods
like POST, PUT, PATCH, and DELETE.
Most of the RESTful services use HTTP as the
default protocol for exchanging data between web
applications. There is a part inside the RESTful web
service response message is called HTTP status code.
This part is used for clarifying the status of the required
service after implementation. There are many stan-
dard status codes that can be used for clarifying th
results status (e.g. 200 it means the request has suc-
ceeded). But for our purpose in this paper, we will use
only GET operation, which is used to retrieve the sta-
tus of an injection attack. Also, according to our
research needs, we will use only three status codes for
clarifying the status of the injection attack as shown in
Table 1.
4. THE CHALLENGE FOR DETECTING
NOSQL INJECTION ATTACKS
There are many NoSQL databases that are not sim-
ilar to each other in the way of manipulation. Con-
versely, relational databases (such as MS SQL Server,
MySQL) use SQL as a standard language for manipu-
lating databases. Also, with multiple languages in a
web application such as (ASP, PHP), the SQL state-
ments can easily be inserted within them in a unified
format. But on the other side, the NoSQL databases
are different in the way of manipulating the databases
as shown in the following section.
The big challenge here is that there are many pat-
ternsthat can be generatedfor NoSQL injection
attacks depending on the different way of manipulat-
ing each type of NoSQL databases. Therefore, we will
need to create a model that can handle all these forms
of patterns at the same time.
Fig. 1. NoSQL Injection Attack Example.
Internet
MongoDB
Unauthorized
access
NoSQL
Query
Web Application
Firewall
Table 1.NoSQL injection attack status
Status
Code Status Description
200 Ok – No any NoSQL Injection attack detected
400 Bad Request – NoSQL Injection attack has been
detected
404 Not Found п it maybe means the type of NoSQL
database not supported or invalid parameters

438
PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
EASSA et al.
5. MAIN VARIANTS OF NOSQL
INJECTION ATTACKS
As general, there are many types of attacks that
affectany network/internet-basedsystem[35–38].
These attacks are mainly depending on the environ-
ment characteristics for which the computer applica-
tion is designed, (e.g., web applications) [39].
There are manytechniquesof web application
attacks that can be used according to the type of each
NoSQL database. We will discuss in the following
some examples of the most common types of NoSQL
databases and the technique of injection attack for
each of them.
According to accepted database popularity ranking
[33], five of the most common NoSQL databases
(MongoDB, Cassandra, Amazon DynamoDB and
CouchDB) are ranked among the 10 most popular
NoSQL databases. These types will be used to confirm
that the probability of injection attack is different in
technique depending on the type of each database.
In the following four examples of web applications
are similar in function and programming language,
these examples execute after submitting the user login
button and the web application verifies that they are
already registered in the NoSQL database. The only
difference between them, each web application con-
nected to a different NoSQL database as follow:
Example 1: web application connected to Mon-
goDB
$cont=$collection->findOne(array
('email'=>$email,'password'=> $pass));
Example 2: web application connected to Cassan-
dra
$users = $database->query('SELECT * FROM
“reg_users” WHERE “username” = :usern'
AND “password” = :passw', ['usern' =>
$user, 'passw' => $pass]);
Example 3: web application connected to Amazon
DynamoDB
$response = $client->getItem(array
(“TableName” => "usr_reg","Key" =>
array(“useremail” => array( Type:: STRING
=> $usrId),"password" => array(
Type::STRING => $password))));
Example4: web application connectedto
CouchDB
sprintf('http://127.0.0.1:5984/test/?$re
g_users['username']=%s&$reg_users['pass-
word']=%s', $user, $pass));
In example 1, it is possible to inject a malicious
code into submitted data from the login webpage. This
could for example look like this:
http://127.0.0.1/phd/Mon-
goDB/after_log.php?user=ahmed&pass[$ne]=
1&sbumit1=Submit
Where “$ne” as discussed in section 3, it selects the
documents where the value of the field is not equal to
“1”. So, the attacker will have the authority of the
authorized user.
In example 2, the injection technique is very simi-
lar to what happens in the relational databases because
Cassandra query language CQL is very close to rela-
tional database query language SQL. So, the attacker
may enter any username and a password of:
ali’; DROP COLUMNFAMILY ’users
The attackercan completelydeletea tableor
COLUMNFAMILY including all data inside it and
the query will appear as follow:
('select * from reg_users where username
= ali and password = ali'; drop columnfa-
mily 'users', ['usern' =>, 'passw' =>
ali'; drop columnfamily 'users]).
In example 3, the attacker can inject a malicious
code into submitted data from the login webpage. This
could for example look like this:
http://127.0.0.1/phd/AmazonDyna-
moDB/after_log.php?user=ahmed&pass[$gt]=
1&sbumit1=Submit
In Amazon DynamoDB, “$gt” is an operator used
for selecting the values where the value of the docu-
ment or key is greater than the specified value. So the
attacker can access the database as an authorized user
Finally, the attacker in example 4 may enter any
username and a password of
''or 1=1
This results in URL query of:
http://127.0.0.1/phd/CouchDB/after_log.p
hp?user=test&pass=%27%27or+1%3D1&sbu-
mit1=Submit
So the attacker can access the database as an autho-
rized user because 1=1 is always true.
According to the previous examples, there is a pos-
sibility of attacking different types of Web applications
which are connected to NoSQL databases by injecting
a malicious code via different techniques.
6. THE PROPOSED DNIARS ARCHITECTURE
This DNIARS architecture consists of main four
components, as shown in Fig. 2, which are service inter-
face, service controller, service handler and detectio
function.
Service interface is an application program interface
(API) act as a medium of communication between the
client (web applications) and server (DNIARS) and it is
also responsible to handle all requests and respons
The service interface component allows web applica
tions to send HTTP requests which include S1 and S2.
Also, it can pass the results of injection status in differ-
ent formats like JSON or XML.

PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
NoSQL INJECTION ATTACK DETECTION 439
Service controller is responsible for processing web
application requests based on the logic in the control-
ler (e.g. NoSQL Database Type) and mapping it to
fetch data and output views.
Service handler is responsible for deciding which
kind of response format should be sent back. This is
decided based on the request header name and its type.
The types for the request header can be like “applica-
tion/json”, “application/xml” or “text/html”. Also,
the service handler is responsible for generating the
status code for each response according to the status of
results.
Detection function is used as the central point of
logic for DNIARS. This component responsible for
detecting NoSQL injection attacks in web application
according to received values from service controller
and service handler. The detection function has the
ability to check the intended structure of the NoSQL
query by comparing NoSQL statement structure in
code query statement (S1) and runtime query state-
ment (S2).
The table “nosqlengines”, it is a simple database
table used to hold all query string forms and its types
such as reserved keywords, logical operators and rela-
tional operators for each NoSQL database type. The
detection function transforms each code query state-
ment (S1) and runtime query statement (S2) into com-
parative patterns format depending on “nosqlengines”
table. Then, the detection function returns the compar-
ative results to service handler component. 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
an error page and stop running for the NoSQL query.
7. THE DNIARS
IMPLEMENTATION DETAILS
The DNIARS was implemented using PHP plain
code without dependency on any other framework and
MySQL as a databasetool for manipulating
“nosqlengines” table. The implemented DNIARS is
capableof respondingto the differentformatsof
requests (e.g. JSON, XML) including HTTP status
code based on detection results status. The process of
the implemented DNIARS can be divided into three
main steps as discussed in the following subsections.
7.1. Request Mapping
RESTful web services should have a uniform, neat
URIs [40]. In Apache web servers, the “.htaccess”
files are used to perform redirecting URLs. This type
of files is used in our implemented RESTful web ser-
vice to handle web application requests which are
routed to the service controller to determine where the
request intended to go and forward it on to the detec-
tion function.
The implemented DNIARS can be called via the
following HTTP request which is containing S1, S2
and NoSQL database type (e.g. MongoDB):
http://127.0.0.1/rest/request/inj/mon-
godb/s1/s2/
In the HTACCESS file, the request mapped to the
service controller as shown in the following:
# Turn rewrite engine on
Options +FollowSymlinks
RewriteEngine on
# map neat URL to internal URL
RewriteRule ^request/inj/([a-z,A-Z,0-
9]+)/([^?.]*)/([^?.]*)/?(.*)$ RestCon-
troller.php?type= $1&str1=$2&str2=$3
[nc,qsa].
7.2. Request Handling
The service controller and handler decide what
kind of response format should be sent back, and this
is decided based on the request header parameter
“Accept”. The accept request headers are required for
proper data formatting for requests that contain a
request body or response body. These request headers
supporting JSON, XML and HTML as shown in the
following PHP script:
Fig. 2. The proposed DNIARS architecture.
Response
Web form
Query
response
Invalid
query
request
HTTP request
S1
Service
Interface
HTML,
JSON, XML
S2
Request
response
Service
Controller
RESTful Service
DNIARS
Service
Handler
Detection
Function nosql-
engines
Valid
query
Web
Application
S1, S2
Calling
RESTful
Service
NoSQL
DB

440
PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
EASSA et al.
<?php
require_once(“detection_fun.php”);
class RestHandler extends SimpleRest {
public function check($type,$s1,$s2) {
$injstatus = detection_fun($type,$s1,$s2);
if(empty($injstatus)) {
$statusCode = 404;
$injstatus = array('error' => 'parameters not found!');
} else if(isset($injstatus[0])) {
$statusCode = 200;
}else if(isset($injstatus [1])) {
$statusCode = 400;}
$requestContentType= “";
if(isset($_SERVER['HTTP_ACCEPT'])) {
$requestContentType = $_SERVER['HTTP_ACCEPT'];}
$this->setHttpHeaders($_SERVER['HTTP_ACCEPT'], $statusCode);
if(strpos($requestContentType,'application/json') !== false){
$resp = $this->encodeJson($injstatus);
echo $resp;
} else if(strpos($requestContentType,'text/html') !== false){
$resp = $this->encodeHtml($injstatus);
echo $resp;
} else if(strpos($requestContentType,'application/xml') !== false){
$resp = $this->encodeXml($injstatus);
echo $resp;}}
public function encodeHtml($respData) {
$htmlResp = “<table border='1'>";
foreach($respData as $key=>$value) {
$htmlResp .= “<tr><td>". $key. "</td><td>". $value. "</td></tr>";}
$htmlResp .= “</table>";
return $htmlResp; }
public function encodeJson($respData) {
$jsonResp = json_encode($respData);
return $jsonResp; }
public function encodeXml($respData) {
$xml = new SimpleXMLElement('<?xml version="1.0"
encoding="UTF-8"?><result></result>');
foreach($respData as $key=>$value) {
$xml->addChild($key, $value);}
return $xml->asXML();}}?>
7.3. NoSQL Attack Detecting
Detection process totally depends on the detection
function. According to NoSQL database type (e.g.
MongoDB), the function selects all reserved keywords
and operators which may be used in injection attack.
Then, the detection function generates comparative
patterns for each code query statement (S1) and run-
time query statement (S2) based on returned result
from “nosqlengines” table. If no any NoSQL injectio
attacks detected, it will return to the request handler an
acceptancemessagefor the originalweb application
request; if it fails and one or more NoSQL injection attac
detected, it will return to the request handler a rejection
message as shown in the following PHP script:
<?php
function detection_fun($type,$querys,$queryd){
function pattern_generator($type,$string){
$conn = mysqli_connect(“localhost”, “root”, “","nosqldbs”);
if(! $conn ) {
die('Could not connect: ' . mysqli_error());}
$sql = “SELECT stringtype, syntax FROM nosqlengineswhere dbtype= '$type'";
$queryResult = mysqli_query($conn, $sql);

PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
NoSQL INJECTION ATTACK DETECTION 441
$data_array=array();
$data_result=array();
$string = strtolower($string);
while($row = mysqli_fetch_assoc($queryResult)) {
$word = strtolower($row['syntax']);
$word_escaped = preg_quote($word, '~');
$pattern = '~' . $word_escaped . '~';
$count = preg_match_all($pattern, $string, $matches);
if($count!=0)
array_push($data_array,array($row['stringtype'],$row['syntax'],$count));
}return $data_array;
mysqli_close($conn);}
$mv = 0;$erst="Accepted";
$pdarray=pattern_generator($type,$queryd);
$psarray=pattern_generator($type,$querys);
if ($pdarray != $psarray){
$mv = 1;
$erst="Not Acceptable-NoSQL Injection attack has been detected";}
$resarray=array($mv=>$erst);
return $resarray;}?>
8. EXPERIMENTAL RESULTS
To investigate the effectiveness of the DNIARS,
detection ability was examined through the most com-
mon testing tools for RESTful web services such as
Advanced REST client, Jmeter, WebInject, SoapUI,
HttpMaster and TestingWhiz. It was found from the
test result that DNIARS could already detect all types
of NoSQL injection attacks.
We will use an example for testing purpose; this
example is vulnerable to NoSQL injection attack. Sup-
posing 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. 1.
http://127.0.0.1/after_log.php?user=ahme
d&pass[$ne]=1&sbumit1=Submit
In this case, the resulting query in the dynamic
state will be as follows:
$collection->find(array(“username” =>
“ahmed”,“password” => array(“$ne” => 1)));
In MongoDB, “$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 intro-
duced their password correctly.
It is evident from this example that the previously
mentioned web application is vulnerable to NoSQL
injection attack because the attacker can access the
administration area without password checking.
Because of the increasing use of RESTful web ser-
vice, many testing tools have been developed to test th
performance of this technology; these testing tools
automate testing for a specific scenario such as loa
testing and response time. The previously mentioned
example is used as a testing example for DNIARS,
where (S1) in static code state is:
$collection->find-
One(array(“email"=>$email,"pass-
word"=>$pass))
, and (S2) in dynamic state is:
$collection->find(array( “username” =>
“ahmed”, “password” => array(“$ne” =>
1)))
Thus, the DNIARS will be called by the following
HTTP request:
http://127.0.0.1/rest/request/inj/mon-
godb/$collection->find-
One(array(“email"=>$email,"pass-
word"=>$pass))/$collection-
>find(array("username” => “ahmed”,
“password” => array(“$ne” => 1)))/
The experimentwas conductedtwice but with
some changes in the testing environment as shown in
the following Table 2.
The main difference between testing cases A and B
is in the initial number of virtual users which are
loaded as shown in Fig. 3(a).
Test A uses a type of test called a steady load test
which means a fixed number of virtual users are loaded
during the test run. Test B uses a type of test called a
ramp-upuser load or stepwiseload which means
increasing the number of virtual users throughout the
test run. After the test, the following results were
shown in Table 3.

442
PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
EASSA et al.
During the testing phase, some results were figured
out as shown in Fig. 3. Figure 3b shows the number of
successfullypassedrequestsduring test execution
time. We can see in Fig. 3b that there is a part repeated
every two minutes for both typesof testing A and B.
This explains that the load of requests takes about a min-
ute with an average of 250 requests per second, and then
a full minute does not show any loading of new requests
until the completion of previous requests.
The total number of generated requests during test
execution time was 168415 requests in test case A and
162282 requests in test case B and all of them loaded
successfully except 350 requests not completed in both
tests A and B as shown in Fig. 3c.
We can see in Fig. 3c that there is a part repeated
every minute for both types of testing A and B. This
shows that there are several requests that have not been
completed successfully because of the weakness of the
servercapabilities,whereit cannotcompletethe
request on time because the maximum time for send-
ing request is 60 seconds.
Figure 3d represents the average load time of all
requests was successfully loaded. The load time aver-
age for DNIARS is 94 milliseconds in test case A and
it is 93 milliseconds in test case B. The maximum
loading time during the test period was 1.41 second in
test case A and it was 21.23 second in test case
In contrast, the lowest loading time was 3 milliseconds
in both tests A and B. As we see in Fig. 3d, it is clearly
shown in the 12th and 14th minutes there is a signifi-
cant difference in the average of loading time between
test case A and B.
The real reason behind it is the difference in maxi-
mum load time because test case B uses a ramp-u
user load, in which there is a bottleneck due to th
gradual increase in the number of virtual users. How-
ever, in general there is a similarity in the average time
required to load requests between test case A and B.
Figure 3e shows the request transfer speed graph.
This graph represents the average request transfer spee
at any moment of the test run. In contrast, Fig. 3f shows
the response transfer speed. As shown in Figs. 3e and f,
is clear that the response speed is very close to th
request transfer speed and therefore there is no signif-
icant delay in the speed of response during the testing
process. So practically the DNIARS can work in real
NoSQL environments.
According to testing results, the DNIARS was able
to detect the NoSQL Injection attack. Also, it is com-
patiblewith real workingenvironmentswherethe
error rate does not exceed 1%. In addition to, it can
respond to requests in a different format like XML and
JSON.
9. CONCLUSION
This paper presents a RESTful web service which is
called DNIARS, the DNIARS architecture consists of
main four components which are service interface,
service controller, service handler and detection func-
tion. The DNIARS can be used as a filtering web ser-
vice to detect NoSQL injection attacks in web applica-
tions. The DNIARS can be called remotely over the
internetby any other web applicationvia HTTP
request. If no any NoSQL injection attacks detected,
it will return a status code 200, which means that the
request has been performed successfully and no an
NoSQL injection attacks detected; if it fails or one or
more NoSQL injection attacks detected, it will return
a status code 400 or 404. The DNIARS totally sepa-
rates the web application from the detection process.
This has some advantages. For example, it improves
the portability of the interface to other types of plat-
forms; it increases the scalability of both the DNIARS
and the web application and allows the different com-
ponentsof the developmentsto be evolvedinde-
pendently. The DNIARS implemented using PHP
programming language and MySQL without depen-
dency on any other framework and it was tested using
the most common testing tools for RESTful web ser-
vice. Also, it has the ability for responding to different
requests formats like JSON, XML. In future work, we
will propose a novel comprehensive tool by generaliz-
Table 2.The DNIARS testing environment
Testing environment variablesTest A Test B
Server HW capabilities Processor = i7, 2 GHz
RAM = 8 GB
System type = 64 bit
Initial number of virtual users50 user 1 user
Maximum number of users 50 users 50 users
Step time duration 1 second 1 second
The number of users per step0 user 1 user
Test time duration 15 minutes15 minutes
Server connect timeout 60 seconds60 seconds
Send request timeout 60 seconds60 seconds
Receive response timeout300 seconds300 seconds
Request correlation timeout300 seconds300 seconds
Table 3.The DNIARS testing results
Testing result criteria Test A Test B
Generated requests 168415 request162282 request
Total errors 350 error 350 error
Errors percentage 0.21% 0.22%
Load time average 94 millisecond93 millisecond
Maximum load time 1.41 second 21.23 second
Minimum load time 3 millisecond 3 millisecond
Completion time average101 millisecond 100 millisecond

PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
NoSQL INJECTION ATTACK DETECTION 443
ing the proposed DNIARS over all other types of data-
bases which are SQL and NewSQL.
REFERENCES
1. Arcuri, A., RESTful API automated test case genera-
tion, Proc. 2017 IEEE Int. Conf. on Software Quality,
Reliability and Security (QRS), Prague, 2017, pp. 9–20.
2. Pautasso, C., RESTful API Design: Best Practices in API
Design with RESTs, API-Univ., 2016.
3. Zafar, R., Yafi, E., Zuhairi, M.F., and Dao, H., Big
data: the NoSQL and RDBMS review, Proc. 2016 Int.
Conf. on Information and Communication Technology
(ICICTM), Kuala Lumpur, 2016, pp. 120–126.
4. Eassa, A.M., Al-Tarawneh, O.H., El-Bakry, H.M.,
and Salama, A.S., NoSQL racket: a testing tool for
detecting NoSQL injection attacks in web applica-
tionss, Int. J. Adv. Comput. Sci. Appl., 2017, vol. 8,
no. 11, pp. 614–622.
5. Okman, L., Gal-Oz, N., Gonen, Y., Gudes, E., and
Abramov, J., Security issues in NoSQL databasess,
Proc. 10th IEEE Int. Conf. on Trust, Security Privacy
Comput.Commun.(TrustCom),Hogn Kong, 2011,
pp. 541–547.
6. Cory, N., Travis, L., Reenu, I., and Gary, H., NoSQL
vs RDBMS – why there is room for boths, Proc. SAIS
2013, Savannah, March 8–9, 2013.
7. Schram, A. and Anderson, K.M., MySQL to NoSQL:
data modelling challenges in supporting scalabilitys,
Proc. 3rd Annu. Conf. on Systems, Programming, and
Applications: Software for Humanity SPLASH’12, Tuc-
son, 2012, pp. 191–202.
8. Kaur, D. and Kaur, P., Empirical analysis of web
attackss, Proc. Comput. Sci., 2016, vol. 78, pp. 298–306.
9. Prokhorenko, V., Kim-Kwang Raymond Choo, and
Ashman, H., Web application protection techniques: a
taxonomy, J. Network Comput. Appl., 2016, vol. 60,
pp. 95–112.
10. Rababah, O.M., Al Hwaitat, A.K., Al Manaseer, S.,
Fakhouri, H.N., and Halaseh, R., Web threats detec-
tion and prevention frameworks, Commun. Network,
2016, vol. 8, no. 3, pp. 170–178.
11. Tajpour, A., Ibrahim, S., and Sharifi, M., Web applica-
tion security by SQL injection DetectionTools, Int. J.
Comput. Sci., 2012, vol. 9, issue 2, no 3, pp. 332–339.
12. Bherde, G.P. and Pund, M.A., Recent attack preven-
tion techniques in web service applications, Proc. 2016
Int. Conf. on Automatic Control and Dynamic Optimiza-
tion Techniques (ICACDOT), Pune, 2016, pp. 1174–
1180.
13. Shanmughaneethi,S.V. Emilin Shyni, S.C., and
Swamynathan, S., SBSQLID: securing web applica-
tions with service based SQL injection detections, Proc.
Int. Conf. on Advances in Computing, Control, and Tele-
communicationTechnologies,Trivandrum, Kerala,
2009, pp. 702–704.
14. Jan, S., Panichella, A., Arcuri, A., and Briand, L.,
Automatic generation of tests to exploit XML injection
vulnerabilities in web applications, IEEE Trans. Soft-
ware Eng., 2017, no. 99.
15. Shrivastava, R., Bhattacharyji, J., and Soni, R., SQL
injection attacks in database using web service: detec-
tion and prevention – reviews, Asian J. Comput. Sci. Inf.
Technol., 2012, vol. 2, no. 6, pp. 162–165.
Fig. 3. The DNIARS testing results: (a) concurrent users loading; (b) passed requests; (c) errors; (d) load time; (e) reques
speed; (f) response transfer speed.
30
10
20
40
50
60
0
2m12s
3m12s
4m20s
4m40s
5m
5m20s
6m26s
6m46s
7m6s
7m26s
8m30s
8m50s
9m10s
9m30s
10m32s
10m52s
11m12s
11m32s
12m32s
12m52s
13m12s
13m32s
14m28s
14m48s
2m32s
2m52s
0
20s
40s
1m
(a)
Users loading, A Users loading, B
200
50
100
150
250
300
350
400
0
2m12s
3m12s
4m20s
4m40s
5m
5m20s
6m26s
6m46s
7m6s
7m26s
8m30s
8m50s
9m10s
9m30s
10m32s
10m52s
11m12s
11m32s
12m32s
12m52s
13m12s
13m32s
14m28s
14m48s
2m32s
2m52s
0
20s
40s
1m
(b)
Passed Requests, A Passed Requests, B
20
5
10
15
25
30
0
2m12s
3m12s
4m20s
4m40s
5m
5m20s
6m26s
6m46s
7m6s
7m26s
8m30s
8m50s
9m10s
9m30s
10m32s
10m52s
11m12s
11m32s
12m32s
12m52s
13m12s
13m32s
14m28s
14m48s
2m32s
2m52s
0
20s
40s
1m
(c)
Errors, A Errors, B
300
100
200
400
500
600
700
800
900
1000
0
2m12s
3m12s
4m20s
4m40s
5m
5m20s
6m26s
6m46s
7m6s
7m26s
8m30s
8m50s
9m10s
9m30s
10m32s
10m52s
11m12s
11m32s
12m32s
12m52s
13m12s
13m32s
14m28s
14m48s
2m32s
2m52s
0
20s
40s
1m
(d)
Load Time, A in ms Load Time, B in ms
80
20
40
60
100
120
140
80
20
40
60
100
120
160
180
0
2m12s
3m12s
4m20s
4m40s
5m
5m20s
6m26s
6m46s
7m6s
7m26s
8m30s
8m50s
9m10s
9m30s
10m32s
10m52s
11m12s
11m32s
12m32s
12m52s
13m12s
13m32s
14m28s
14m48s
2m32s
2m52s
0
20s
40s
1m
(e)
Request Transfer Speed, A – kB/s
Request Transfer Speed, B – kB/s
Request Transfer Speed, A – kB/s
Request Transfer Speed, B – kB/s
140
0
2m12s
3m12s
4m20s
4m40s
5m
5m20s
6m26s
6m46s
7m6s
7m26s
8m30s
8m50s
9m10s
9m30s
10m32s
10m52s
11m12s
11m32s
12m32s
12m52s
13m12s
13m32s
14m28s
14m48s
2m32s
2m52s
0
20s
40s
1m
(f)

444
PROGRAMMING AND COMPUTER SOFTWARE Vol. 44 No. 6 2018
EASSA et al.
16. Mouli, V.R. and Jevitha, K.P., Web services attacks and
security – a systematic literature reviews, Proc. Comput.
Sci., 2016, vol. 93, pp. 870–877.
17. NoSQL does not have to mean no security: data secu-
rity and compliance best practices for NoSQL data sys-
tems, IBM Corporation,2016.http://whitepapers.
theregister.co.uk/paper/view/4306/nosql-does-not-
have-to-mean-no-security.pdf.AccessedMarch, 1
2018.
18. Lane, A., Securing big data: security recommendations for
hadoopand NoSQL environments,SecurosisL.L.C.,
2012, pp. 4–6.
19. Amreen and Dadapeer, A survey on robust security
mechanism for NoSQL databases, Int. J. Innov. Res.
Comput. Commun. Eng., 2016, vol. 4, no. 4, pp. 7662–
7666.
20. Ron, A., Shulman-Peleg, A., and Bronshtein, E., No
SQL, no injection? Examining NoSQL securitys, Proc.
36th IEEE Symp. on Security and Privacy, San Jose,
2015, vol. 1.
21. Gupta, N. and Agrawal,R., NoSQL security,in
Advances in Computers, Elsevier, 2018.
22. Hou, B., Qian, K., Li, L., Shi, Y., Tao, L., and Liu, J.,
MongoDB NoSQL injection analysis and detection,
Proc. 3rd IEEE Int. Conf. on Cyber Security and Cloud
Computing (CSCloud), Beijing, 2016, pp. 75–78.
23. Priyadharshini,S. and Rajmohan,R., Analysison
database security model against NOSQL injection, Int.
J. Sci. Res. Comput. Sci., Eng. Inf. Technol., 2017, vol. 2,
no. 2, pp. 168–171.
24. Sahafizadeh, E. and Nematbakhsh, M.A., A survey on
security issues in big data and NoSQLs, ACSIJ J., 2015,
vol. 4, issue 4, no.16, pp. 68–72.
25. Son, S. and McKinley, K.S., Diglossia: detecting code
injection attacks with precision and efficiencys, Proc.
20th ACM Conf. on Computer and Communications Secu-
rity (CCS), Berlin, 2013, pp. 1181–1192.
26. Eassa, F.E., Zaki, M., Eassa, A.M., and Aljehani, T.,
IMATT: an integrated multi-agent testing tool for the
security of agent-based web applicationss, World J.
Comput. Appl. Technol., 2012, vol. 1, no. 2, pp. 19–28.
27. OWASP Top 10, web application security risks report.
http://www.owasp.org. Accessed March 1, 2018.
28. CWE/SANS Top 25 Most Dangerous Software Errors.
http://cwe.mitre.org/top25/. Accessed March 1, 2018.
29. Kabakus, A.T. and Kara, R., A performance evaluation
of in-memory databasess, J. King Saud Univ. – Comput.
Inf. Sci., 2017, vol. 29, no. 4, pp. 520–525.
30. Shahriar, H. and Haddad, H.M., Security vulnerabili-
ties of NoSQL and SQL databases for MOOC applica-
tionss, Int. J. Digital Society, 2017, vol. 8, no. 1.
31. Elhoseny,M., Abdelaziz,A., Salama,A.S., Riad,
A.M., Muhammad, K., and Sangaiah, A.K., A hybrid
model of Internet of Things and cloud computing to
manage big data in health services applicationss, Future
Generat. Comput. Syst., 2018, vol. 86, pp. 1383–1394.
32. Abdelaziz, A., Elhoseny, M., Salama, A.S., and Riad,
A.M., A machine learning model for improving health-
care services on cloud computing environments, Mea-
surement, 2018, vol. 119, pp. 117–128.
33. The DB-Engines Ranking. https://db-engines.com/en
/ranking_trend. Accessed March 1, 2018.
34. Wilde, E. and Pautasso, C., REST: from Research to
Practicec, New York: Springer-Verlag, 2017, pp. 35–55.
35. Elhoseny, M., Yuan, X., ElMinir, H.K., and Riad, A.M.,
An energyefficientencryptionmethodfor secure
dynamic WSNs, Security Commun. Networks, Wiley,
2016, vol. 9, no. 13, pp. 2024–2031.
36. Elhoseny, M., Elminir, H., Riad, A., and Yuan, X.,
A secure data routing schema for WSN using elliptic
curve cryptography and homomorphic encryptions, J.
King Saud Univ. – Comput. Inf. Sci., Elsevier, 2016,
vol. 28, no. 3, pp. 262–275.
37. Riad, A.M., El-Minir, H.K., and Elhoseny, M., Secure
routing in wireless sensor networks: a state of the arts,
Int. J. Comput. Appl., 2013, vol. 67, no. 7.
38. Elhoseny, M., Hosny, A., Hassanien, A.E., Muham-
mad, K., and Kumar Sangaiah, A., Secure automated
forensic investigation for sustainable critical infrastruc-
tures compliant with green computing requirements,
IEEE Trans. Sust. Comput., 2017, no. 99.
39. Khari, M., Vaishali. S., and Kumar, M., Comprehen-
sive study of web application attacks and classification,
Proc. 3rd Int. Conf. on Computing for Sustainable Glob
Development (INDIACom), New Delhi, 2016, pp. 2159–
2164.
40. Selvakumar, G. and Kaviya, B. J., A survey on RESTful
web services composition, Proc. Int. Conf. on Computer
Communication and Informatics (ICCCI), Coimbatore,
2016, pp. 1–4.
View publication statsView publication stats