Book Image

ASP.NET Core 5 Secure Coding Cookbook

By : Roman Canlas
Book Image

ASP.NET Core 5 Secure Coding Cookbook

By: Roman Canlas

Overview of this book

ASP.NET Core developers are often presented with security test results showing the vulnerabilities found in their web apps. While the report may provide some high-level fix suggestions, it does not specify the exact steps that you need to take to resolve or fix weaknesses discovered by these tests. In ASP.NET Secure Coding Cookbook, you’ll start by learning the fundamental concepts of secure coding and then gradually progress to identifying common web app vulnerabilities in code. As you progress, you’ll cover recipes for fixing security misconfigurations in ASP.NET Core web apps. The book further demonstrates how you can resolve different types of Cross-Site Scripting. A dedicated section also takes you through fixing miscellaneous vulnerabilities that are no longer in the OWASP Top 10 list. This book features a recipe-style format, with each recipe containing sample unsecure code that presents the problem and corresponding solutions to eliminate the security bug. You’ll be able to follow along with each step of the exercise and use the accompanying sample ASP.NET Core solution to practice writing secure code. By the end of this book, you’ll be able to identify unsecure code causing different security flaws in ASP.NET Core web apps and you’ll have gained hands-on experience in removing vulnerabilities and security defects from your code.
Table of Contents (15 chapters)

Fixing NoSQL injection

NoSQL databases are a different type of database in which non-relational and semi-structured data is stored. There are many kinds of NoSQL databases to name, such as Cassandra, Redis, DynamoDB, and MongoDB, each with its own query language. Although distinct from one another, these queries are also prone to injection attacks.

In this recipe, we will identify the NoSQL injection vulnerability in code that is using MongoDB as the backend and fix the problem by applying several countermeasures.

Getting ready

Using Visual Studio Code, open the sample Online Banking app folder at Chapter02\nosql-injection\before\OnlineBankingApp.

How to do it…

Let's take a look at the steps for this recipe:

  1. Launch Visual Studio Code and open the starting exercise folder by typing the following command:
    code .
  2. Navigate to Terminal | New Terminal in the menu or simply press Ctrl + Shift + ' in Visual Studio Code.
  3. Type the following command in the terminal to build the sample app to confirm that there are no compilation errors:
    dotnet build
  4. Open the Services/PayeeService.cs file and locate the vulnerable part of the code in the Get(string name) method:
    public List<Payee> Get(string name) {
        var filter = "{$where: \"function()         {return this.Name == '" + name + "'}\"}";
        return payees.Find(filter).ToList();
    }
  5. To remediate the NoSQL injection vulnerability, change the preceding highlighted code:
    public List<Payee> Get(string name) {
        return payees.Find(payee => payee.Name ==         name).ToList();
    }  

The filter passed into the Find method is now replaced with a Lambda expression, a much more secure way of searching for a payee by name.

How it works…

The Get method has a string parameter that can be supplied with a non-sanitized or validated value. This value can alter the MongoDB filter composed with it, making the NoSQL database perform an unintended behavior.

The name parameter can be appended with an expression that would evaluate the query into a logical result different from what the query was expected to perform. A JavaScript clause can also be inserted into a query that can terminate the statement and add a new block of arbitrary code.

By way of some general advice, avoid using the $where operator. Simply apply a C# Lambda expression as a filter to prevent any injectable JSON or JavaScript expression.

There's more…

Suppose the preceding options are not possible and it is necessary to use the $where clause, you must then JavaScript-encode the input. Use the JavaScriptEncoder class from the System.Text.Encodings.Web namespace to encode the value being passed into the parameter:

  1. First, modify the PayeeService.cs file to add a reference to the Encoder namespace:
    using System.Text.Encodings.Web;
  2. Next, define a property for JavaScriptEncoder:
    private readonly JavaScriptEncoder _jsEncoder;
  3. Change the PayeeService constructor and add a new parameter to inject JavaScriptEncoder:
    public PayeeService(IOnlineBankDatabaseSettings settings,JavaScriptEncoder jsEncoder)
  4. Lastly, encode the name parameter using the Encode function of JavaScriptEncoder:
    var filter = "{$where: \"function() {return this.Name == '" + _jsEncoder.Encode(name) + "'}\"}";

If a malicious input was passed into the name parameter and was escaped by the Encode method, the C# MongoDB driver will throw an exception if the escaped value could not be interpreted as a valid JavaScript expression.

To prevent NoSQL injections, developers must avoid building dynamic queries using string concatenation. NoSQL databases offer ways to query and process data, but you must be aware of potential security implications a feature might bring into the ASP.NET Core web application.