NoSQL Injection Analysis and relief, nosql injection relief

NoSQL Injection Analysis and relief, nosql injection relief

Key points of this article:

1. Learn about new security vulnerabilities against NoSQL
2.Five types of NoSQL attack methods, such as tautology, joint query, JavaScript injection, piggybacked queries, and cross-domain violations
3.OWASP organization's recommendations for checking NoSQL injection code
4. Learn how to mitigate security risks
5. How to integrate NoSQL database vulnerability management throughout the software development cycle 

IEEE Software provides reliable and expert-reviewed information on today's strategic technical issues. IT managers and technical leaders should rely on IT professionals with new and advanced solutions to meet the challenges of reliable and flexible enterprises.
NoSQL (not just NoSQL) data storage systems are very popular because they are scalable and easy to use. Although the new data model and Query format of NoSQL data storage make the original attack no longer effective, attackers can find new opportunities to insert malicious code.
Database security is an important part of information security. Attackers can access enterprise databases to gain full control over key data. For example, the SQL Injection Attack inserts malicious code into the statements sent by the application to the database layer. This allows attackers to perform almost any operations on data, including access to unauthorized data, and modification, deletion, and insertion of data. Although the framework is safer and more conscious, the utilization of SQL injection has steadily declined in recent years, it is still a high-risk system vulnerability. For example, if a Web application suffers four or more Web attacks each month, SQL injection is still the most popular method for attacking retailers. In addition, the SQL injection vulnerability has an impact on 32% of Web applications.
NoSQL (not just SQL) is a popular trend in data storage. It generally refers to non-relational databases that rely on different storage mechanisms. These storage mechanisms include document storage, key-Value Pair storage, and graph. These databases are widely used by modern large applications, such as Facebook, Amazon, and Twitter. They need to distribute data to many servers. Traditional relational databases do not meet this scalability requirement. They need a single database node to execute all the operations of the same transaction.
Therefore, a batch of distributed, NoSQL key-value pairs were developed to meet the scalability requirements of these large-scale applications. Such data storage includes NoSQL databases such as MongoDB and Cassandra, as well as memory and cache storage such as Redis and Memcached. Indeed, the popularity of NoSQL has steadily increased over the past few years, with MongoDB ranking fourth among the 10 most popular databases, as shown in 1.

Figure 1 Top 10 most popular databases in db-engines.com August 2015 popularity rankings. NoSQL databases include MongoDB, Cassandra, and Redis. The popularity of these three models is still rising.
In this article, we will analyze the threats and technologies of NoSQL and their mitigation mechanisms.
I. NoSQL Vulnerabilities
Like almost every new technology, NoSQL databases are not safe enough when they first emerge. At the beginning, they lacked encryption, proper authentication, role management, and fine-grained authorization. In addition, they may also have dangerous risk exposure and Denial of Service Attack 3. Now, the situation has improved. The popular database has introduced the built-in protection mechanism 7.
NoSQL databases use different query languages, which makes the traditional SQL Injection Technology ineffective. But does this mean that the NoSQL system is immune to injection? Our research shows that although the query language and its driving security have been greatly improved, there are still some malicious query injection methods. Someone has sorted out the list of NoSQL injection technologies 1, 3, and 4. Some preliminary Application scanning projects have emerged (such as nosqlproject.com), and the Open Web Application Security Project (OWASP, Open Web Application Security Project) has published suggestions for checking NoSQL injection code. However, these are only preliminary results, and these issues have not yet been fully studied and have not received due attention.
Ii. NoSQL attack methods
Web applications and services usually use NoSQL databases to store customer data. Figure 2 shows a typical architecture where NoSQL is used to store data accessed through Web applications. A driver is used to access the database, that is, an access protocol package. It provides class libraries for database clients written in multiple programming languages. Although the driver itself may not be vulnerable to attacks, sometimes it provides insecure APIs. When application developers mistakenly use them, they will introduce vulnerabilities to the application, these vulnerabilities are exploited to perform any operations on the database. As shown in 2, attackers can forge a Web access request with injection code. When the database client or Protocol package is processed, the expected illegal database operations will be performed.

Figure 2 typical Web application architecture. NoSQL is used to store data accessed through Web applications. A driver is used to access the database, that is, an access protocol package. It provides class libraries for database clients written in multiple programming languages. Although the driver itself may not be vulnerable to attacks, sometimes it provides insecure APIs. When application developers mistakenly use them, they will introduce vulnerabilities to the application.
NoSQL-related SQL attack mechanisms can be roughly divided into the following five categories:
1. Just a few words.It is also called permanent truth. This type of attack injects code into a condition statement so that the generated expression determines that the result is always true, bypassing authentication or access mechanisms. For example, in this article, we will show how attackers can use the $ ne operation (not equal) syntax to allow them to access the system illegally without corresponding creden.
2. join query.Joint query is a well-known SQL injection technology. Attackers use a fragile parameter to change the dataset returned by a given query. The most common method of joint query is to obtain data through the authentication page. In this article, we will show an attack example, which will use the Boolean OR operator to launch an attack by adding a permanent expression, leading to an error in the entire statement determination and illegal data acquisition.
3. JavaScript injection.This is a new vulnerability introduced by NoSQL databases that allow JavaScript Execution of data content. JavaScript makes it possible to perform complex transactions and queries in the Data Engine. Attackers can inject arbitrary JavaScript code into these queries, which results in illegal data acquisition or tampering.
4. Negative query.In a back-load query, attackers can use escape characters (such as carriage returns and line breaks) to insert an extra query executed by the database, so that arbitrary code can be executed.
5. Cross-origin violation.Http rest APIs is a popular module in NoSQL databases. However, they introduce a new type of vulnerability that can even allow attackers to attack databases from other domains. In cross-origin attacks, attackers use legitimate users and their Web browsers to perform harmful operations. In this article, we will demonstrate this type of cross-site Request Forgery (CSRF) attack in the form of violations, the user browser trusted on this website will be exploited to perform illegal operations on the NoSQL database. By injecting HTML code into a website with vulnerabilities or deceiving users to access an attacker's website, attackers can execute post actions on the target database to destroy the database.
Iii. JSON query and Data Format
Although relatively secure, the popular JSON format can still be attacked by new types of injection. We will give an example of such attacks in MongoDB. MongoDB is a document-oriented database that has been used by many large vendors, including eBay, Foursquare, and LinkedIn.
In MongoDB, queries and data are described in JSON format, which is better than SQL in terms of security, because it is more fully defined and easy to encrypt and decrypt, in addition, there are good native implementations in each programming language. The destruction of the query structure like SQL injection is more difficult to implement in queries with JSON structures. Common insert statements in MongoDB are as follows:

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

This inserts a new document into the books collection. It has the title and author fields. The common query conditions are as follows:

db.books.find({ title: 'The Hobbit' })

In addition to limiting the fields to be queried, the query can also contain regular expressions and conditions.
Iv. PHP heavy talk Injection
Let's take a look at the architecture shown in Figure 3. A Web application that uses PHP to implement the backend will encode the request for querying data storage in JSON format. Let's use a MongoDB example to demonstrate the array injection vulnerability. In terms of technology and results, this is an attack method similar to SQL injection.

Figure 3 use the PHP application of MongoDB. A backend Web application that uses PHP to encode requests used to query data storage in JSON format.
PHP encoded array is native JSON. An array example is as follows:

array('title' => 'The Hobbit',   'author' => 'J.R.R. Tolkien');

PHP will encode the following JSON format:

{"title": "The Hobbit", "author":   "J.R.R. Tolkien"}

If a PHP has a login mechanism, the user's browser sends the user and password through http post (which is vulnerable to attacks like http get), the common post url encoding should be like this:

username=Tolkien&password=hobbit

The backend PHP code processes the user and queries MongoDB as follows:

db->logins->find(array("username"=>$_   POST["username"],   "password"=>$_POST["password"]));

This is reasonable. intuitively, developers may like to use the following query:

db.logins.find({ username: 'tolkien',   password: 'hobbit'})

However, PHP has a built-in mechanism for associated arrays, which allows attackers to send the following malicious data:

username[$ne]=1&password[$ne]=1

PHP parses the input as follows:

array("username" => array("$[ne] " =>   1), "password" =>   array("$ne" => 1));,

It is encoded as the following MongoDB query:

db.logins.find({ username: {$ne:1 },   password {$ne: 1 })

Because $ ne is used by MongoDB to determine whether the conditions are not equal, It queries the records of all users in the logon set whose names are not equal to 1 and whose passwords are not equal to 1. Therefore, this query returns all users in the logon set. The SQL statement is equivalent to the following query statement:

SELECT * FROM logins WHERE username <>   1 AND password <> 1

In this case, the vulnerability allows an attacker to log on to the application without a valid credential. In other variants, this vulnerability may cause illegal data access or privileged operations by unprivileged users. To alleviate this problem, we need to convert the parameters received from the requirement to the appropriate type. In this example, strings can be used, as shown below:

db->logins->find(  array("username"=>(string)$_    POST["username"],  "password"=>(string)$_    POST["password"]));

V. NoSQL joint query Injection
The SQL injection vulnerability is often caused by the lack of proper encoding of user input and direct query. In popular data storage such as MongoDB, The JSON query structure makes the attack more difficult. However, this does not mean that it is impossible.
Let's look at a login form that sends username and password parameters to the backend through http post. It concatenates strings to obtain query statements. For example, developers may do this:

string query = "{ username: '" + post_   username + "', password:   '" + post_passport + ' " }"

When a valid input is available, the query statement is as follows:

{ username: 'tolkien', password:    'hobbit' }

However, if a password is entered maliciously, the query statement will be converted to a password ignored. you can log on to the user account without a password. An example of malicious input is as follows:

username=tolkien', $or: [ {}, {'a':   'a&password=' }],$comment: 'successful MongoDB   injection'

The input will be built into the query:

{ username: 'tolkien', $or: [ {}, {   'a': 'a', password '' } ], $comment: 'successful MongoDB   injection' }

If the user name is correct, the query is successful. Converts the statement to an SQL statement. This query is similar to the following statement:

SELECT * FROM logins WHERE username =    'tolkien' AND (TRUE OR ('a'='a' AND password = '')) 

The password is a redundant part of the query. because the conditions in () are always true, the final result of the query is not affected.
How did this happen? The following are the concatenated query strings. The user input is a bold font, and the remaining text strings are non-formatted fonts:

{ username: 'tolkien', $or: [ {}, {    'a': 'a', password '' } ], $comment: 'successful MongoDB    injection' }

This attack will succeed if the user name is correct. Generally, it is not difficult to get a user name.
Vi. NoSQL JavaScript injection
NoSQL databases have a common feature, that is, they can run JavaScript in the database engine to execute complex queries or transactions such as MapReduce. Popular databases, such as MongoDB and CouchDB, as well as other popular databases such as Cloudant and BigCouch, are allowed to do so. If this query method is found in non-clean user input, executing JavaScript would expose the weak surface to attackers. For example, imagine a complex transaction that requires JavaScript code, including unclean user input as a query parameter. Let's take a look at its storage model. It stores a set of entries, each of which has the price and quantity attributes. To get the total number or average value of these attributes, the developer has compiled a MapReduce function that receives the quantity or price from the user as a parameter and then processes it. In PHP, it looks like the following code ($ 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 aggregates $ param given by name for each entry. At that time, $ param was expected to receive the amount or price, and this code will run as expected. However, malicious input (which may contain arbitrary JavaScript) is executed because user input is not escaped.
Take a look at the following input:

function(kv) { return 1; }, {    out: 'x' });db.injection. insert({success:1});return 1;

The first part of the data will close the original MapReduce function, and then the attacker can execute the desired JavaScript on the database (bold part ). Finally, the last part calls a new MapReduce to maintain a balance between the original statements of the injected code. After merging the executed user input into a string, we get the following code (the injected user input is displayed in 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 the classic SQL injection. One way to defend against such attacks is to disable JavaScript execution in the database configuration. If JavaScript is required, the best policy is not to use any user input.
VII. Key-value pair data storage
Key-Value Pair storage such as Memcached, Redis, and Tachyon is a memory data storage designed to speed up the execution of applications, cloud architectures and platforms, and a large number of frameworks. These platforms consider the storage and retrieval of frequently accessed data. They are usually before data storage, as shown in figure 4. The Cache architecture often stores authentication tokens and container access control lists. Each subsequent user request must take effect again.

Figure 4 distributed memory data storage Architecture. The attacked Web server uses a key-value data storage for quick data retrieval. The query of data storage is built on the Web server through the data provided by the user. If the processing is inappropriate, user data can cause an invalid query injection, which will be stored and processed by the key-value face data, resulting in errors in the application logic, attackers can bypass authentication or perform harmful data retrieval.
Although the key-Value Pair query is very simple, the cache API is usually very simple, but we find a Memcached (the second popular key-value pair is not fully visible) potential injection attack means, the vulnerability is based on the Memcached driver of a specific PHP version. The following conditions are met to launch an attack:

1. the property (for example, value) passed to the cache set/get is the information from the user request (for example, HTTP header) 2. the received string is sent without processing 3. cached attributes include sensitive information that will lead to query execution that is different from the expected behavior.

If these conditions are met, attackers can inject query or manipulate query logic, such as a negative query attack.
8. Negative Query
Add a key and corresponding value to a group of operations in the database using Memcached. When called from the command line interface, this set of functions uses two lines of input, the first line is:

set <KEY> <FLAG> <EXPIRE_TIME>   <LENGTH>,

The second row is composed of the data to be saved.
When the function configured in PHP is called, the two parameters it receives look like this:

$memcached->set('key', 'value');

The researchers indicated that the driver failed to take action against the \ n (0x0A) ASCII code with carriage return \ r (0x0D) and line feed, as a result, attackers have the opportunity to inject new command lines containing key parameters and other unplanned commands into the cache.
Take a look at the following code. $ param serves as the user input and as the key:

$memcached=new Memcached(); $memcached ->addServer('localhost',11211); $memcached->set($param, "some value");

Attackers can provide the following input for injection attacks:

"key1 0 3600 4\r\nabcd\r\nset key2 0 3600 4\r\ninject\r\n"

In this example, the first key added to the database is key1 with a "some value" value. Attackers can add other, unplanned keys to the database, that is, key2 with an "inject" value.
This injection can also happen on the get command. Let's take a look at the example on the Memcached homepage. It starts with these three lines:

Function get_foo(foo_id) foo = memcached_get("foo: " . foo_id) return foo if defined foo

This example shows the typical usage of Memcached. Before processing input, first check whether the input already exists in the database. If you use similar code to check the authentication token received from the user and verify that they have logged on, you can use it by passing the following string as the token (the injection part has been highlighted in bold):

"random_token\r\nset my_crafted_token 0 3600 4\r\nroot\r\n" 

When this string is passed as a token, the database will check whether this "random_token" exists, and then add a "my_crafted_token" with "root" value ". Then, the attacker can send the my_crafted_token with the root identity.
Other commands that can be attacked by this technology include:

incr <Key> <Amount>decr <Key> <Amount>delete <Key>

Here, incr is used to add a key value, decr is used to reduce a key value, and delete is used to delete a key. Attackers can also use the three functions that bring their own key parameters in the same way as the set and get functions.
Attackers can use the multi-entry function to perform the same injection: deleteMulti, getMulti, and setMulti. Each key field can be injected.
Carriage return line feed injection can be used to connect multiple get requests. In a test we conducted, up to 17 connections can be established, including the original get. In this way, the result returned by the injection is the first key and its corresponding value.
The driver vulnerability has been fixed in PHP 5.5, but unfortunately it already exists in all previous PHP versions. According to W3Techs.com's statistics on the production system's PHP version, more than 86% of PHP websites use older versions than 5.5, this means that if they use Memcached, they will be vulnerable to this injection attack.
IX. Cross-Origin Violation
Another common feature of NoSQL databases is that they can often expose http rest APIs that can be used to query databases from client applications. Databases that expose REST APIs include MongoDB, CouchDB, and HBase. When the rest api is exposed, the database is directly exposed to the application, or even HTML5-based applications, because it no longer requires Indirect drivers, allows any programming language to execute HTTP queries on the database. The advantage of doing so is obvious, but is this feature accompanied by security risks? Our answer is yes: This rest api exposes the database to cross-site Request Forgery (CSRF), allowing attackers to bypass the firewall and other peripheral defenses.
As long as the database is deployed in a security network such as a firewall, attackers must find a vulnerability that allows them to access the security network, or you can inject arbitrary queries. When a database exposes a rest api in a security network, anyone who can access the security network can perform queries on the database only through HTTP, therefore, you can initiate such queries in the browser. If an attacker can input an HTML form on the website or fool the user into the website of the attacker, the attacker can submit the form to execute any post operations on the database. The post operation includes adding files.
We are investigating and examining Sleepy Mongoose, a full-featured HTTP interface for MongoDB. Sleepy Mongoose API is defined in a URL format such as http: // {host name}/{db name}/{collection name}/{action. File search parameters can be included as query parameters, and new files can also be added as request data. For example, if we want. internal. add a new file {username: 'attacker'} to the database administrator set named hr on the db host to send a post HTTP request to the response.
Now let's take a look at how the CSRF attack uses this function to add new files to the Administrator set, so as to be in the hr database (which is considered to be in a safe internal network) add a new administrator user, as shown in Figure 5. To successfully launch an attack, you must meet the following conditions. First, attackers must be able to operate a website, either on their own or on insecure websites. The attack places an HTML form on the website and a script that will automatically submit the form, for example:

<form action=" http://safe.internal. db/hr/admins/_insert" method="POST" name="csrf"><input type="text" name="docs" value=" [{"username":attacker}]" /></form><script> document.forms[0].submit(); </script>

Figure 5 NoSQL http rest api-based cross-site request negative attacks. Users in the internal network hidden behind the firewall are spoofed to access a malicious external webpage, which causes unexpected queries to be executed on the rest api of the NoSQL database in the internal network.
Second, attackers must trick users into accessing infected websites through the Internet or infect websites frequently accessed by users. Finally, the user must be authorized to access the Mongoose HTTP interface.
In this way, attackers can perform operations without entering the internal network. In this example, new data is inserted into the database located in the internal network. This attack is easy to execute, but requires the attacker to detect the host, database name, and so on in advance.
10. Mitigation
Given the attack methods we mentioned in this article, it is very important to mitigate the security problems in NoSQL deployment. Unfortunately, application-layer code analysis is insufficient to mitigate all risks. The three trends present more challenges than before. First, cloud and big data systems usually execute multiple complex applications that use heterogeneous open-source tools and platforms. These applications are usually developed by the open-source community and in most cases have not been thoroughly tested for security. Another challenge is the speed of Modern code development formed along with the DevOps methodology, because DevOps seeks to shorten the time between development and production. Finally, most application security testing tools cannot be synchronized with applications in the new programming language. For example, most security products do not support Golang, Scala, and Haskel.
11. Development and testing
To fully address the risks introduced by the application layer, we need to consider the entire software development lifecycle, as shown in figure 6.

Figure 6 Application and deployment security Lifecycle. To fully address the risks introduced by the application layer, we need to consider the entire software development lifecycle.
1. consciousness.
Obviously, building security software that blocks injection and other potential vulnerabilities is the best and cheapest solution. We recommend that people involved in the software life cycle receive appropriate security training for their responsibilities. For example, developers who have understood vulnerabilities are unlikely to introduce them into the software.
2. design.
Application Security must be considered and defined in the early stages of development. Define what needs to be protected within the application, and how to ensure that this function has been converted into tasks in the development phase and has been paid enough attention.
3. Best practices for code.
We recommend that you take full advantage of the shared class libraries that have undergone security verification and processing to reduce the chance of making security errors. For example, you can use a class library that has been fully authenticated to reduce the risk that developers can introduce vulnerabilities into algorithms by implementing authentication on their own. Here is another example of using the "sanitization" class library. All injection attacks are caused by a lack of disinfection. Using a class library that has been fully tested and disinfected can greatly reduce the risk of introducing vulnerabilities through self-developed disinfection methods.
4. Privileged isolation.
In the past, NoSQL did not support proper authentication and role management 9. Now, it is possible to perform proper authentication management and Role-Based Access Control authentication on most popular NoSQL databases. These mechanisms are very important for two reasons. First, they allow the implementation of the principle of least privilege, so as to avoid attacks by upgrading the privilege of legitimate users. Second, similar to SQL injection attack 10, when data storage is exposed under the injection attack we mentioned in this article, proper privilege isolation can minimize the harm.
5. security scanning.
We recommend that you run dynamic and static application security tests (DAST and SAST respectively) on the application or source code to detect injection vulnerabilities. The problem is that many tools on the market lack the rules for detecting NoSQL injection. The DAST method is considered to be more reliable than SAST 11. Especially if you use the backend check method to improve the detection reliability, This is a method proposed for interactive application security testing 9, 12. It also recommends that these scanning tools be integrated into the continuous build and release systems so that they are executed at each cycle or check, and defects are detected and repaired in a timely manner, not just in the security test phase.
For two reasons, this may reduce the workload for fixing security defects. First, the cost of fixing defects in the development phase is much lower than that in the later stages of the lifecycle, especially because security tests often follow functional tests, in addition, you may need to perform a functional test again to fix security defects. Second, developers can understand these defects at an early stage and will not make similar errors in subsequent code development.
6. Security Testing.
Applications should be tested by professional security testers. These tests should validate that all security requirements defined at the design stage have been met and should include penetration tests on applications and host infrastructure (recommended as similar as the production environment as possible.
12. Secure deployment
An important part of maintaining applications is ensuring secure deployment. If the deployment is not secure enough, all the security efforts at the application code layer may be overwhelmed. This stage is sometimes ignored.
Network isolation. Enterprises such as Adobe, RSA Security, and Sony have suffered numerous attacks. In these attacks, the concept of Intranet Security is no longer true. In some cases, the internal network is the border of Penetration. We should try our best to make it difficult for attackers to get anything from this point. This is especially true for some newer NoSQL databases that lack role-based authorization. Therefore, we recommend that you strictly configure the network to ensure that the database can only be accessed by the relevant host, such as the application server.
API protection. To mitigate the risk of rest api exposure and CSRF attacks, you need to control requests and limit their formats. For example, CouchDB has adopted some important security measures to mitigate the risks caused by exposed REST APIs. These measures include accepting only the JSON content format. HTML forms are restricted to URL-encoded content formats. Therefore, attackers cannot use HTML for CSRF attacks. Another measure is to use Ajax requests, because requests initiated by the same-origin policy from the browser will be blocked. It is also important to ensure that JSONP and cross-origin resource sharing have been canceled in the server's API and that operations cannot be initiated directly from the browser. Some databases, such as MongoDB, have many third-party REST APIs, many of which lack the security measures we mentioned here.
13. Monitoring and Attack Detection
Humans are prone to mistakes. Even if they follow all the best security development practices, they may still find vulnerabilities in the software after development. In addition, new attack paths unknown during development and testing may be discovered. Therefore, it is recommended to monitor and defend applications at runtime. Although these systems may be good at discovering and blocking certain attacks, they do not understand the application logic and the rules under the hypothetical running applications, so they cannot identify all the vulnerabilities.
1. Web application firewall.
WAFs is a security tool used to check HTTP data streams and detect malicious HTTP transactions. They can be used as electrical appliances, network sniffer, proxy, or website server modules to provide an independent security layer for Web applications to detect attacks such as SQL injection. Although known attacks can bypass firewall 13, we advocate adding rules for detecting NoSQL injection to these systems.
2. intrusion detection system.
Similar to firewalls that can detect attacks at the network layer, the host-based intrusion detection system (HIDSs) monitors application execution and server load. HIDSs generally understands the normal behaviors of applications and provides warnings for behaviors that do not match the expected behaviors. They may be attacks. This type of tool can detect vulnerabilities spread on the operating system, but it has nothing to do with SQL detection or CSRF.
3. Data activity monitoring.
The data activity monitoring tool has become a common requirement for organization data protection. They control data access to customize security alert monitoring activities and create data access and security event audit reports. Although most solutions are targeting relational databases, the monitoring of NoSQL data storage has begun to emerge 10. We hope these will be constantly improved into the conventional practices of NoSQL activity monitoring. These tools are very useful monitoring and detection systems for injection attacks we have demonstrated in this article.
4. Security Information and event management (SIEM) systems and threat alerts.
The Security Information and event management system sorts logs and sorts the log associations to help detect attacks.
In addition, Threat alert tools can help provide malicious IP addresses, domain data, and other harmful indicators, which can help detect injection.
5. runtime application self-protection (RASP ).
In the runtime, application self-protection introduces a new application security method. The defense mechanism is embedded into the application at runtime so that it can perform self-monitoring. The advantage of self-protection in runtime applications exceeds that of other security technologies because it can check internal program flow and data processing. Setting checkpoints in key locations of applications can more accurately detect more problems. The disadvantage is that the runtime application self-protection pays a performance cost. It is highly dependent on programming languages and may cause applications to stop running in the production environment.
NoSQL databases suffer from risks like traditional databases. Some low-layer technologies and protocols have changed, but injection risks, incorrect access control management, and insecure network exposure remain high. We recommend that you use a mature database with built-in security measures. However, even with the most secure data storage, it is impossible to prevent the injection attack that uses Web application vulnerabilities to access data storage. One way to avoid these problems is through careful code checks and static analysis. However, these are difficult to implement and may have a high false positive rate. Although dynamic analysis tools have shown that they are useful for detecting SQL injection attacks, they need to be adjusted to detect the NoSQL database-specific vulnerabilities we mentioned in this article. In addition, monitoring and defense systems related to NoSQL risks should also be used.