www.invicti.com Open in urlscan Pro
2606:4700::6812:918  Public Scan

Form analysis
3 forms found in the DOM

GET https://www.invicti.com/

<form role="search" method="get" class="sub-nav-search-form" action="https://www.invicti.com/" __bizdiag="115" __biza="W___">
  <input type="text" placeholder="Type here to search..." name="s">
</form>

POST https://netsparker.us18.list-manage.com/subscribe/post?u=5b95175e9d922bf109568e064&id=c41662cd70

<form action="https://netsparker.us18.list-manage.com/subscribe/post?u=5b95175e9d922bf109568e064&amp;id=c41662cd70" method="post" target="_blank" class="maillist-subscribe" __bizdiag="66081660" __biza="W___">
  <input class="form-control" name="EMAIL" placeholder="Enter your email to signup for the latest posts" type="email" required="" value="">
  <button type="submit" class="btn btn--primary">Subscribe</button>
</form>

POST https://netsparker.us18.list-manage.com/subscribe/post?u=5b95175e9d922bf109568e064&id=c41662cd70

<form action="https://netsparker.us18.list-manage.com/subscribe/post?u=5b95175e9d922bf109568e064&amp;id=c41662cd70" method="post" target="_blank" class="maillist-subscribe" __bizdiag="66081660" __biza="W___">
  <input class="form-control" name="EMAIL" placeholder="Email" type="email" required="" value="">
  <button type="submit" class="btn btn--primary">SUBSCRIBE</button>
</form>

Text Content

Netsparker is now Invicti
Get a demo
AppSec with Zero Noise Get a demo
Get a demo
 * Product
   * Overview
   * Features
 * Why Us?
   * Solutions
     * Industries
       * IT & Telecom
       * Government
       * Financial Services
       * Education
       * Healthcare
     * Roles
       * CTO & CISO
       * Engineering Manager
       * Security Engineer
       * DevSecOps
   * Comparison
   * Case studies
   * Customers
   * Testimonials
 * Plans
 * About Us
   * Our Story
   * In the news
   * Careers
   * Contact us
 * Resources
   * Blog
   * White Papers
   * Webinars
   * Resource Library
   * Invicti Learn
   * Partners
     * Channel
     * MSSP
   * Support


Web Security Blog
 * Web Security
 * News
 * Product Releases
 * Product Docs & FAQs


Search Close search bar


WHAT IS NOSQL INJECTION AND HOW CAN YOU PREVENT IT?

Zbigniew Banach - Fri, 29 May 2020 -
 * 
 * 
 * 

NoSQL injection vulnerabilities allow attackers to inject code into commands for
databases that don’t use SQL queries, such as MongoDB. Let’s see how NoSQL
injection differs from traditional SQL injection and what you can do to prevent
it.

Subscribe

Your Information will be kept private.

Stay up to date on web security trends
SUBSCRIBE

Your Information will be kept private.


A QUICK INTRODUCTION TO NOSQL

Even if you don’t work with databases, you’ve probably heard of NoSQL among the
cloud-related buzzwords of the past few years. NoSQL (a.k.a. “non-SQL” or “not
only SQL”) is a general term covering databases that don’t use the SQL query
language. In practice, it’s used to refer to non-relational databases that are
growing in popularity as the back-end for distributed cloud platforms and web
applications. Instead of storing data in tables, as with relational databases,
NoSQL data stores use other data models that are better suited for specific
purposes, such as documents, graphs, objects, and many others. 

MongoDB, currently one of the most popular NoSQL database products, stores data
as documents using a syntax similar to JSON (JavaScript Object Notation). Among
other benefits, this allows developers to build full-stack applications using
only JavaScript. We will use MongoDB queries to demonstrate how attackers can
exploit unvalidated user input to inject code into a web application backed by a
NoSQL database.


WHY MONGODB INJECTION IS POSSIBLE

With traditional SQL injection, the attacker exploits unsafe user input
processing to modify or replace SQL queries (or other SQL statements) that the
application sends to a database engine. In other words, an SQL injection allows
the attacker to execute commands in the database. Unlike relational databases,
NoSQL databases don’t use a common query language. NoSQL query syntax is
product-specific and queries are written in the programming language of the
application: PHP, JavaScript, Python, Java, and so on. This means that a
successful injection lets the attacker execute commands not only in the
database, but also in the application itself, which can be far more dangerous.

MongoDB uses the Binary JSON (BSON) data format and comes with a secure BSON
query assembly tool. Queries are also represented as BSON objects (i.e. binary
data), so direct string injection is not possible. However, MongoDB deliberately
allows applications to run JavaScript on the server within the $where and
mapReduce operations. The documentation is very clear that if this functionality
is used, the developer should take care to prevent users from submitting
malicious JavaScript. In other words, MongoDB deliberately includes a potential
injection vector. So what can a malicious user do if the developer is not
careful?


SIMPLE MONGODB INJECTION IN PHP

For a basic authentication bypass, the attacker can try to enter MongoDB
operators in field values, for example $eq (equals), $ne (not equal to) or $gt
(greater than). Here’s an unsafe way to build a database query in a PHP
application, with the parameter values taken directly from a form:

$query = array("user" => $_POST["username"], "password" => 
    $_POST["password"]);

If this query is then used to check login credentials, the attacker can abuse
PHP’s built-in associative array processing to inject a MongoDB query that
always returns true and bypass the authentication process. This may be as simple
as sending the following POST request:

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

PHP will translate this into an array of arrays:

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

When sent as a MongoDB query to a user store, this will find all users where the
user name and password are not equal to 1, which is highly likely to be true and
may allow the attacker to bypass authentication.


JAVASCRIPT INJECTION IN MONGODB

Let’s say we have a vulnerable application where the developer uses MongoDB’s
$where query operator with unvalidated user inputs. This allows an attacker to
inject malicious input containing JavaScript code. While the attacker can’t
inject completely arbitrary JavaScript, only code that uses a limited set of
functions, this is quite enough for a useful attack.

To query a MongoDB data store with the $where operator, you would normally use
the find() function, for example:

db.collection.find( { $where: function() { 
    return (this.name == 'Invicti') } } );

This would match records with name Invicti. A vulnerable PHP application might
directly insert unsanitized user input when building the query, for example from
the variable $userData:

db.collection.find( { $where: function() { 
    return (this.name == $userData) } } );

The attacker might then inject an exploit string like 'a'; sleep(5000) into
$userData to have the server pause for 5 seconds if the injection was
successful. The query executed by the server would be:

db.collection.find( { $where: function() { 
    return (this.name == 'a'; sleep(5000) ) } } );

Because queries are written in the application language, this is just one of the
many types of injection possible. For example, if Node.js is used for
server-side scripting, as in the popular MEAN stack (MongoDB, ExpressJS,
AngularJS, and Node.js), server-side JavaScript injection into Node.js may be
possible.


PREVENTING NOSQL INJECTION ATTACKS

The consequences of a successful MongoDB injection or other NoSQL injection
attack can be even more serious than with traditional SQL injection. Attackers
can not only extract data from the database, but also execute code in the
context of the application, for example to perform denial of service attacks or
even compromise admin user accounts and take control of the server. Such attacks
are especially dangerous since NoSQL data stores are often a novelty to
developers familiar only with relational database products, which increases the
risk of insecure code.

Many popular NoSQL products are still young and under intense development, so
it’s always a good idea to use the most recent version. For example, earlier
versions of MongoDB were notoriously insecure on many levels and had serious
injection vulnerabilities, while in more recent versions, security is taken much
more seriously.

As is often the case in web application security, the best way to prevent NoSQL
injection attacks is to avoid using unsanitized user inputs in application code,
especially when building database queries. MongoDB, for example, has built-in
features for secure query building without JavaScript. If you do need to use
JavaScript in queries, follow the usual best practices: validate and encode all
user inputs, apply the rule of least privilege, and know your language to avoid
using vulnerable constructs. For more advice, see the OWASP page on testing for
NoSQL injection.


ABOUT THE AUTHOR

Zbigniew Banach - Managing Editor & Senior Cybersecurity Writer

Cybersecurity writer and blog managing editor at Invicti Security. Drawing on
years of experience with security, software development, content creation,
journalism, and technical translation, he does his best to bring web application
security and cybersecurity in general to a wider audience.


RELATED ARTICLES


CYBER WORKFORCE SHORTAGES STILL LOOM LARGE – BUT THE CAVALRY IS COMING


5 REASONS WHY PROOF-BASED SCANNING IS A GAME-CHANGER


5 REASONS WHY CONTINUOUS VULNERABILITY TESTING AND MANAGEMENT BEATS AD-HOC
SCANNING


ETHICAL HACKING VS. THE LAW – WILL YOU GET ARRESTED FOR A GOOD DEED?


MOST POPULAR ARTICLES


SQL INJECTION CHEAT SHEET


HTTP SECURITY HEADERS: AN EASY WAY TO HARDEN YOUR WEB APPLICATIONS


HOW YOU CAN DISABLE DIRECTORY LISTING ON YOUR WEB SERVER – AND WHY YOU SHOULD


JSON INJECTION

Invicti Security Corp
1000 N Lamar Blvd Suite 300
Austin, TX 78703, US

© Invicti 2023

 * RESOURCES
   * Features
   * Integrations
   * Plans
   * Case Studies
   * Advisories
   * Invicti Learn
 * USE CASES
   * Penetration Testing Software
   * Website Security Scanner
   * Ethical Hacking Software
   * Web Vulnerability Scanner
   * Comparisons
   * Online Application Scanner
 * WEB SECURITY
   * The Problem with False Positives
   * Why Pay for Web Scanners
   * SQL Injection Cheat Sheet
   * Getting Started with Web Security
   * Vulnerability Index
   * Using Content Security Policy to Secure Web Applications
 * COMPANY
   * About Us
   * Contact Us
   * Support
   * Careers
   * Resources
   * Partners

© Invicti 2023
 * Legal
 * Privacy Policy
 * California Privacy Rights
 * Terms of Use
 * Accessibility
 * Sitemap

By using this website you agree with our use of cookies to improve its
performance and enhance your experience. More information in our Privacy Policy.

OK