Paper Title (use style: paper title)

4 downloads 355 Views 520KB Size Report
Abstract—NoSQL data storage systems have become very ... enterprise database grants an attacker a great control over the ... developer might present a vulnerability into the application ... would be encoded by PHP to the following json:.
Analysis and Mitigation of NoSQL Injections Aviv Ron Cyber security Center of Excellence IBM Beer Sheba, Israel [email protected]

Alexandra Shulman-Peleg Cyber security Center of Excellence IBM, Beer Sheba, Israel [email protected]

Abstract—NoSQL data storage systems have become very popular due to their scalability and ease of use. Unfortunately, they lack the security measures and awareness which are required for data protection. Although the new data models and query formats of NoSQL data stores make old attacks, like SQL injections irrelevant, they give attackers new opportunities for injecting their malicious code into the statements passed to the database. Here, we analyze the techniques for injecting malicious code into NoSQL data stores, providing examples of new NoSQL injections as well as CSRF attacks allowing an attacker to bypass perimeter defenses, such as firewalls. We analyze the source of these vulnerabilities and present methodologies to mitigate the attacks. Since code analysis alone is insufficient to prevent the attacks in today’s typical large scale deployment, we describe the mitigations that should be done through the entire software lifecycle.

Anton Puzanov Cyber security Center of Excellence IBM, Beer Sheba, Israel [email protected]

As a result, there is a growing popularity of distributed, NoSQL key-value stores that satisfy the scalability requirements of modern large scale applications. These data stores include NoSQL databases like MongoDB and Cassandra as well as in-memory stores and caches like Redis and Memcached. Indeed, the popularity of NoSQL databases is constantly growing over the last years and, for example, MongoDB, is ranked 4th among the 10 most popular databases as seen in Figure 1.

Keywords—H.2.8 Database Applications; K.4.4.f Security

I.

INTRODUCTION

Database security has been and will continue to be one of the more critical aspects of information security. Access to enterprise database grants an attacker a great control over the most critical data. For example, SQL injection attacks insert malicious code into the statements passed by the application to the database layer. This enables the attacker to do almost anything with the data including accessing unauthorized data as well as altering, deleting and inserting new data. Although the exploitation of SQL injection has been declining steadily over the years due to secure frameworks and improved awareness it has remained a high impact means to exploit system vulnerabilities. For example, it was shown that web applications receive 4 or more web attack campaigns per month and SQL injections are the most popular attacks on Retailers ‎[1]. Furthermore, it was reported that SQL injection vulnerabilities affects 32% of all web applications ‎[15]. NoSQL (Not Only SQL) is a trending term in modern data stores. These are non-relational databases that rely on different storage mechanisms such as document store, keyvalue store, graph and more. The wide adoption of these databases is facilitated by the new requirements of modern large scale applications (e.g. Facebook, Amazon, Twitter) which need to distribute the data across a huge number of servers. These scalability requirements cannot be met by traditional relational databases which require that all operations of the same transaction are executed by a single database node Error! Reference source not found..

Figure 1: Top 10 most popular databases for August 2015 according to db-engines.com popularity ranking. According to this ranking there are 3 NoSQL databases among the top 10 – MongoDB, Cassandra and Redis. Additionally it can be seen from the 3rd column that all of the NoSQL databases in the top 10 are in a growing popularity trend compared to their popularity a year ago. Like almost every new technology, NoSQL databases were lacking security when they first emerged‎[2]‎[3]‎[4]. They suffered from lack of encryption, proper authentication and role management as well as fine grained authorization ‎[5], Furthermore, they allowed dangerous network exposure and denial of service attacks ‎[2]. Today the situation is better and popular databases introduced built-in protection mechanisms (e.g.,‎[9]). All of these databases use different query languages which make the traditional SQL injection techniques irrelevant. But does this mean that NoSQL systems are immune to injections? Our study shows that while the security of the query language itself and the drivers has largely improved, there are still techniques for injecting malicious queries. Some works already provide reports of NoSQL injection techniques (‎[3]‎[2]Error! Reference

source not found.). Some initial application scanning projects emerged (e.g. nosqlproject.com) and the OWASP published some recommendation for testing code for NoSQL injections. However, these are only initial results and the problem‎ was‎ not‎ sufficiently‎ studied‎ and‎ didn’t‎ receive‎ the‎ required attention. Here, we aim to raise this awareness providing the analysis of NoSQL threats and techniques as well as their mitigation mechanism. Specifically, the contributions of this paper include: (1) Analysis of the injection techniques that are relevant to NoSQL data stores and caches; (2) Providing examples of new NoSQL injections to data stores and caches as well as CSRF attacks allowing an attacker to bypass perimeter defenses, such as firewalls; (3) Presenting mitigation and protection mechanisms, allowing to detect injections at their different stages of propagation. II.

NOSQL ATTACK VECTORS

NoSQL data stores are commonly used by web applications and services to store the data of their customers. Figure 2 illustrates a typical architecture in which a NoSQL data store is used to store the data accessed via a web application. The access to the data base is performed via a driver - an access protocol wrapper, providing libraries for database clients in multiple programming languages. While these drivers themselves may not be vulnerable, sometimes they present non‎safe‎API’s‎that‎when‎used‎incorrectly by the application developer might present a vulnerability into the application that will allow arbitrary operations on the database. As illustrated in Figure 2, attackers may craft a web access request with an injection which when processed by the database client/protocol wrapper will allow the desired illegal database operation.

Figure 2: Typical web application architecture The main mechanisms of SQL attacks that are relevant in NoSQL context can be divided to the following classes: A. Tautologies These attacks allow bypassing authentication or access mechanisms by injecting code in conditional statements and generate expressions that are always true (tautologies). For example, in this article we show how one can exploit the syntax‎of‎“$ne”‎(not‎equal) operator, which allows an attacker to illegally log in to the system without having an appropriate username and password.

B. Union Queries This is one of the most well known SQL injection techniques, in which an attacker exploits a vulnerable parameter to change the data set returned for a given query The most common usages are to bypass authentication pages and extract data. Here we show an example of an attack exploiting‎the‎Boolean‎“OR”‎operators‎by‎adding‎ expressions that are always true (e.g. an empty query {}) which lead to the incorrect evaluation of the entire statement allowing to illegally extract data. C. Javascript injections This is a new class of vulnerabilities introduced by NoSQL databases which allow execution of Javascript in the database context. Javascript allows running complicated transactions and queries on the database engine. Passing unsanitized user input to these queries may allow injecting arbitrary javascript code by an attacker that may result in illegal data extraction or data alteration. D. Piggy-backed Queries Here an attacker exploits some assumptions in the interpretation of escape sequences special characters (e.g. termination characters like CRLF) to insert additional queries to be executed by the database. E. Origin violation HTTP‎ REST‎ API’s‎ are‎ a‎ popular‎ module‎ in‎ NoSQL‎ databases. This introduces a new class of vulnerabilities that allow the attacker to attack the database even from another domain. In cross origin attacks a legitimate user and its web browser are exploited to perform some unwanted action on behalf of the attacker. Here, we show such violations in the form of a Cross-Site Request Forgery (CSRF) attack in which the trust that a site has in a user's browser is exploited to perform an illegal operation on a NoSQL database. By injecting an HTML form into a vulnerable website or tricking a user into a website of his own, an attacker may perform a POST action on the target database, compromising the database. III.

JSON QUERIES AND DATA FORMATS

In the following sections we demonstrate how the popular JSON representation format, while relatively safe, still allows new types of injection attacks. We illustrate this on the example of MongoDB, which is one of the most popular NoSQL databases (see Figure 1). MongoDB is a documentoriented database, which has been adopted for usage by multiple large vendors such as EBay, Foursquare, LinkedIn and others. In MongoDB Queries and Data are represented in JSON format, which is better than SQL in terms of security because it is more‎ “well‎ defined”,‎ very‎ simple‎ to‎ encode/decode and also has good native implementations in every programming language. Breaking the query structure as has been done in SQL injection is harder to do with a JSON structured query. A typical insert statement in MongoDB looks like:

db.books.insert({ title: ‘The Hobbit’, author: ‘J.R.R. Tolkien’ })

This inserts a new document into the books collection with a title and author field. A typical query looks like: db.books.find({ title: ‘The Hobbit’ })

Queries can also include regular expressions, conditions, limit which fields get queried and more. IV.

PHP TAUTOLOGY INJECTIONS

Let us examine an architecture depicted in Figure 3, where a web application is implemented with a PHP backend, which encodes the requests to the JSON format used to query the data‎ store.‎ Let’s‎ use‎ an‎ example‎ of‎ MongoDB‎ to‎ show‎ an‎ array injection vulnerability – an attack similar to SQL injection in its technique and results.

Figure 3: PHP application with MongoDB PHP encodes arrays to JSON natively. So for example the following array: array(‘title’ => ‘The hobbit’, ‘author’ => ‘J.R.R. Tolkien’);

would be encoded by PHP to the following json: {“title”: ”The hobbit”, “author”: “J.R.R. Tolkien” }

Let’s consider the following situation: A PHP application has a login mechanism where username and password are sent from the users browser via HTTP POST (the vulnerability is applicable also to HTTP GET as well). A typical POST URL encoded payload would look like: username=tolkien&password=hobbit

And the backend PHP code to process it and query MongoDB for the user would look like: db->logins->find(array(“username”=>$_POST[“username”], “password”=>$_POST[“password”]));

This makes perfect sense and is intuitively what the developer is likely to do, intending a query of: db.logins.find({ username: ‘tolkien’, password: ‘hobbit’ })

But PHP has a built in mechanism for associative arrays which allows an attacker to send the following malicious payload: username[$ne]=1&password[$ne]=1

PHP translates this input into: array(“username” => array(“$ne” => 1), “password” => array(“$ne” => 1));

Which is encoded into the MongoDB query: db.logins.find({ username: { $ne: 1 }, password: { $ne: 1 } })

Since $ne is the not equals condition in MongoDB, this is querying all the entries in the logins collection where the username is not equal to 1 and the password is not equal to 1 which means this query will return all the users in the logins collection, in SQL terminology this is equivalent to: SELECT * FROM logins WHERE username 1 AND password 1

In this scenario the vulnerability will lead to the attacker being able to log in to the application without a username and password. In other variants the vulnerability might lead to illegal data access or privileged actions performed by an unprivileged user. To mitigate this issue it is needed to cast the parameters received from the request to the proper type, in this case string: db->logins->find( array(“username”=>(string)$_POST[“username”], “password”=>(string)$_POST[“password”]));

V.

NOSQL UNION QUERY INJECTION

One of the common reasons for a SQL injection vulnerability is building the query from string literals which include user input without using proper encoding. The JSON query structure makes it harder to achieve in modern data stores like MongoDB. Nevertheless it is still possible. Let us examine a login form which sends its username and password parameters via an HTTP POST to the backend which constructs the query by concatenating strings. For example the developer would do something like: string query = “{ username: ‘“ + post_username + “’, password: ‘” + post_password + “’ }”

With valid input (tolkien + hobbit) this would build the query: { username: ‘tolkien’, password: ‘hobbit’ }

But with malicious input this query can be turned to ignore the password and login into a user account without the password, here is an example for malicious input: username=tolkien’, $or: [ {}, { ‘a’:’a&password=’ } ], $comment:’successful MongoDB injection’

This input will be constructed into the following query: { username: ‘tolkien’, $or: [ {}, { ‘a’: ‘a’, password: ‘’ } ], $comment: ‘successful MongoDB injection’ }

This query will succeed as long as the username is correct. In SQL terminology this query is similar to: SELECT * FROM logins WHERE username = ‘tolkien’ AND (TRUE OR (‘a’=’a’ AND password = ‘’)) #successful MongoDB injection

That is, the password becomes a redundant part of the query since an empty query {} is always true and the comment in the end does not affect the query. How did this happen? Let’s‎ examine‎ the‎ constructed‎ query‎ again‎ and‎ color‎ the‎ user input in bold and the rest in plain text: { username: ‘tolkien’, $or: [ {}, { ‘a’: ‘a’, password: ‘’ } ], $comment: ‘successful MongoDB injection’ }

This attack will succeed in any case the username is correct, an assumption which is valid since harvesting user names isn’t hard to achieve.

VI.

NOSQL JAVASCRIPT INJECTION

A common feature of NoSQL databases is the ability to run javascript in the database engine in order to perform complicated queries or transactions such as map reduce. For example popular databases which allow this are MongoDB, CouchDB and its based descendants Cloudant and BigCouch. Javascript execution exposes a dangerous attack surface if un-sanitized user input finds its way to the query. For example consider a complicated transaction which demanded Javascript code and which includes un-sanitized user‎ input‎ as‎ a‎ parameter‎ in‎ the‎ query.‎ As‎ a‎ use‎ case‎ let’s‎ take a model of a store which has a collection of items and each item has a price and an amount. The developer wanted to get the sum or average of these fields, so he writes a map reduce function that takes the field name that it should act upon (amount or price) as a parameter from the user. In PHP such code can look like this (where $param is user input): $map = "function() { for (var i = 0; i < this.items.length; i++) { emit(this.name, this.items[i].$param); } }"; $reduce = "function(name, sum) { return Array.sum(sum); }"; $opt = "{ out: 'totals' }"; $db->execute("db.stores.mapReduce($map, $reduce, $opt);");

This code sums the field given by $param for each item by name.‎ $param‎ is‎ expected‎ to‎ receive‎ either‎ “amount”‎ or‎ “price”‎‎for‎this‎code‎to‎behave‎as‎expected,‎but‎since‎user‎ input is not being escaped here, a malicious input might include arbitrary javascript that will get executed. For Example, consider the following input: a);}},function(kv) { return 1; }, { out: 'x' });db.injection.insert({success:1});return 1;db.stores.mapReduce(function() { { emit(1,1

In its first part (dark grey) this payload closes the original map reduce function, then the attacker can execute any javascript he wishes on the database (bold) and eventually the last part (plain black) calls a new map reduce in order to balance the injected code into the original statement. After combining this user input into the string that gets executed we get (injected user input is bold): db.stores.mapReduce(function() { for (var i = 0; i < this.items.length; i++) { emit(this.name, this.items[i].a); } },function(kv) { return 1; }, { out: 'x' }); db.injection.insert({success:1}); return 1;db.stores.mapReduce(function() { { emit(1,1); } }, function(name, sum) { return Array.sum(sum); }, { out: 'totals' });"

This‎ injection‎ looks‎ very‎ similar‎ to‎ “classical”‎ SQL‎ injection. The defense against such an attack is disabling usage of Javascript execution in the database configuration. If still required, it is a best practice not to use any user input in the formation of the javascript code. VII.

KEY VALUE DATA STORES

Key Value Data Stores like Memcached, Redis and Tachyon are in memory data stores which are designed to speed up the performance of applications, Cloud infrastructure and

platforms as well as Big Data frameworks. These platforms allow storing and retrieving data which is accessed repeatedly and frequently, for example one popular usage is a cache. Those platforms are commonly located in front of the data storage as depicted in Figure 4. A common usage of a cache platform is to store authentication tokens and container ACLs which need to be re validated on each subsequent request of the user. Although‎ usually‎ cache‎ API’s‎ are‎ very‎ simple‎ due‎ to‎ the‎ nature of key value queries being simple, we still find a possible injection attack on Memcached, the second most popular key value store, due to a vulnerability in the Memcached driver on certain PHP versions. The conditions which must be true in order to conduct the attack are: (1) Information from the user request (e.g. HTTP header) should be used as an attribute (e.g. value) passed to a cache set/get‎request;‎(2)‎The‎received‎string‎is‎passed‎“as‎is”‎and‎ is not sanitized; (3) Cached attributes include sensitive information which will cause the query execution to behave differently than intended.

Figure 4: Distributed in-memory data store architecture VIII.

PIGGY-BACKED QUERIES

Let‎ us‎first‎inspect‎the‎ structure‎of‎a‎“set”‎operation‎ which‎ adds a key and its corresponding value to the database using Memcached, when called from the command line interface, the‎“set”‎function‎uses‎two‎lines of input, the first is: set

and the second line consists of the data that should be stored.‎ When‎ calling‎ the‎ “set”‎ function‎ of the PHP driver the‎“set”‎function‎will‎receive‎two‎parameters‎and‎will‎look‎ as follows: $memcached->set('key', 'value');

Researchers showed ‎[10] that the driver fails to sanitize the ASCII characters Carriage return \r(0x0D) and Line feed \n(0x0A) resulting in a capability of the attacker to inject a new line in the key parameter and append another unintended command to the cache. Let’s‎ consider‎ the‎ following‎ code‎ where‎ $PARAM‎ is‎ user‎ input which is used as the key: $memcached=new Memcached(); $memcached->addServer('localhost',11211); $memcached->set($PARAM, “some value”);

An attacker can supply the following input that will result in an injection: "key1 0 3600 4\r\nabcd\r\nset key2 0 3600 4\r\ninject\r\n"

In the example above we can see that the first key that is added to the database is key1 with value “some‎value”, but on the same time, the attacker adds another unintended key to the database key2 with value “inject”. This‎injection‎can‎take‎place‎from‎the‎“get”‎command‎also. Let’s examine the example shown on the Memcached home page, which starts with these three lines: Function get_foo(foo_id) foo = memcached_get(“foo:” . foo_id) return foo if defined foo

This example shows a typical use of Memcached. It first checks if the input exists in the database before processing it. Let’s assume similar code is used to check an authentication token received from a user in order to validate if he is logged in or not. This can be exploited by passing the following string as the token (the injection is highlighted in bold): “random_token\r\nset my_crafted_token 0 3600 4\r\nroot\r\n”

When this String will be passed as a token, the database will be checked for the existence of random_token but at the same time, it will add my_crafted_token with the value root, later the attacker can send my_crafted_token and will be recognized as root. Several other instructions might be injected using this technique: incr decr delete

Their use is quite self-explained, incr is used to increment a key, decr is used to decrement a key, delete is used to delete a key. The injection can occur also using those three functions using‎ their‎ “key”‎ parameter‎ on‎ the‎ same‎ manner‎ as‎with‎the‎“set”‎and‎“get” functions. The same injections can be performed using the multiple items‎ functions:‎ “deleteMulti”,‎ “getMulti”‎ and‎ “setMulti”,‎ where the injection should‎occur‎in‎one‎of‎the‎“key” fields. The CRLF injection can be used in order to concatenate several get requests. In a test we conducted the maximum value of such concatenation is 17 including the original get key, the result which will return from such injection is the first key which has an associated value. This driver vulnerability was fixed in PHP 5.5 but unfortunately it exists in all PHP versions prior. According to w3techs.com statistics on PHP versions of websites in production more than 86% of all PHP websites use a version older than 5.5, which means they are vulnerable to this injection if they use Memcached. IX.

CROSS ORIGIN VIOLATIONS

Another common feature of NoSQL databases is exposing an HTTP REST API that enables querying the database from client applications. For example, databases that expose a REST API include MongoDB, CouchDB and HBase. The exposure of a REST API enables simple exposure of the database to applications; even HTML5 only based

applications, since it terminates the need for a mediate driver and allows any programming language to perform HTTP queries on the database. The advantages are clear, but does this feature come with a risk to security? We answer this on the affirmative: the REST API exposes the database to CSRF attacks allowing an attacker to bypass firewalls and other perimeter defenses. Let us examine how. As long as a database is deployed in a secure network behind security measures, such as firewalls, in order to compromise the database an attacker must either find a vulnerability that will let him into the secure network or perform an injection that will allow him to execute arbitrary queries. When a database exposes a REST API inside the secured network it allows anyone with access to the secured network to perform queries on the database using HTTP only – thus allowing such queries to be initiated even from the browser. If an attacker can inject an HTML form into a website or trick a user into a website of his own the attacker can perform any POST action on the database by submitting the form. POST actions include adding documents. In‎ our‎ research‎ we‎ inspected‎ “Sleepy‎ Mongoose”‎ which‎ is‎ mentioned in the MongoDB‎ official‎ website‎ as‎ a‎ “full‎ featured HTTP interface‎for‎MongoDB”.‎The‎API‎of‎sleepy‎ mongoose is defined by the URL in the following manner: http://{host name}/{db name}/{collection name}/{action}

Parameters for example for finding a document may be included as query parameters and new documents may be added as request data. For example if we want to add the new‎ document‎ {‎ username:‎ ‘attacker’‎ }‎ to‎ the‎ collection‎ “admins”‎ in‎ the‎ database‎ called‎ “hr”‎ on‎ the‎ “safe.internal.db”‎ host‎ we‎ would‎ send‎ a‎ POST HTTP request to: http://safe.internal.db/hr/admins/_insert

with the url encoded data: username=attacker

Now let us see how a CSRF attack utilizes this functionality in order to add a new document to the admins collection thus adding a new admin user to the HR database which is located supposedly safe in the internal network, thru a cross site request forgery attack as depicted in Figure 5. For the attack to succeed a few conditions must be met: (1) The attacker has control over a website either of his own or by exploiting a benign unsecure website. The attacker will place an HTML form in the website and a JavaScript that will submit the form automatically such as: document.forms[0].submit();

(2) The attacker needs to trick an employee to enter the infected site by means of phishing or perhaps this is a site that employees may visit on a regular basis and the attacker managed to inject the infection to it. (3) The employee

needs to have permissions and access to the mongoose HTTP interface. In this manner the employee is able to perform actions, in this case insert new data to the database which is located inside an internal network, without having access to the internal network. This attack is very simple to execute but it demands the attacker has performed some reconnaissance to identify the names‎of‎the‎host,‎database‎etc…

Figure 5: Diagram of a CSRF attack on a NoSQL HTTP REST API X.

A. Development and testing: Awareness: Obviously, building secure software which will prevent injections and other potential exploits is the best and cheapest solution. It is recommended that all the resources involved in the software lifecycle receive the appropriate security training for their role. For example a developer who understands the weaknesses is less likely to introduce one into the software. Design: Security aspects of the application must be thought of and defined in the early stages. Defining what needs to be protected in the application and how that will take place makes sure these are translated to tasks in the development phase and receive the right amount of attention and are not otherwise neglected. Code best practices: It is recommended to utilize as much shared libraries as possible which have gone thru a security validation process – thus limiting the window of security mistakes to a smaller size. For example using well validated libraries for encryption reduces the risk of the developer implementing encryption on his own and introducing vulnerabilities into the algorithm. Another example is the usage of sanitization libraries. All injection attacks are a result of lack / poor sanitization. Using a well tested sanitization library will greatly reduce the risk of introducing gaps in a self-developed sanitization method.

MITIGATION

Mitigating security risks in NoSQL deployments is important in light of the attack vectors we presented in this paper. Unfortunately, code analysis of the application layer alone is insufficient to ensure that all of the threats are mitigated. There are three main trends that make this problem even more challenging than before. First, the emerging cloud and Big Data systems typically execute multiple complex applications which use heterogeneous open source tools and platforms. These are commonly developed by open source communities and in most cases do not undergo comprehensive security testing. The second challenge is the speed of modern code development with DevOps methodologies which aim to shorten the time between the development and production. Finally, most of the existing tools for application security testing cannot keep up with the fast paste with which new programming languages are adopted (e.g. languages like Golang, Scala and Haskel are still not supported by most of the security products as well as the rapid change in usage of JavaScript). Thus, in order to fully address the threats introduced by the application layer, there is a need to consider the entire software development lifecycle. Below we describe the mechanisms for the continuous mitigation which can be helpful to achieve this.

Privilege Isolation: In the past NoSQL did not support proper authentication and role management ‎[7], today it is possible to manage proper authentication and RBAC authorization on most popular NoSQL databases. Utilizing these mechanisms is important for two reasons. First, they allow enforcing the principle of least privilege thus preventing privilege escalation attacks by legitimate users. Second, similarly to SQL injection attacks ‎[13], proper privilege isolation allows to minimize the damage in case of data store exposure via the above described injections. Security Scanning: It is recommended to run Dynamic and Static Application Security Testing (DAST and SAST) on the application / source code in order to find any injection vulnerabilities. The problem is that many of the tools in the market today still lack rules for detecting NoSQL injections. DAST methodology is considered more reliable than static analysis ‎[6], especially if used in conjunction with some backend inspection technology that improves detection reliability, a methodology referred to as Interactive Application Security Testing (IAST) ‎[7]‎[8]. It is also recommended to integrate these scans into the continuous build and deployment systems such that they run every cycle / check in and bugs are captured and fixed immediately and not only at the security testing phase. This may reduce the effort of fixing security bugs for two reasons: (1) The cost of fixing a bug in the development phase is much cheaper than later in the lifecycle. Especially since security testing tends to take place after functional testing and fixing security bugs may introduce the need to

repeat the functional testing as well. (2) The developer might learn from his bugs in an early stage and not repeat them again in other similar places in the code. Security testing: A professional security tester should test the application. These tests should include validation that all the security requirements have been met as were defined in the design phase as well as perform penetration testing on the application itself and the hosting infrastructure which is recommended to resemble the production infrastructure as much as possible.

Figure 6: Life-cycle of application and deployment security B. Secure deployment Network isolation: The concept of a secure internal network has been invalidated in countless attacks on enterprises such as the Adobe password breach, RSA, Sony and more. The internal network is bound to be infiltrated at some point and it is our duty to make it hardest for the attacker to gain advantages from that point on. This is especially true for some NoSQL databases which are relatively new and lack role based permissions which means anyone can execute anything on them such as the case for Memcached we mentioned earlier. For this a strict network configuration is recommended in order to make sure the database is only accessible to the relevant hosts that are supposed to use it such the application server. Protection of APIs: To mitigate the risks of REST API exposure and CSRF attacks, there is a need to control the requests, limiting their format. For example, CouchDB has adopted some important security measures that mitigate the risk from having a REST API exposed. These measures include accepting only JSON in the content type. HTML forms are limited to URL encoded content type and hence an attacker will not be able to use html forms for CSRF and the other alternative is using AJAX requests and those are blocked by the browser thanks to same origin policy. It is also important to make sure JSONP and CORS are disabled in the server API to make sure that no actions can be made directly from a browser. It is important to note that some databases like MongoDB have many third party REST API’s‎ which‎ are‎ encouraged‎ by‎ the‎ main‎ project,‎ some of

these are really lacking in the security measures we described here. C. Monitoring and attack detection Humans are prone to error and hence even after following all the secure development best practices vulnerabilities may still be found in the software when it is deployed. Additionally new attack vectors might be found that were not known at the time of development testing. Hence it is recommended to monitor and defend the application at runtime. But this is in no way a substitute to the prior steps in the secure development life cycle that we mentioned. While such systems may be good at finding and blocking certain attacks they are not aware of the application logic and the rules under which the application is supposed to work and they will not find 100% of the vulnerabilities. Web Application Firewalls (WAFs): are security tools that inspect HTTP data streams and detect malicious HTTP transactions. They can be implemented as appliances, network sniffers, proxies, or web server modules and are specifically designed to provide an independent security layer for web applications, detecting attacks like SQL injection. Although, it is known that attackers can bypass WAFs ‎[12], we advocate that rules for detecting NoSQL injections should be added to these systems too. Intrusion Detection Systems: Similarly to firewalls that can detect attacks at the network level, Host-based Intrusion Detection Systems (HIDS) guard the execution of the application and workloads on the servers. HIDS typically learn the normal behavior of applications and alert upon activities that do not conform to the expected behavior and can point out to an attack. Such tools can detect vulnerabilities that propagate to the OS, but will not be relevant for a SQL injection or CSRF attack. Data activity monitoring: Database activity monitoring tools became a common requirement for organizations data protection. They control the access to databases, monitor the activities with customizable security alerts and create auditable reports of data access and security events. Unfortunately, most of the solutions target relational databases, but, initial solutions to monitoring NoSQL data stores already started to appear ‎[13]. We hope that these will continue to improve and will become a common practice for NoSQL activity monitoring. These tools are the most useful monitoring and detection systems relevant for injection attacks as we demonstrated in this article. SIEM and threat intelligence: Security information and event management systems (SIEM) aggregate and correlate logs helping in attack detection. Furthermore, threat intelligence tools can assist in providing data on malicious IP addresses and domains as well as other indicators of compromise, which can help in the detection of injections. To achieve increased protection, these system can also be combine with HIDS, which can forward the details of the

actions at the operating system level to SIEM for advanced analysis and analytics. Runtime Application Self Protection (RASP): As Joseph Feiman from Gartner stated, stop protecting‎ your‎ apps,‎ it’s‎ time for apps to protect themselves, RASP introduces a new application security approach in which the defense mechanism is embedded to the application at runtime, allowing it to monitor itself. The benefit of RASP over the other security technologies lays in the ability to inspect the flow of the program and data which is being processed internally. Placing inspection points at key positions in the application allows detecting more security issues with higher accuracy. On the down side RASP has a toll on performance, is tightly coupled with the programming language and may break the application in production. XI.

SUMMARY

We have shown that NoSQL databases suffer from the same security risks as their SQL counterparts. Some of the low level techniques and protocols have changed but still the risks of injection, improper access control management and unsafe network exposure are high and similar between SQL and NoSQL systems. We recommend using mature databases with built-in security measures. However, even using the most secure data store does not prevent injection attacks which leverage vulnerabilities in the web applications accessing the data store. One way to prevent these is via careful code examination and static analysis. However, these may have high false positive rates and are difficult to conduct. While, dynamic analysis tools were shown to be very useful for the detection of SQL injection attacks ‎[7], these should be adjusted to detect the specific vulnerabilities of NoSQL databases that we described in this paper. Additionally and finally monitoring and defense systems should be used that are relevant to NoSQL risks. REFERENCES [1]

[2] [3]

[4]

[5]

[6]

[7]

"Imperva Web Application Attack Report" http://www.imperva.com/docs/HII_Web_Application_Attack_Report _Ed4.pdf No SQL and No Security https://www.securosis.com/blog/nosql-andno-security Okman, Lior, et al. "Security issues in nosql databases." Trust, Security and Privacy in Computing and Communications (TrustCom), 2011 IEEE 10th International Conference on. IEEE, 2011. Sahafizadeh, Ebrahim, and Mohammad Ali Nematbakhsh. "A Survey on Security Issues in Big Data and NoSQL." Vol. 4, Issue 4, July 2015 © ACSIJ PUBLICATION Factor, Michael, et al. "Secure Logical Isolation for Multi-tenancy in cloud storage." Mass Storage Systems and Technologies (MSST), 2013 IEEE 29th Symposium on. IEEE, 2013. Haldar, Vivek, Deepak Chandra, and Michael Franz. "Dynamic taint propagation for Java." Computer Security Applications Conference, 21st Annual. IEEE, 2005. 9 Advantages of Interactive Application Security Testing (IAST) over Static (SAST) and Dynamic (DAST) Testing http://www1.contrastsecurity.com/blog/9-reasons-why-interactivetools-are-better-than-static-or-dynamic-tools-regarding-applicationsecurity

[8]

[9] [10]

[11] [12] [13]

[14] [15]

Glass Box: The Next Phase of Web Application Security Testing? http://www.esecurityplanet.com/network-security/glass-box-the-nextphase-of-web-application-security-testing.html MongoDB documentation on Security http://docs.mongodb.org/manual/core/security-introduction/ Memcached injections WP https://www.blackhat.com/docs/us14/materials/us-14-Novikov-The-New-Page-Of-Injections-BookMemcached-Injections-WP.pdf PHP usage statistics http://w3techs.com/technologies/details/plphp/5/all Ristic, Ivan. "Protocol-Level Evasion of Web Application Firewalls." Black Hat US Proceedings (July 2012) (2012). Organizations Ramp Up on NoSQL Databases, but What About Security? https://securityintelligence.com/organizations-ramp-up-onnosql-databases-but-what-about-security/ Practical Threat Management for Government Entities, SANS Whitepaper, Jacob Williams May 2015 State of Software Security Report, Varacode, 2013