Determine correctness

Determining correctness means verifying data is well-formed. This is the opposite of determining incorrectness. Determining that data is incorrect is a good backup strategy, but it’s not a replacement for validating that data is correct, because no one can know all the potential ways to malform incoming data.

“Don’t look for bad things.” Doing so assumes you know all the bad things, and no one does. Instead, validate for correct and well-formed data. That way, your code always fails secure, sometimes called failing closed. Stop and think for a moment: if a user provides valid input but it’s not seen as valid by your code, at worst you have a support ticket to deal with.

There are many strategies to constrain data to its correct form. Most programming languages offer library functions or methods that perform basic constraint checking. You can use regular expressions, too, but they should be reserved for more complex data formats or when alternate methods don’t work correctly.

Let’s return to the vaccination booking application as an example. Suppose the file uploaded by the vaccination center is a simple text comma-separated value (CSV) file with the following fields:

Click here to view code image

centerId, date and time, vaccination type, open spots, comment

It’s simple. The formats for each data item are as follows:

• centerID This is the vaccination center ID. It is a six-digit number. This field cannot be blank.

• date and time For this, you use the ISO 8601 date and time format. This field cannot be blank.

• vaccination type This is a string that represents the name of a valid vaccine manufacturer. This field cannot be blank.

• open spots This is a number from 0 to 999. This field can be blank; when it is, it equates to zero.

• comment This is a text field in which a representative from the vaccination center can enter a comment. This comment can be up to 200 characters long.

The CSV file will have one line for each vaccination center, date and time, and vaccine type. The file is uploaded to an Azure Storage account, and from there it is read by an Azure Function. With this in mind, you can build some code that checks that the data is correctly formed. There is more than one way of doing it, so we’ll show a few examples.

When checking validity, you want to be as performant as possible. Regular expressions (regex) are a common way to validate data, but simple data formats do not require a regex, and other options are faster and good enough.

Before you validate each item in each line of the CSV file, you need to make sure each line contains the correct number of fields. This is simple. You just split the line based on the delimiter. If the file is JSON or XML, you could also make sure it’s valid JSON or XML. You could also validate against a schema.

The following C# code checks that a line of the CSV file is five fields and only five fields. Anything other than five is incorrect data.

Click here to view code image

C#
if (line.Split(",").Length == NUM_FIELDS) {
           // Correct number of fields
}

JavaScript

Click here to view code image

if (line.split(",").length == NUM_FIELDS) {
           // Correct number of fields
}

C++ does not support a split() method. If you use the Boost C++ library (https://www.boost.org/), you could use boost::split. Failing that you must write your own method:

Click here to view code image

C++
#include <vector>
#include <string>

using namespace std;

auto split(const string &str, const string &delim) {
          vector<string> vs;
          size_t pos = 0;

          for (size_t i = 0; (i = str.find(delim, pos)) != string::npos; pos = i + delim.size())
                    vs.emplace_back(str.data() + pos, str.data() + i);

          vs.emplace_back(str.data() + pos, str.data() + str.size());
          return vs;
}

vector<string> v = split(line, ",");
if (v.size() == NUM_FIELDS) {
          // Correct # items
}

Click here to view code image

Go
import (
          "strings"
)
res := len(strings.Split(line, ","))
if res == NUM_FIELDS {
          // Correct # items
}

Python
if len(line.split(",")) == NUM_FIELDS:
    # Correct # items


PowerShell
if ($line.Split(",").Count -eq NUM_FIELDS) {
    # Correct # items
}

Java
if (line.split(",").length == NUM_FIELDS) {
          # Correct # items
}

if (UInt32.TryParse(id, out val) == true) {
           // Is an unsigned int
           if (val >= 0 && val <= 999999) {
                     // correct
   }
}

C#
var re = new Regex(@"^d{6}$");
if (re.IsMatch(id)) {
          // Is exactly six digits
}

JavaScript
const re = /^d{6}$/;
if (id.match(re) != null) {
          // Is exactly six digits
}

Java
try {
    int num = Integer.parseInt(id);
    if (num >= 0 && num <= 999999) {
        // valid
           } else {
               // Invalid
    }
} catch (java.lang.NumberFormatException ex) {
               // Invalid
}

2022-02-23T03:08:00-06:00

YYYY-MM-ddThh:mm:ss[+/-]hh:mm

C#
if (DateTime.TryParse(dt, out dt2) == true) {
    // Valid datetime
}

^(-?(?:[1-9][0-9]*)?[0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5]
[0-9]):([0-5][0-9])(.[0-9]+)?(Z|[+-](?:2[0-3]|[01][0-9]):[0-5][0-9])?$

PowerShell
[datetime]::Parse($date)

Java
try {
    DateTimeFormatter formatter = DateTimeFormatter.ISO_OFFSET_DATE_TIME;
    var odt = LocalDate.parse(dt, formatter);
} catch (java.time.format.DateTimeParseException ex) {
    // Not valid
}

C#
string[] validPharam = { "PharmaA", "PharmaB", "PharmaC" };
bool valid = validPharam.Any(x => x.Contains(pharma, StringComparison.OrdinalIgnoreCase));

JavaScript
var validPharma = ["PharmaA","PharmaB","PharmaC"];
var valid = validPharma.find((str) => str === pharma);
if (valid != undefined) {
          // pharma is valid
}

Go
func Contains(s []string, e string) bool {
          for _, v := range s {
                    if v == e {
                              return true
                    }
          }
          return false
}

arrPharma := []string{"PharmaA", "PharmaB", "PharmaC"}
if Contains(arrPharma, pharma) == true {
          // pharma is valid
}

C#
public bool IntegerRangeCheck(string input, out uint result, uint min, uint max) {
  return uint.TryParse(input, out result) && (result >= min && result <= max);
}

Go
re, _ := regexp.Compile(`^d{1,3}$`)
if (len(re.FindString(dt)) > 0) {
          // 000–999
}

Python
val = int(line)
if val >=0 and val <= 999:
    # valid

Validating the comment field, including international characters

This can be tricky, because a comment field is an area for text, but that text might include characters other than a–zA-Z0–9. For example, a comment might say, “This will be administered by Dr. Françoise d'Aubigné.” Note the cedilla and acute accents under the c and over the e, respectively. Neither of these are in the range a–zA–Z, so you need to be mindful of this.

Because you don’t trust the data, you need to make sure the data is well-formed. First, you need to define which subset of characters can go in the comment field. As noted, a–zA–Z does not represent all possible characters in other languages—for example, French, Spanish, Greek, and obviously many more. Thankfully, many modern regex’s support international characters using a p escape. The following is a sample testbed written in Rust:

Click here to view code image

use regex::Regex;
use lazy_static::lazy_static;

fn is_valid_comment(comment: &str) -> bool {
    if comment.len() > 200 {
         return false;
    }
    lazy_static! {
        static ref RE: Regex = Regex::new(r"^[p{Letter}p{Number}p{Other_Punctuation}s]+$").
unwrap();
    }
    RE.is_match(comment)
}
fn main() {
    let comments =
        vec!["باتكلا اذه نم ريثكلا تملعت.",           // Arabic
             "我从这本书中学到了很多东西。",                // Chinese
             "Jeg lærte meget af denne bog.",          // Danish
             "He nui aku ako mai i tēnei pukapuka.",           // Māori
             "私はこの本から多くのことを学びました。",               // Japanese
             "I learned a lot from this book.",                // English
             "למדתי הרבה מהספר הזה.",                          // Hebrew
             "ከዚህ መጽሐፍ ብዙ ተምሬያለሁ ።",                          // Amharic
             "This won't <script> work!"];

   for comment in comments.iter() {
       if is_valid_comment(comment) {
           println!("Valid: {}", comment);
       } else {
           println!("Invalid: {}", comment);
       }
   }
}

This code iterates through various languages and succeeds on each except the last because it includes characters that are not in the list of allowed characters.

Note

Remember, we’re looking for “goodness” as our main defense against potentially malicious input, not “badness.”

Breaking the regex down, you have the following:

• ^ The start of the string.

• [ The start of a set of characters.

• p{Letter} Any Unicode letter, uppercase or lowercase—not just a–z or A–Z. Note that p{L} is also valid.

• p{Number} Any Unicode number, not just 0–9. Note that p{N} is also valid.

• p{Other_Punctuation} Various punctuation, including ¿ and ¡ in Spanish. Note that p{Op} is also valid.

• s A space.

• ] The end of a set of characters.

• + One or more.

• $ The end of the string.

In this example, you cannot use p{Punctuation}, because it includes the < and > punctuation marks. These are used in HTML and can be employed in a cross-site scripting (XSS) attack. Also, the + in the regex could be replaced with other length constraints.

There’s one important caveat: some languages don’t natively include a regex library that can handle Unicode, and some languages don’t support the long names for the character classes. For example, .NET supports p{L} but not p{Letter}.

For JavaScript, including Node.js, you need to use the u qualifier as part of the regex. The following short test code shows this in action. The first regex works, but the second returns null because it does not have a u qualifier.

Click here to view code image

let str = "Έμαθα πολλά από αυτό το βιβλίο.";
console.log(str.match(/p{L}/gu) );
console.log(str.match(/p{L}/g) );

Tip

For a good overview of Unicode strings in regular expressions, see https://azsec.tech/5tq.

Before we move on to the next section, we have to confess something: there is a bug in the code! We left it until now, mainly to show how easy it is to make simple mistakes. The problem is that the comment field is freeform with some restrictions. So, you can add commas to the comment field, but this would make the code that checks for fieldcount==5 wrong.

To fix this, you could always strip out commas from the comment field. But this is dangerous because it can lead to the “commas save lives” problem—that is, there is a big difference between “Let’s eat, Grandma” and “Let’s eat Grandma.” Alternatively, you could escape all commas in the comment field with the HTML-escaped version, &#39. So, a sentence like, “Let’s eat, Grandma” becomes “Let’s eat' Grandma.” It’s ugly, but it’s safe. Honestly, all this shows the fragility of CSV files. It might be better to use a JSON representation of the data.

Reject known bad data

Restricting to only known data is always the right strategy when verifying incoming data. However, some developers go one step further and add another defensive layer that checks for known illegal data. For example, let’s say your code expects a filename in an argument, like in the following Python code:

Click here to view code image

import re
def is_filename_valid(filename):
    valid = re.match("^.+.(?i)(jpg|png|gif|bmp|tiff)$",filename)
    return (valid != None)

This is a simple regex that also happens to be too loose and vulnerable. This will allow filenames like the following:

• diving-the-uss-vandenberg.jpg

• picsofdogs.bmp

• CatsBehavingBadly.png

This seems fine. However, the regex will also allow the following:

• ....docs axreturn2022.jpg

• /home/blake/docs/mysecretinvention.doc

• c:secretpics icoles-taxreturn2022.jpg

Oops!

One thing you could do is add another regex that looks for bad things to reject anything you might have missed in the first regex. For example:

Click here to view code image

def is_filename_valid(filename):
    valid = re.match("^.+.(?i)(jpg|png|gif|bmp|tiff)$",filename)
    bad = re.match("[:\/]+",filename)
    return (valid != None and bad == None)

This regex looks for bad things—most notably colon, slash, and backslash characters.

The real fix, though, is to create a more restrictive regex, like this one:

Click here to view code image

import re
def is_filename_valid(filename):
    valid = re.match("^(?i)[a-z0-9]{1,24}.(?i)(jpg|png|gif|bmp|tiff)$").,filename)
    return (valid != None)

This regex is correct. However, there’s no harm in taking a “the regex might not be right” view and adding a list of known bad characters in a filename—again, colon, slash, and backslash characters.

Regular expressions are a great way to validate data, but they have a dark side: adding them can make your code vulnerable! This is because some classes of regex are subject to a regex denial of service (ReDoS). For more information about ReDoS, read this write-up on the issue published by OWASP here: https://azsec.tech/z5y. Much of the earliest work on this topic was done by Bryan Sullivan at Microsoft.

Also, a regex can take up quite a bit of memory. It might look like a small string, but under the hood the regex code builds a state machine that can get complex and occupy large amounts of memory. This increased memory consumption is especially true for certain regex constructs. For example, the + (one-or-more) qualifier will create a smaller state machine than a {1,200} (between 1 and 200 characters inclusive) qualifier.

The following Rust code will fail ton run:

Click here to view code image

static ref RE: Regex = Regex::new(r"^[p{Letter}p{Number}p{Other_Punctuation}s]{1,200}}$").
unwrap();

The error is

Click here to view code image

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
CompiledTooBig(10485760)', srcmain.rs:102:103

But the regex runs correctly if you switch out {1,200} with +. Why? As noted, the state machine for {1,200} is considerably more complex than a simple + and consumes more memory. By default, Rust will allow only a maximum 1 MB state machine, but this state machine weighs in at 22 MB!

In Rust, you can change the default memory limit by using code like this:

Click here to view code image

use regex::RegexBuilder;
let re = RegexBuilder::new(r"^[p{Letter}p{Number}}p{Other_Punctuation}s]{1,200}$")
         .size_limit(22 * 1024 * 1024)            // 22MB
         .build()
         .unwrap();

You can experiment with this code at the Rust Playground, located here: https://azsec.tech/y6i. Run the code, remove the .size_limit() method, and rerun.

The next issue is performance. To improve performance, don’t put a regular expression definition in a loop or in a function that is heavily used. As mentioned, constructing the state machine takes time. That’s why the sample Rust code uses a lazy static, so the regex is compiled on the first call and then referenced from then on. You could also create your regexes once using a class construction.

One important final note about regular expressions: never use untrusted input as part of a regular expression string. In other words, the attacker should never control any part of the regex string.

Encode data

This is mostly for data that is echoed back to a user’s browser. Even after encoding all the incoming data, it is beneficial and safer to clean up the data before it is sent back to a browser. This is mostly true of any data that comes from an untrusted source. The goal of this is to render potential HTML and scripting useless, primarily to mitigate XSS issues.

If you have any data that comes from a potentially untrusted source and is then echoed back in a browser, this data must be encoded before it is echoed back. The most well-known way to achieve this is to simply HTML-encode all output. Some frameworks—for example, ASP.NET MVC and Razor—do this automatically. For others, you might need to call a function that takes the data, encodes it, and then renders it in the browser.

The following C# code snippet demonstrates this:

Click here to view code image

using System.Text.Encodings.Web;
using System.Text.Unicode;
string bad = @"<script>alert(1);</script>";
var encoder = HtmlEncoder.Create(allowedRanges: new[] { UnicodeRanges.BasicLatin });
Console.WriteLine(encoder.Encode(bad));

Recall the comment field example from earlier in the chapter. Processing text entered in this field involves the following steps:

1. A user enters a comment.

2. The server accepts the input and runs it through a regex to make sure the comment is well-formed. If it is not correct, the comment is rejected. If the format is correct, the comment is written to a Cosmos DB database.

3. When another user scrolls through comments, each comment is read from Cosmos DB.

4. Each comment is passed through an HTML function.

5. The result of HTML encoding is rendered in the user’s browser.

A01: Broken access control

Further information https://azsec.tech/kgp

As we stress in Chapter 5, access control is critical. In Azure, this usually means using role-based access control (RBAC), although some services support attribute-based access control (ABAC). Some services in Azure, such as storage accounts, also support shared access signature (SAS) tokens, which are used to allow access to a process or user that has the token. A SAS token can include access requirements such as Read, Write, and Delete.

In Azure, implementing access control also means having a limited set of users with elevated roles, such as Owner and Contributor, but also extending to service-specific roles such as Storage Account Contributor. Accounts with these roles can often read and configure services but not change access policies.

A02: Cryptographic failures

Further information https://azsec.tech/q8v

In part, this covers encryption of data at rest and in motion, or “on the wire.” For data at rest, this means lack of cryptographic defenses or poor implementation, such as not encrypting a sensitive column in SQL Server. For data in motion, this usually means not using a secure protocol such as TLS 1.2.

Many of these can be enforced using Azure Policy, as discussed in Chapter 7, “Governance.” For example, the sample found at https://azsec.tech/t0x enforces HTTPS (HTTP over TLS) for Azure Storage accounts. One level lower, this can include using insecure cipher suites in TLS (such as TLS_RSA_WITH_3DES_EDE_CBC_SHA) or insecure cryptographic algorithms (such as RC4, DES, 3DES, MD5).

Other examples of cryptographic failure include the following:

• Poor key generation, such as using a deterministic random number generator

• Poor key derivation, such as using a password directly as a cryptographic key

• Using “custom” cryptographic algorithms rather than industry-standard reviewed algorithms

• Encrypting data but not providing tamper-detection, too

• Reuse of initialization vectors (IVs)

A03: Injection

Further information https://azsec.tech/u90

Examples of injection include SQL injection (SQLi) and cross-site scripting. One way to resolve this collection of issues is by verifying input and encoding output. Another is to use technologies that have specific defenses to mitigate injection. For example, SQL has parameterized queries to neuter variables used as part of the query. The following C# code uses the SQLParameter class to build a dynamic SQL query safely:

Click here to view code image

SqlDataAdapter myCommand = new SqlDataAdapter(
"SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);
SQLParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",
                        SqlDbType.VarChar, 11);
Parm.Value = idAuthor;

Also, many application frameworks and constructs automatically create SQL statements from text. For example, in C# LINQ to SQL is designed to create secured SQL queries. You can learn more here: https://azsec.tech/5mh.

Azure Logic Apps are subject to SQLi, as explained here: https://azsec.tech/hzj. The same goes for Cosmos DB when using the SQL client, discussed here: https://azsec.tech/uwi. Microsoft Defender for SQL offers SQL Advanced Threat Protection to detect attempted SQLi attacks in near real time. You can learn more here: https://azsec.tech/p0g.

As mentioned, XSS is another example of injection. The core problem with XSS is accepting untrusted input—which could include HTML or scripts—and then using it as HTML output. The fix is simple: validate incoming data, and HTML encode outgoing data using methods like .NET’s HttpUtility.HtmlEncode(). This combination of input and output logic is often called filter input, escape output (FIEO).

A04: Insecure design

Further information https://azsec.tech/4i6

This is mitigated with threat modeling. The whole point of threat modeling is to understand a solution’s design and what defenses are used to protect that system. If security issues are found during the threat-modeling process, these issues can be resolved, which leads to a more secure design.

A05: Security misconfiguration

Further information https://azsec.tech/ng0

This is incredibly common. People deploy a secure configuration, but over time, small changes creep in, and services slowly drift away from the original secure defaults. This is why you use governance services in Azure such as Azure Policy: to restrict this drift and to prevent new services from deploying with insecure defaults.

One of the most common issues we have seen is virtual machines (VMs) with public IP addresses. VMs should be behind a load balancer or a bastion service such as Azure Bastion. But we’ve been in more than one conversation with customers whose VMs have an RDP or SSH port open directly to the internet. This is a bad idea.

Misconfiguration often extends to how you configure various services. A classic and common error is failing to add security-related headers to HTTP servers. Any HTTP server should set the following headers, whether you’re using an Apache server in a Linux VM or an App Service. These headers instruct the browser how to enforce specific security rules. The current list of common, security-related HTTP headers is as follows:

• Content-Security-Policy

• Referrer-Policy

• Strict-Transport-Security

• X-Content-Type-Options

• X-Frame-Options

• X-XSS-Protection

• Access-Control-Allow-Origin (cross-origin resource sharing [CORS])

This list is dynamic. Over the years, new headers have been added or updated. The Security Headers site (https://securityheaders.com/) has an excellent analysis of the various headers and what they should be set to, as does the Mozilla Developer Network (https://azsec.tech/ggb).

For Azure App services (for example, the service that runs https://azsecuritypodcast.net), you can update web.config. The following code is the web.config file used by the Azure Security Podcast:

Click here to view code image

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
     <system.webServer>
        <httpProtocol>
            <customHeaders>
                <clear />
                <add name="Content-Security-Policy" value="default-src 'self' *.rss.com; script-
src 'self' https://ajax.aspnetcdn.com "/>
                <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
                <add name="Strict-Transport-Security" value="max-age=63072000" />
                <add name="X-Content-Type-Options" value="nosniff" />
                <add name="X-Frame-Options" value="ALLOW-FROM https://player.rss.com" />
                <add name="X-XSS-Protection" value="1; mode=block" />
                <add name="Access-Control-Allow-Origin" value="https://player.rss.com https://
apollo.rss.com" />
                            <add name="Cache-Control" value="max-age=31536000" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

The Content-Security-Policy (CSP) header is complex and powerful, and having a good understanding of how it works is critical. Notice that the preceding sample contains references to *.rss.com. This is a media player implemented using HTML that allows a user to play an episode in the browser. If the various headers did not allow *.rss.com, the media player would not render, because the HTML is fetched from another site. Also, notice that script-src references ajax.aspnetcdn.com, which allows the browser to pull in jQuery from outside the core website. Again, without this, jQuery would not load when using CSP.

Finally—and this is important—these headers will often cause a site to incorrectly render, so you might need to change your site’s code or tweak the headers. One good example is using inline code or styles to help you wrangle Content-Security-Policy. You should move inline code and styles to a separate file and reference it at the start of your HTML files.

You can use a tool like the one at https://report-uri.com/home/generate to help you build a policy string. For an Azure static website, you can add a new file in the root folder named staticwebapps.config.json like so:

Click here to view code image

{
      "globalHeaders": {
        "content-security-policy": "default-src 'self'",
        "Referrer-Policy":"no-referrer",
        "Strict-Transport-Security": "max-age=63072000",
        "X-Frame-Options": "SAMEORIGIN",
        "X-Permitted-Cross-Domain-Policies": "none",
        "X-Content-Type-Options": "nosniff"
    }
}

Other web servers and environments have their own header configuration files. For example, in Apache (running in a VM), you can edit httpd.conf to add this at the end of the file:

Click here to view code image

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set Content-Security-Policy "default-src 'self'"
  Header always set Referrer-Policy "no-referrer"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Frame-Options "DENY"
  Header always set X-XSS-Protection "1; mode=block"
</IfModule>

There is one other new header: Permissions-Policy. It replaces Feature-Policy. You can learn more about it here: https://www.permissionspolicy.com/. To check if the browsers your applications support can handle the header, you can use the Can I Use site, located here: https://caniuse.com/?search=Permissions-Policy. The Azure Security Podcast site does not set this header on purpose. When it becomes more popular, we will enable it in the site.

Notice there is nothing to remove the Server: header, which announces the web server type and version number. Removing or replacing this header is of no real security value; it is just security theater, because a somewhat-knowledgeable attacker can easily “fingerprint” the server to determine its type and version.

On a related note, the Access-Control-Allow-Origin header, which is used to support cross-origin resource sharing, does not improve security. In fact, it reduces security somewhat by allowing a controlled weakening of the browser same-origin security policy. The reason CORS exists is to have a preferred way to send HTTP requests across websites without resorting to some disastrous work-arounds used in the past. CORS allows for some more secure OAuth2 flows. Some services in Azure support CORS—for example, Azure Functions, as shown in Figure 9-5.

Even though the screenshot shown in Figure 9-5 mentions using * as a wildcard, you should not allow all domains to access your Function App. Allow only required domains to interact with your Function app. Also, as shown in Figure 9-6, Microsoft Defender for Cloud warns against setting CORS to *.

Contrary to popular belief, the HTTP Strict-Transport-Security (HSTS) heading does not force all HTTP connections to HTTPS. HSTS requires one validated HTTPS connection to the server (that is, with no certificate errors) before the browser will honor the HSTS header. The reason is because an attacker can manipulate an HTTP body, including headers, making the HSTS setting untrustworthy in an HTTP response. However, HSTS also maintains a preload database of known sites that require HTTPS. To add your site to the list, go to the HSTS Preload Submission site at https://hstspreload.org/.

Another header type, cookies, should set the following flags:

• HttpOnly

• Secure

• Expires

• SameSite

HttpOnly helps mitigate XSS attacks from stealing cookie content. While you should certainly set cookies to use this option, be aware that it has value only if the cookie is used for authentication purposes, and it’s not a great defense against some forms of XSS. However, using cookies for session state and client configuration access is better than using HTML storage. You can read more on this here: https://azsec.tech/bpw. You should also mark cookies with the Secure flag so they are passed between the browser and server only when using HTTPS (HTTP over TLS).

Cookies should be set to expire using the Expires flag. The duration is up to you and depends on your business requirements because you need to balance security with usability. We have seen many developers set this flag to between one and six months.

SameSite provides some protection against client-side request forgery attacks by restricting when cookies are sent. If you set the SameSite=Strict flag on a cookie, then a browser sends cookies only for first-party context requests. These are requests originating from the site that set the cookie. If the request originated from a different URL than that of the current location, none of the cookies tagged with the Strict attribute is sent. You can read more about the flag at https://azsec.tech/bux to determine what cookie SameSite attribute works best for your sites. Here is an example cookie with these flags set:

Click here to view code image

Set-Cookie: sessionid=c92620e1; HttpOnly; Secure; SameSite=Strict; Expires=Fri, 1 Jul 2022
00:00:00 GMT

A06: Vulnerable and outdated components

Further information https://azsec.tech/it1

Many applications are built with other components such as libraries. These components might not be controlled by you, so if they contain vulnerabilities, you will need to update your solutions with new solutions.

It is incredibly important to maintain a software bill of materials (SBOM) that tracks all the components that comprise your applications. This includes the following:

• Component or package name

• Version number

• Vendor or source code repository

• Programming language

• Location of security information about that component

GitHub has a tool called Dependabot to help you identify third-party packages you use that are out of date and have security issues. You can learn more here: https://azsec.tech/hud. This tool is just one part of GitHub’s security supply chain initiative and is discussed in further detail at https://azsec.tech/m0q.

A07: Identification and authentication failures

Further information https://azsec.tech/f3u

In the world of cloud-based solutions, identity is critical. Still, network boundaries are important—especially when it comes to the need for network segmentation in a zero-trust environment. A core part of identity is strong authentication. This is also a core element of your threat models. All processes must be authenticated, as well as devices and users.

Interestingly, the OWASP documentation calls out CWE-297, “Improper Validation of Certificate with Host Mismatch.” We see this error often, but it extends beyond host name validation. If your code initiates a connection over TLS, it’s important that the code performs all the relevant certificate checks. These include the following:

• The certificate’s signature is valid. This verifies that it is not tampered with.

• The name in the certificate matches the name of the system or user you want to communicate with.

• The certificate chains up to a trusted root CA certificate. This is a critical step to prove the certificate is trusted.

• The extended key usage is correct—for example, server authentication.

• The date range is valid. That is, today is between the NotBefore and NotAfter fields.

• Whether the certificate is revoked. There are two common ways to check if a certificate is revoked. The first is to use a certificate revocation list (CRL). The location of the CRL is held in the certificate using a CRL distribution point (CDP), which is just a URL. The other way to check if a certificate is revoked is to use the Online Certificate Status Protocol (OCSP).

You will probably never write code to perform these steps. Instead, you should leave the validation to the libraries you use. For example, in .NET, the SslStream() class calls a delegate that can perform actions based on errors validating a certificate. Unfortunately, we see code like this quite often:

Click here to view code image

// This is invoked by the SslStream(..,..RemoteCertificateValidationDelegate, ..)
public static bool ValidateServerCertificate(
       object sender,
       X509Certificate certificate,
       X509Chain chain,
       SslPolicyErrors sslPolicyErrors) {
     // Ignore all certificate errors
    return true;
}

This code ignores certificate errors and is a serious security vulnerability.

On the topic of certificates, be careful with self-signed certificates. If you must use self-signed certificates, check the certificate’s signature and thumbprint against a list of predetermined valid certificates. The list must have a strong access policy so it cannot be changed by untrusted entities.

Even then, be careful. Some people use self-signed certificates in test and use “real” CA-issued certificates in production. The problem with this is the test environment does not perform the same certificate tests as would be performed in production. The best way around this is to set up a certificate authority yourself—for example, using Active Directory Certificate Services (AD CS). You can install the root CA certificate from this CA on your development and test machines and test end-to-end certificate-based authentication including revocation. And because you control the certificates, you can create certificates that are invalid to see how your code reacts to, say, an expired server certificate or one where key usage is for client authentication when you expect server authentication.

A08: Software and data integrity failures

Further information https://azsec.tech/0kv

The issue here is code or data being compromised and changed. If you download code that is not digitally signed or you do not verify an out-of-band hash, there’s no way to know if the code or data is valid. In fact, looking at our vaccination booking example, the data really should be digitally signed by the vaccination center, so we know for certain it’s from the correct one.

You can create a digital signature quite easily as long as you have a certificate that has key usage for digital signatures and the associated private key. In Windows, these certificates are often referred to as Authenticode certificates.

Not only does PowerShell support signing, but it can also be configured to only allow digitally signed PowerShell files to run—for example, using cmdlets such as Set-AuthenticodeSignature to sign PowerShell files. You can see the result in the following code. The signature size is relatively constant, so it seems large compared to one line of script, but for a large script, the signature would be about the same size as for one line of script.

Click here to view code image

"Hello, World!"

# SIG # Begin signature block
# MIIFkQYJKoZIhvcNAQcCoIIFgjCCBX4CAQExCzAJBgUrDgMCGgUAMGkGCisGAQQB
-- SNIP --
# 1vbbaAkllAAg9aDVb6EXPY+AIKr5UYJli8WhCfVbWo+qV1EeWUXKlJEEDOTTaH3K
# mvZISeSM+yS+yN+hz6hNPxdy3S6QuWhjrFleL5hj1p2+OO8RAA==
# SIG # End signature block

Key Vault can perform signing operations within Key Vault, and the keys can be in hardware if you use an RSA-HSM or ECC-HSM key. The following simple C# test code demonstrates how to sign arbitrary data. This sample creates a signature by signing the SHA-512 hash using a P-521 elliptic curve.

Click here to view code image

using Azure.Identity;
using Azure.Security.KeyVault.Keys.Cryptography;
using System.Security.Cryptography;
using System.Text;

// You should pull the hash alg from a config file
string HASH_ALG = "SHA512";
SignatureAlgorithm SIG_ALG = SignatureAlgorithm.ES512; // P-521 Curve
var keyVaultUrl = "https://mykv.vault.azure.net/keys/key-name/version";

var creds = new DefaultAzureCredential(true);
var keyCryptoClient = new CryptographyClient(new Uri(keyVaultUrl), creds);

var msg = Encoding.UTF8.GetBytes("A message we want to sign");
var digest = HashAlgorithm.Create(HASH_ALG)?.ComputeHash(msg);

SignResult sig;
if (digest is not null) {
    sig = keyCryptoClient.Sign(SIG_ALG, digest);
    Console.WriteLine(Convert.ToBase64String(sig.Signature));
}

This code emits a Base64-encoded signature block, which could travel with the text file or separately. For example, you could do something like this:

Click here to view code image

A message we want to sign
--SIG—
AALaNsWvS9atK8xl4BqsqEdps0+IykG7bxwKXXZhyJ6zR/
rAKtYTTgpMvqqO1VyX6wEwFrwGTRb7Sl9kJeiPALmHAQ6BB6jeT/YnrRQHzBKqpoaMy9zRCWC/oDUW+ufAUnIOVsBM5WttcY
Zuj0JcEAjraGwB6eQWoc9cK23O1iM/DKNT
--ENDSIG--

You could then do the reverse operation: signature verification using CryptographyClient.Verify(). There is a twist, though: you probably won’t pull the public key from Key Vault. Instead, you’ll use the public key in a certificate so you can perform all the correct certificate checks mentioned earlier. This will not only verify the certificate, but it will also check that the data came from the name in the certificate. For example, if the certificate has a field [email protected], then you know the data came from Joe. You could also use something like XMLDSig or JSON web signature to sign and verify data, so you don’t need to do the low-level work.

Remember, this section is all about integrity and authenticity. There is no encryption. It is common to do both, however. Our vaccination file could append the signature to the CSV file. The data is not encrypted, but we still have integrity and authentication due to the digital signatures, as long as your code performs all the relevant certificate checks before verifying the signature.

If a service needs to verify data, it can also use a message authentication code (MAC), which uses a symmetric key rather than public/private key pair. This would require any services to have access to the MAC key. This is why systems that use a MAC are usually one-to-one rather than one-to-many: to keep the MAC key distribution as small as possible. For example, TLS uses a unique MAC key for client-to-server communication, and a different MAC key for server-to-client communication.

What about using a hash? You can use a hash so long as:

• The hash is not included with the data to be verified.

• The hash is available over an authenticated and protected channel—for example, using TLS.

The hash cannot travel with the data because the data could be tampered with and the hash recalculated.

A09: Security logging and monitoring failures

Further information https://azsec.tech/4oa

This topic is covered in detail in Chapter 6.

A10: Server-side request forgery (SSRF)

Further information https://azsec.tech/3pn

Once again, this is an input trust issue. The core lesson here is to never allow an attacker to control a URL. If you must have a user control the URL, then have a list of valid URLs to validate against and only allow those URLs.

SSRF-based attacks are common against cloud-based solutions. It is believed the 2019 Capital One breach that yielded more than 100-million customer records was an SSRF attack against the company’s AWS infrastructure. You can read about the Capital One attack here: https://ejj.io/blog/capital-one.

The problem is incredibly simple:

1. A vulnerable server accepts a URL from an untrusted source (an attacker).

2. The server does not verify the URL is valid and correctly formed.

3. The server accesses the data at that URL.

4. The server returns the object at that URL back to the attacker.

The problem is if the web server has access to internal resources and the URL (that came from the attacker) points to a resource on the internal network, the attacker can start reading resources on the internal network! An example of an internal resource that is common to cloud platforms is the Instance Metadata Service (https://azsec.tech/meta), which, on Azure, is accessible on a nonroutable IP address, 169.254.169.254.

Another attack, cross-site request forgery (CSRF), sounds like SSRF, but the two are not the same. In fact, CSRF was on the OWASP Top 10 back in 2017, but it’s not now, mainly because most web frameworks offer defenses, such as ASP.NET MVC. You can read more here: https://azsec.tech/0py. The remedy for CSRF is to include a random token in the session, but this is always best handled by the various web frameworks.

Don’t write glorified C

C is a low-level language designed as a replacement for assembly language. The lineage of many modern programming languages originates in C.

C is small, is efficient, and has unfettered access to process memory. It is this last point that also makes C a language that requires care. The documentation for the original commercial C compiler from Whitesmiths, Ltd., in 1982 said, “C is too expressive a language to be used without discipline.” (A copy of this manual is available at https://azsec.tech/7c2; the quote is on page 22.)

C++ offers numerous quality, security, and robustness benefits over C. But you must use these features to obtain these benefits. You might have noticed that the sample C++ code we wrote, while simple, uses C++ idioms, has no direct pointer use, and passes large function arguments by reference. Honestly, it might have been easier in some examples to use low-level C, but using Modern C++ (https://azsec.tech/ko3) and the C++ Standard Library (STL; https://azsec.tech/odj) makes the code safer by far.

Use compiler and linker defenses

The two most popular C and C++ compilers are Microsoft Visual C++ and GNU gcc. Both provide extensive options to emit safer code that includes various defenses against memory corruption vulnerabilities.

For Visual C++, the following is a list of commonly used compiler and linker options and links to resources for more information. Some are enabled by default for C++ projects.

• /SDL This supports enhanced security checks, including enhanced stack-corruption detection (https://azsec.tech/azk).

• /DYNAMICBASE This uses address space layout randomization (ASLR) to randomly rebase the application at load time (https://azsec.tech/1s3).

• /NXCOMPAT This indicates that the application supports No eXecute (NX), also known as Data Execution Prevention (DEP) (https://azsec.tech/3nt).

• /SAFESEH This emits code that has a set of safe exception handlers (https://azsec.tech/18y).

• /GUARD This enables Control Flow Guard (https://azsec.tech/c5y) and Exception Handler Continuation Metadata (https://azsec.tech/o1p).

• /CETCOMPAT Opt in for hardware-enforced stack protection (https://azsec.tech/s1s and technical write-up at https://azsec.tech/i17).

• /fsanitize=address This is a way to find security issues, mainly memory safety issues, at compile time, and to prevent security issues at runtime. It can be treated as a replacement for /RTC (runtime checks) and /analyze (static analysis) (https://azsec.tech/vom).

For gcc, the following is a commonly used set of options that should be employed:

• _FORTIFY_SOURCE This a macro (for example, gcc -D_FORTIFY_SOURCE=2), not a compiler or linker flag, that performs checks for classes of buffer overflow (https://azsec.tech/fsp).

• -Wformat-overflow This detects string format overflows (https://azsec.tech/3i8).

• -Wstringop-overflow This detects overflows in memcpy and strcpy (https://azsec.tech/3i8).

• -fstack-protector-strong This adds stack-based corruption detection (https://azsec.tech/qfg)

• -fPIE This creates a Position Independent Executable (PIE) that uses ASLR (https://azsec.tech/opj).

• /fsanitize=address This is the same technology used in VC++ (https://azsec.tech/m44).

All these options find or detect potential memory safety issues at compile time or runtime. You should use as many of these options as possible. Many of them will fail fast in the face of an issue, enabling you to debug and fix the issue quickly.

Use analysis tools

Both gcc and VC++ include baseline code analysis functionality. While you probably don’t need to run the analysis on each build, you should perform it at least once per sprint so you can catch any issues quickly and fix them. Also, although these tools have a strong focus on security, they find other issues, too.

Visual C++ also has an /analyze option that performs various code quality and security checks on your code. There is an overlap between what /fsanitize=address can find and what /analyze can find. In our opinion, for native C and C++ code, you should use both until you determine that one performs better on your codebase. You can find information about /analyze here: https://azsec.tech/r7c.

In addition, Microsoft Research created the source-code annotation language (SAL) used in the Windows SDK and Microsoft Runtime headers. You should seriously consider using it in your custom C++ headers, too. You can read more about SAL here: https://azsec.tech/rxy.

Finally, the Visual C++ team wrote an excellent article about NULL-deference detection using the static analysis tools built into the compiler. You can read about it here: https://azsec.tech/bxv. For gcc, a compiler option was added to gcc v10 to provide lightweight static analysis. You can learn more here: https://azsec.tech/87z.

On the GitHub side, CodeQL is a tool that is free for research use and free when used with open source software. CodeQL (previously named Semmle) is a rich static analysis solution that offers advanced capabilities such as data flow and control flow analysis across various programming languages, including C, C#, C++, Go, Java, JavaScript, Python, Ruby, and TypeScript.

CodeQL builds a database of the code. Then, a developer can use SQL-like queries to search the code for specific conditions that indicate code quality bugs, including vulnerabilities. A nice feature is that the CodeQL query language is the same regardless of the underlying programming language. Also, because anyone can create CodeQL queries, CodeQL democratizes query creation.

If you are reviewing commercial analysis tools, consider using tools that support Static Analysis Results Interchange Format (SARIF). You can read more about it here: https://sarifweb.azurewebsites.net/. SARIF allows the output of multiple analysis tools to feed into various reporting and all-up analysis tools. CodeQL supports SARIF, as discussed here: https://azsec.tech/7f2.

Generating totally random data

This is simple! Just create a random set of bytes. In our example, we’d probably create a series of lines of random data. The following PowerShell code does this:

Click here to view code image

Set-StrictMode -Version latest

function Get-RandomLine {
    param (
        [Parameter(Mandatory)] [int] $len
    )
    $charSet = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789{]+-
[*=@:)}$^%;(_!&#?>/|.'.ToCharArray()

    $rng = [System.Security.Cryptography.RandomNumberGenerator]::Create()
    $bytes = New-Object byte[]($len)
    $rng.GetBytes($bytes)

    $data = New-Object char[]($len)

    for ($i = 0 ; $i -lt $len ; $i++) {
        $data[$i] = $charSet[$bytes[$i] % $charSet.Length]
    }

    return -join $data
}

$fileName = "appointments.csv"
"" | out-file $filename

$numLines = Get-Random -Minimum 2 -Maximum 20
1..$numLines |% {
    $len = Get-Random -Minimum 10 -Maximum 256
    Get-RandomLine $len | out-file -Append $fileName
}

You could modify the $charSet variable to include other characters, of course, but this is a reasonable start. It creates a text file of random lines. This file could be uploaded to the storage account; the Azure Function then picks it up and parses it. The function code should utterly reject this file because it is syntactically incorrect, if for no other reason than the code cannot split the lines into the five discrete fields (unless, by luck, a random line includes four commas, which can happen, but it’s unlikely).

Now let’s make the fuzzing a little smarter. Rather than creating random data, let’s create five fields of random data. This should get us past the code that checks the number of fields in each row. We can tweak the PowerShell code to this:

Click here to view code image

$fileName = "appointments.csv"

"" | out-file $filename

$numLines = Get-Random -Minimum 2 -Maximum 20
$numFields = 5

1..$numLines |% {
    $line = ""
    1..$numFields |% {
        $len = Get-Random -Minimum 0 -Maximum 64
        $field = Get-RandomLine $len
        $line += ($field + ",")
    }

    $line.TrimEnd(",") | out-file -Append $fileName
}

This produces a CSV file made up of a random number of lines, and each line comprises comma-separated random characters. This might get past the check for the number of fields, but some lines might fail because the comma is in the list of random characters, and we get more than four commas.

This will work in some cases, but not many. There’s a fine line between data that’s “corrupted a little bit” and data that’s a complete mess. Most systems will detect incoming data that is completely random. Again, the CSV data is probably syntactically incorrect. We can do better!

Mutating existing data

This is a favorite among security researchers because it’s effective. You take a corpus of valid data, tweak the data, and then send the data to the application and see how it reacts. For example, if this were a REST endpoint, you could tweak the JSON payload before it hits the wire, where it would then be consumed by the server.

For our example, we need to collect or generate a corpus of thousands of valid lines of data that go in the CSV file. But, to keep this simple, we’re going to work with one line. Remember, the format is as follows:

Click here to view code image

centerId, date and time, vaccination type, open spots, comment

We will use this:

Click here to view code image

98722, 2022-03-16T15:50-06:00, PharmaA, 4, These are the last batches of PharmaA

Recall that we said you want to find the fine line between tweaking the data slightly and making it totally random. Here, we need to set a threshold, so we make tiny changes. Examples of these small changes might include the following:

• Inserting random characters

• Deleting random characters

• Setting or resetting the high bit of a character

• Byte swapping

• Truncating the data

• Adding data at the end or start of the data

• Inserting special characters (for example, file system special characters, like , /, :, etc.) or character sequences (for example, HTML or SQL)

• Inserting interesting numbers, such as 2^n - 1, 2^n + 1, 0, MAX_INT, MAX_UINT

The following snippet of C# code takes a byte array (passed in the constructor, not part of this snippet) and fuzzes the array if a threshold is met. For example, we might only want to fuzz 5 percent of the incoming data. You need to find what this threshold is for your data. The code also performs multiple passes over the incoming data, so a string can have more than one mutation. Finally, you can set a random number seed to reproduce an error.

Click here to view code image

public SimpleFuzz(int threshold=5, int? seed = null) {
        _rnd = seed is null ? new Random() : new Random((int)seed);
        _threshold = threshold;
    }
public byte[] Fuzz(byte[] input) {
    if (input.Length == 0) return Array.Empty<byte>();
    if (_rnd.Next(0, 100) > _threshold) return Array.Empty<byte>();

    var mutationCount = _rnd.Next(1, 5);
    for (int i = 0; i < mutationCount; i++) {

        if (input.Length == 0) break;

        var whichMutation = _rnd.Next(0, 7);

        int lo = _rnd.Next(0, input.Length);
        int range = _rnd.Next(1, 1+ input.Length / 10);
        if (lo + range >= input.Length) range = input.Length - lo;

        switch (whichMutation)
        {
            case 0: // set all upper bits to 1
                for (int j = lo; j < lo + range; j++)
                    input[j] |= 0x80;
                break;

            case 1: // set all upper bits to 0
                for (int j = lo; j < lo + range; j++)
                    input[j] &= 0x7F;
                break;

            case 2: // set one char to a random value
                input[lo] = (byte)_rnd.Next(0, 256);
                break;

            case 3: // insert interesting numbers
                byte[] interesting = new byte[] { 0, 1, 7, 16, 15, 63, 64, 127, 128, 255 };
                input[lo] = interesting[_rnd.Next(0,interesting.Length)];
                break;

            case 4: // swap bytes
                for (int j = lo; j < lo + range; j++) {
                    if (j + 1 < input.Length)
                        (input[j + 1], input[j]) = (input[j], input[j + 1]);
                }
                break;

            case 5: // remove sections of the data
                input = _rnd.Next(100) > 50 ? input[..lo] : input[(lo + range)..];
                break;

            case 6: // add interesting pathname/filename characters
                var fname = new string[] { "\", "/", ":", ".."};

                int which = _rnd.Next(fname.Length);
                for (int j = 0; j < fname[which].Length; j++)
                    if (lo+j < input.Length)
                        input[lo+j] = (byte)fname[which][j];

                break;

            default:
                break;
        }
    }
    return input.ToArray();
}

Figure 9-7 shows part of the Locals window in Visual Studio, and you can see that the incoming string, named data, has been partially corrupted in the res variable. Part of the first field is removed, part of the second field looks like the upper bit is set, and some parts of the last field have been flipped.

As you can see, the fuzzing is much subtler than the previous methods of using random data. The goal of more subtle fuzzing is to attempt to get greater code coverage, if possible.

Intelligently manipulating data knowing its format

The last type of fuzzing is when the fuzzing logic understands the data format—for example, if you have a custom-written graphic image parser that handles Portable Network Graphics (PNG) image files. Understanding the data format is important for some data types, because when the logic understands the format and structure of the file, it can make surgical changes to a file. A PNG file will have elements like X- and Y-dimensions, color depth, and more, that can be smartly fuzzed—for example, by the following:

• Setting X or Y to negative numbers

• Setting X or Y to alphabet characters

• Setting X or Y to massive values

• Setting the color depth to crazy values

Perhaps most importantly, PNG files also have checksums. If your code injects random data into the file, the file checksums will be incorrect, and the code you’re trying to fuzz will reject the file quickly, before it gets further into the code. This means that after the file is fuzzed, the checksums will need to be recalculated.

Fuzzing APIs

We want to wrap this section up with one more important topic: fuzzing APIs. Today, exposed APIs are a common target of attack. These can relate to code-level vulnerabilities as well as design issues such as a lack of authentication or authorization and more. One website, APIsecurity.io (https://apisecurity.io/), is an excellent resource to learn more about real API vulnerabilities in the real world.

You should perform security testing of your APIs—for example, those exposed by Azure Functions, Azure App Service, or code written in Node.js running in a container. Fuzzing is one type of test; you can take the aforementioned practices and ideas and apply them to APIs, too. For example, if an API uses the HTTP GET method to read a resource, you can corrupt parameters on the query string. Or if you use a POST to create a resource, you can corrupt the JSON or XML payload in the HTTP body.

Suppose our vaccination booking application uses an HTTP POST API call with a JSON payload rather than uploading a file to Azure. A request might look something like this:

Click here to view code image

{
    "centerId" : "98722",
    "date_time" : "2022-03-16T15:50-06:00",
    "vaccination_type" : "PharmaA",
    "open_spots" : "4",
    "comment" : "These are the last batches of PharmaA"
}

Of course, the payload will probably have more than one item, but we want to keep things simple. Your fuzzing logic could apply the same tactics on this payload, but by manipulating the fields of the JSON file.

Be careful when fuzzing files like JSON and XML. You probably don’t want to fuzz the structure of the file—for example, replacing the opening { with a random value—because corrupting the structure of the JSON file won’t get beyond the JSON parser, let alone get to the code you really want to test!

The following code is an update to the preceding code that can handle a JSON file:

Click here to view code image

public byte[] Fuzz(JsonDocument doc) {
    byte[] fuzzResult = Array.Empty<byte>();
    using var stream = new MemoryStream();
    using (var writer = new Utf8JsonWriter(stream)) {
        writer.WriteStartObject();
        foreach (var elem in doc.RootElement.EnumerateObject()) {
            writer.WritePropertyName(elem.Name);
            byte[] fuzzed = Fuzz(elem.Value.ToString());
            writer.WriteStringValue(fuzzed.Length > 0
                            ? System.Text.Encoding.UTF8.GetString(fuzzed)
                            : elem.Value.GetRawText().Trim('"'));
        }
        writer.WriteEndObject();
        writer.Flush();

        fuzzResult = stream.GetBuffer();
    }
    return fuzzResult;
}

Figure 9-8 shows a run of about 15 generations of the preceding code. As you can see, every line has one or more subtle changes. Each line represents the same starting text, but the mutations are different each run. Ask yourself, do you think your API code could handle all these lines of JSON without crashing?

One final note: you need to detect at the code level if the application fails to handle the incoming data. Historically, you would use a debugger and log the debug spew, but in Azure, you should use Application Insights to monitor the API or code as it responds to incoming nasty data.