Skip to main content

NoSQL injection

Need​

Prevention of NoSQL injection attacks

Context​

  • Usage of Ruby 2.0 for developing Ruby applications
  • Usage of Rails framework for building web applications
  • Usage of ActiveRecord for Object-Relational Mapping (ORM) in a Node.js application

Description​

Non compliant code​

def search_product
  product_name = params[:product_name]
  products = Product.where("name like ?", product_name)
  render json: products
end

The above code is a simple search function in a Ruby on Rails application that takes a product name as a parameter from the user and searches for it in the database. The problem with this code is that it is vulnerable to NoSQL injection.

The function does not validate or sanitize the product_name input before using it to query the database. If an attacker provides a specially crafted string as input, they might be able to manipulate the query to retrieve unauthorized data or perform other malicious operations.

For example, an attacker could provide a string such as {$ne: ""} as the product_name. This would result in a query that retrieves all products, regardless of their names, because the $ne operator in NoSQL means "not equal". This could potentially leak sensitive information.

Moreover, the attacker could also provide a string such as {$gt: ""}, which would result in a query that retrieves products whose names are greater than an empty string, effectively retrieving all products as well. This is just one of the many ways an attacker can manipulate the query through NoSQL injection.

Therefore, it is crucial to always validate and sanitize user inputs before using them in database queries to prevent NoSQL injection attacks.

Steps​

  • Sanitize and validate user inputs before using them in NoSQL queries.
  • Use parameterized queries or prepared statements to prevent NoSQL injection.
  • Avoid using user inputs directly in the query string.
  • Implement input validation to ensure that only expected values are accepted.
  • Implement proper error handling and logging to detect and respond to potential injection attempts.
  • Consider using an ORM (Object-Relational Mapping) framework like ActiveRecord in Ruby on Rails, which provides built-in protection against SQL and NoSQL injection.
  • Regularly update and patch the Ruby on Rails framework and its dependencies to benefit from the latest security fixes.
  • Educate developers about the risks of NoSQL injection and provide secure coding guidelines.

Compliant code​

def search_product
  product_name = params[:product_name]
  products = Product.where("name like ?", "%#{product_name}%")
  render json: products
end

The original code was vulnerable to NoSQL injection because it was using user input directly in a query without sanitizing or validating it. This could allow an attacker to manipulate the query, potentially leading to unauthorized data access or other security issues.

The fixed code uses a parameterized query to prevent NoSQL injection. This means that the user input is not used directly in the query string, but instead, it's used as a parameter in a prepared statement. This way, the database can distinguish between the query code and the data, preventing the data from being executed as code.

The "%" symbols added around product_name in the query are used to perform a LIKE search in SQL. This means that it will match any product name that contains the user input, not just product names that are exactly equal to the user input.

In addition to this, it's important to implement input validation to ensure that only expected values are accepted. This could be done using Ruby on Rails' built-in validation features.

Also, consider using an ORM (Object-Relational Mapping) framework like ActiveRecord in Ruby on Rails, which provides built-in protection against SQL and NoSQL injection.

Finally, make sure to regularly update and patch the Ruby on Rails framework and its dependencies to benefit from the latest security fixes, and educate developers about the risks of NoSQL injection and provide secure coding guidelines.

References​

Last updated on