Analyzers for Secure Code

Code analysis packages can aid software development and improve code quality. As code complexity grows, even the most experienced software developers and engineers sometimes fail to catch bugs in the code. For .NET Core environments, there are packages that are available as NuGet downloads and IDE extensions; Resharper and so on. It is best to use these tools to notify the developers about potential code smells before the code is checked in. This happens before DevOps and helps decrease infrastructure costs.

Runtime Selection and Configuration

It is also good practice to use production-like environments for build and testing stages. This approach helps ensure that the code will work in the production environments. Normal development machines have variables and scripts set up in aiding the program’s execution. These can be problematic in the production environment, and sometimes they are not available altogether.

Docker is likely the de-facto when it comes to containerization and cloud-native solution development. Your teams should run tests against Docker environments too. Docker containers are also vulnerable to security and performance bugs. You should scan the images before you run your tests on them. Docker Hub provides you with good tools that you can use to run scans on your built images, and a list of known vulnerabilities in existing images, so you can ignore those images in your development environment.

For .NET Core, Microsoft has shipped the Docker images that are available on Docker Hub,¹² as seen in Figure 3-1. Microsoft provides Docker images for the .NET Core runtime, .NET Core SDK, and ASP.NET Core runtime. There are preview editions for .NET Core available too, but they are not for production environments.

The .NET Core SDK supports environment variables and configuration files. These files are used to store necessary information for the program to start and execute. You can create separate configuration files for each environment on which your team must run the application. Since .NET Core applications—especially ASP.NET Core—must utilize a middleware registry to start the pipeline, you can easily configure which file to read the configuration from. This lets your developers configure a local database to connect to, instead of the production database.

Code Smells, Bugs, Performance Issues and Naive Errors

Finally, code smells and bugs pollute the source code repository and decrease the value of the product. There are bugs that are visible to the end users and there are bugs that are not visible to the end users. Just because a bug is not visible to the end user does not mean that it has a low priority. Think of a software issue where a bad algorithm is being used that is eating up the maximum amount of your infrastructure resources. An end user might not complain but your accounts and finance departments will.

These types of errors are commonly the most difficult to detect and remove. This is where load testing/stress testing comes in to play. You can run statistical tests on the web apps and software written in .NET Core using QA and testing suites. The purpose of QA tests is to verify the code quality and find the regions where the code is taking most time. Your engineers can review the part of your code that has performance issues.

Unlike logical issues, which you can verify using unit testing, you cannot test to see if a website provides a response to a user query in less than 200 milliseconds. Even if you time a request-response from your API, you cannot be certain that a website would perform similarly in a production environment. For such reasons, statistical testing of the code is used. Many QA tools, such as Apache JMeter, provide such a feature that lets you run the test on the software and generate hypotheses that show a fail/pass scenario for your website’s performance.

Likewise, QA tests are run on a running app, and responses are captured and logged. A request is made a couple hundred times, imitating real users on the Internet. The responses are used as data samples and the rest of the calculations are done by statistics. This helps your engineers see if the app would function properly in high traffic scenarios, based on statistical tests. Later in the book we will see how to use Apache JMeter to perform basic load tests on our applications, and if we can integrate the entire process in our CI/CD pipeline.

For each negative outcome, engineers need to rework the application and add a patch to fix the problem. This also means that for each bug fix, performance increase, or code improvement, your entire application has to be rebuilt, deployed, and restarted on the server. That is where microservices architectures come into the play; more on that later in this chapter.

Fixing Injection and Scripting Attacks

Most vulnerabilities are caused by poorly tested software code. ASP.NET Core code requires more test checks as compared to front-end modules, such as React. Most front-end constructs fail to build if you use them inappropriately. In React, for example, if you try to pass in an HTML snippet as a props to a component, it terminates the code. The reason to do this is to avoid HTML injection in the DOM. React, however, does support using a special props value, dangerouslySetInnerHtml,¹⁸ which you can use to pass the HTML.

EditorComponent is a React component that exposes a Markdown editor tab.

This component is responsible for attaching a couple of event handlers that take input from the user and convert that Markdown to potential HTML. Then, in our components, we render the HTML in the DOM .

MarkdownInputComponent exposes a textarea field that is used to input the Markdown.

MarkdownPreviewComponent exposes the paragraph element that renders the content.

Figure 3-2 shows a preview for this.

What happens here is that our Markdown content is converted to HTML but React renders this HTML by escaping it. So <h1> becomes <h1>. This prevents HTML injection in the DOM and secures the client from getting polluted or vulnerable code script.

But if you need to inject the Markdown-rendered HTML, you might need to skip this check. In such cases, React allows you to use the function we spoke about previously and render the HTML directly in the innerHTML part.

After this minor code change, your document will properly render the HTML content in the DOM, as shown in Figure 3-3.

This could still lead to problems, as Markdown does not prevent native HTML being an injection in a Markdown document. You can restrict the HTML content to run tests on the code before rendering it on the DOM.

React ensures that you know what you are doing, and that you and only you are responsible for the problems caused by directly injection HTML into the DOM. That is why the props name starts with danger and you need to pass a special object with __html as a field name. You can avoid having to do this manually by using community-driven packages and libraries. For example, you can add the Remarkable NPM package to your projects, or you can use the react-mde NPM package to use their React components, which are well tested against issues that you might have to test yourself.

Injection attacks are not only common to front-end libraries, several injection problems occur on the back-end too. SQL Injection is one such problem. In an ASP.NET Core web application—also an application to other platforms of .NET Core like Mobile, Cloud-native, Games, and ML.NET—you should consider using an ORM that performs your SQL queries. Entity Framework Core is the most widely used ORM for .NET Core apps.

You can use C# language features such as LINQ to query the data. Most C# features, such as asynchronous development, are supported and provide excellent performance in high-demanding environments.

Scripting Problems: XSS, Token Forgery, and Session Hijacks

NPM also suggests a possible solution to these problems and allows you to fix all problems using a command. Note that NPM does not guarantee a solution to the vulnerability itself, but it will attempt to revert to a version that did not contain a vulnerability. You can execute npm audit fix and NPM will try to patch it if it can. In a larger project you might run into issues when you audit a complete solution. If your teams utilize a central build system, it will face more problems when it comes to fixing and handling build warnings and errors.

Automated Tests

We will explore the automated tests and their benefits when it comes to DevOps in the later parts of this book. For the time being, we can enlist the automated testing suites as a way of preventing the bugs in the software.

Unit tests, integration tests, and load testing suite enable you to verify whether your application provides or fulfills a service-level objective. Organizations can define their own test suites to verify software stability. Build pipelines can run the known tests on the packages. It is your responsibility to add tests as they become necessary. One such example is adding the newly determined errors and bugs to the software code.

As shown in the previous chapter, we can use static-code analysis tools to find the tests necessary in future packages. You can use dynamic code analysis and web firewalls to detect, monitor, and add bugs to your workloads. Your engineers can then select a test from this list and work on the test cases.

I will revisit automated tests in a later part of this book; right now we study how to separate the application’s parts based on the domain and explore the benefits.

Corporate Applications

One application of virtual networks is within the corporate networks and corporate applications. A virtual network provides access to services deployed in it. Internet-based access is not allowed. Corporate applications can utilize virtual private networks, or VPN for short, to access the services deployed in the virtual networks.

This serves as a security layer on top of your software packages. You can deploy the applications on the cloud within a virtual network. Say you have a web application that provides a static HTML page to your customers. Your resources within a virtual private network can be utilized by the web page. Your customers access the website (static HTML or a framework-based web application).

Microsoft Azure allows you to connect your applications to a specific virtual network, as shown in Figure 3-7.

You can select the virtual network that you just created on the cloud to add this website to that network, as shown in Figure 3-8.

Once you have added the website to the virtual network, it can access the resources inside the virtual network. You can see the number of addresses available in the virtual network and the subnet that you selected for website (see Figure 3-9).

You can modify the virtual network settings to add more resources to the network. Remember that each resource must consume a separate IP address to be made available.

You can also use other products and services of cloud platforms such as identity services. The benefit of identity services is that your .NET Core applications no longer need to manage the user accounts and profiles on their own databases.

Increasing Scalability

As previously seen in Chapter 2, .NET Core enables developers to create user identity databases inside the application. For a starter or a proof-of-concept application, it is a good practice. As your users grow, you should separate the database and application code. This increases the overall scalability of your applications. An application that is hardcoded with databases and contains the user or session information in the memory is more likely to fail.

ASP.NET has been using in-proc session management for users since its early days. The design requirement for an N-Tier app demands the separation of different layers. We can architect the application in a microservice approach and provide different endpoints for services. Once our application has been separated from the hardcoded resources, we can better scale the applications. Several database engines offer this kind of data synchronization support. In my own experience, I have used Redis cache database¹⁹ to out-proc the session management.

A cloud-native application often utilizes Docker or Kubernetes engines to orchestrate the web applications. If you have ever worked with Kubernetes, you must be aware of the difficulties that a DevOps might face while working with Stateful²⁰ deployments. If you are using a cloud-platform such as Azure to deploy your databases and other resources, you can use a stateless deployment on Kubernetes and have your work done. Your web resources are managed for scalability and availability by the cloud, and your web app is managed by Kubernetes.

If you are provisioning the services yourself, it’s better to convert your applications to be stateless.

TCP

TCP-based communication is provided and supported out of the box for several apps written in .NET Core. The .NET Core framework supported System.Net namespace offers a vast variety of objects that help write network-oriented apps. The TCP stack for networking is old but provides a very secure and guaranteed method of communication between multiple resources.

You, as a developer, do not need to test the validity of your apps to run on the TCP stack if you are using .NET Core provided TCP/UDP protocols. TCP is also the simplest method of communication in applications.

A common alternative to TCP is a named pipe. A named pipe is a UNIX concept that allows a program to communicate with another program using a pipe.²¹ The benefit of using a pipe is that it is available on all UNIX and Linux platforms. There is an extra bit of security to pipes as well. A program can access the pipes that it has created, as a file descriptor. Only the program that created the pipe can forward the file descriptor (the FD) to another program for communication. External processes cannot access the FD of the program’s pipe. A TCP based communication uses a hostname and the port to communicate, which can be sniffed. Note that the FD of a pipe can also be exploited in several ways, but that is beyond the scope of this book.

A TCP programming sample can be found on my GitHub profile at https://github.com/afzaal-ahmad-zeeshan/tcpserver-dotnetcore. You can fork the project and run it through the code analysis tools as an exercise.

HTTP/2, gRPC, and Beyond

Many modern buzzwords are being introduced to support the modern traffic load and performance requirements. HTTP/2, gRPC, SignalR, and many other technologies have been introduced in .NET Core runtime. Microsoft introduced support for HTTP/2 in their Edge browser, and every other web browser company has done it in the past or is doing so right now. The problem with these is that not everybody has adopted the frameworks. HTTP/2 provides an improvement over the number of requests per response from the server.

This command creates a new ASP.NET Core application with gRPC support. The gRPC uses Protocol Buffers²² (Protobuf) to generate services that provide safe-typed responses. When we combine these solutions, the result becomes cross-platform in nature and offers microservices out of box. The gRPC is also proposed to be used instead of HTTP protocol for better performance and little overhead.

The problem with gRPC is the same as with WCF: the clients need to be compliant with the framework.

For the teams that use .NET Core for their development, gRPC does not pose any problem. You can develop gRPC clients using .NET Core—I will show one such example later—and then deploy the solutions on any platform you want. The platforms that can be targeted range from basic web applications, console programs, mobile apps (using Xamarin), microservices, and cloud-native applications. They all are possible candidates for peer-to-peer or remote procedure operations. The primary difference in gRPC and WCF is that WCF is based on the .NET Framework, which is available on the Windows operating system only.

On the other hand, gRPC clients can be developed using .NET Core, which targets the .NET Standard. This enables gRPC to be used across devices, platforms, and screens.

One common point to remember is that gRPC uses TLS to encrypt the data. There is no layer of gRPC that adds security, and the message travels on the wire without security. It is recommended to always use TLS and SSL certificates to verify the identity of the endpoints—the server and the clients. A single certificate can improve the overall experience for the users. We can also swap the components of the gRPC layers, such as the HTTP/2, to improve performance. One such implementation is the addition of the QUIC protocol to the suite. In this case, we apply the TLS and SSL encryptions but use the QUIC protocol to send and receive the messages. The binary messages transferred by gRPC represent the states of the messages. A web application must refrain from sending sensitive information on the network if the channel is not secured. Most applications can utilize a VPN to secure the communication when using an SSL certificate is not possible.

You can keep things simple and encrypt the data before sending it if your application cannot be secured behind an SSL certificate. You can use the framework’s security libraries, such as the ones offered by the .NET Core framework.

gRPC Sample

You have created a basic gRPC-supported application for real-time messaging and remote procedure calls. A basic gRPC web service is defined as a Protocol Buffer (proto), as follows:

syntax = "proto3";

option csharp_namespace = "Chapter3.gRPCApp";

package greet;

// The greeting service definition.

service Greeter {

  // Sends a greeting

  rpc SayHello (HelloRequest) returns (HelloReply);

}

// The request message containing the user's name.

message HelloRequest {

  string name = 1;

}

// The response message containing the greetings.

message HelloReply {

  string message = 1;

}

This defines the complete contract of a request and response. You can see that we are configuring the C# client namespace here as well. A service is defined as Greeter and has a method called SayHello accepting HelloRequest and returning HelloReply. This enables gRPC to be simple in definition. You will use a proto-compiler to compile the service to native programming languages such as Java, C#, and C++. For .NET Core applications, the build tools and compilers are available through NuGet package managers.

When you created the project, the compilers were automatically set up for you. You only need to execute the following:

$ dotnet run

The .NET Core CLI will automatically build everything and run the project for you. The security is added because gRPC requires²³ you to use HTTPS for traffic and communication.

Note

If you are new to development, then you can use .NET Core CLI to create and add a custom signed certificate to your system.

You should use the .NET Core CLI to set up the local certificates for your application and trust it in the system. Here is the code for that:

$ dotnet dev-certs https --trust

This will create a listing of developer certificates in the trusted certificates registry on your machine. This will prevent your applications from crashing (due to certificate failures) or your browsers from showing an error each time you try to access the resource in development mode.

If you access the resource now, your browser will show you a message, as shown in Figure 3-10, stating that you need to access the resource from a gRPC client.

This is a similar requirement as with WCF. But the good thing is that we are not strictly tied to a specific platform here. We can use .NET Core and develop client applications for any platform that we want our application to work on. The client does not need to have any special setup. We can use a basic console application to connect to the gRPC service that is running.

$ dotnet new console

Once the console has been created, you should add the NuGet packages for gRPC client packages. The name of the C# project file is gRPCClient.csproj and you can find it in the Chapter 3 resources.

$ dotnet add gRPCClient.csproj package Grpc.Net.Client

$ dotnet add gRPCClient.csproj package Google.Protobuf

$ dotnet add gRPCClient.csproj package Grpc.Tools

These packages will enable the .NET Core console applications to communicate with the gRPC server application. You should open the Program.cs file and modify the code inside it. Paste in the following code²⁴:

using System;

using Chapter3.gRPCApp;

using Grpc.Net.Client;

using System.Threading.Tasks;

namespace gRPCClient

{

    class Program

    {

        static async Task Main(string[] args)

        {

            // The port number(5001) must match the port of the gRPC server.

            var channel = GrpcChannel.ForAddress("https://localhost:5001");

            var client =  new Greeter.GreeterClient(channel);

            var reply = await client.SayHelloAsync(new HelloRequest { Name = "GreeterClient" });

            Console.WriteLine("Greeting: " + reply.Message);

            Console.WriteLine("Press any key to exit...");

            Console.ReadKey();

        }

    }

}

Once you have finalized this, you can run the .NET Core console app to see the output of the program. You should have the gRPC server running before you start the client program.

$ dotnet run

Greeting: Hello GreeterClient

Press any key to exit...

This shows that our application connects to the gRPC server and communicates properly.

MD5 and SHA1 for File Hashes

You can use MD5 and SHA1 hashing²⁶ functions in your filesystem to verify their authenticity. Although I would prohibit the use of MD5 or SHA1 for password hashing (as discussed in previous section, MD5 and SHA1 have known rainbow tables and attacks, respectively, and their hashes can be converted back to the plain-text passwords), it is common to use MD5 or SHA1 for file hashing.

You might have experienced on a download site that a special hash (hexadecimal string) is provided along with the download file buttons. These strings are used to verify the authenticity of the file. It might be that a file was corrupted on the server, on the network, or on your own machine. This text helps you verify that the file you downloaded and are going to install on your machine is authentic. Several open source projects use this scheme to ensure their customers know that the file is not modified.

You can use this approach to prevent any false claims from your users against you, if their system is compromised. If this hash is different for the executables, then you know the system has been modified outside your control.

The size of MD5 hash is smaller, as it uses the 128-bit hash size. There is no benefit to increasing the hash size for filesystem management. Although as your files grow in number and size, it would be useful to use SHA1 or SHA2 family variants. This can help you in your DevOps cycles as your maintain and manage the releases of your software product.

Apply SSL Across Domain

While using the algorithms for encryption and decryption, ensure that you are aware of these algorithms and how they work. It is a good approach to use HTTPS (encrypted traffic on the HTTP protocol), but it is always best to know when to use HTTP. Microservices and service-mesh architectures make it possible to use HTTP traffic inside the cluster to decrease the TLS handshake in each request and session. You must configure all public facing endpoints to always use SSL based traffic and always enforce SSL for cookies as well. It is a common misunderstanding that sending the content inside the HTTP body can secure the content on the network. The problem is that your content is available in plain-text and can easily be deciphered. Only HTTPS is capable of safely encrypting your traffic. HTTPS protects your website from man-in-the-middle attacks. Apply a QA check to validate all communication inside your service to use HTTPS.

A common pitfall with the HTTP/HTTPS is that sometimes organizations apply HTTPS only on the pages where they have a form. A web page with no input requires HTTPS too. Consider having a home page with basic HTML that redirects the users to their login pages. If your page is not encrypted, a hacker could attempt to modify the HTML code and redirect your users to a malicious website. This is a common problem if your website’s domain name is long. Your users might not be able to understand the basic difference between the URLs. Several phishing attempts use this approach to lead the traffic away.

It is always necessary to apply all safety checks throughout your website. If you are a corporate working in banking sector, the number of attacks on your website is huge as compared to a blog website. Your website might have state-of-the-art security protocols implemented on the accounts and transaction channels. But if your home page is unencrypted, an attacker can modify the HTML code and redirect your customers to a malicious website. They might not be able to get any benefit out of it, but your customers might expose their credentials to the website on their database.

A single domain certificate is available at a cheap price, and some are available for free. Let’s Encrypt is one such product that comes to mind. You can use Let’s Encrypt to quickly generate certificates by authorizing your ownership of the domain. Let’s Encrypt certificates are valid for 90 days and you can always request a new certificate when you need to. Several cloud providers support Let’s Encrypt certificates. There are community-driven tutorials²⁷ and articles that show how you can set up the certificates yourself. If you are using Microsoft Azure’s App Service, you can use the Let’s Encrypt WebJob to request²⁸ an SSL certificate for your domain.

Modern browsers also have a bias against unencrypted websites and their traffic.

Google Chrome shows when a website is encrypted and when it’s not. For many organizations this is a red-alert, especially those that deal with money. See Figure 3-13.

Google has shown²⁹ to lower the ranks of unencrypted websites in their search results. The Google Security Team says that Google will start to rank HTTPS pages over HTTP pages even if they have no links to them. The importance of HTTPS is bigger than the certificate cost.

Another problem with using mixed mode HTTP and HTTPS is that your website is loaded as one request per resource. If you use mix mode HTTP and HTTPS, your website is slowed down by the HTTPS request (due to the TLS handshake) and some requests are not making proper use of the TLS handshake already made. Most browsers will also try to prevent the resources being loaded from an unencrypted host. Static resources—such as images, CSS, and JavaScript files—are more prone to attacks by malware and man-in-the-middle attacks. Application of HTTPS across domains also prevents these problems.

Things get interesting when you develop solutions using modern web standards. Progressive web applications, or PWA for short, work only with HTTPS.³⁰ Most standards enforced by the SEO ranking tools also consider SSL certification a primary and leading factor³¹ in site ranking. Some websites have shown a double amount³² of traffic after application of SSL certificate on their web servers. Organizations have discovered that PWAs provide a better conversion rate as compared to native apps. Teams develop their solutions as a PWA to quickly turn their traffic into business value. Google recently notified³³ users of their AdSense product that they are moving from a native experience to a PWA experience. For you, this is possible only if you use SSL certificates on your website.