Now that the code is configured to generate an OpenAPI document file that describes the web API, VanArsdel’s development team turns their attention to publishing the application.
Seamless development experiences in Visual Studio, from code to deploy
In a fusion development team, time is one of the most valuable assets. You write code and build an app, then use different tools to deploy your app. You come back to the code, update it, and switch to the other tools for deployment. The cost for switching between tools is huge, and eventually it decreases your productivity.
What if your development tool, Visual Studio, can do everything for you in one place? It saves time and increases productivity. Visual Studio offers features to publish your app to Azure App Service.
Visual Studio also offers the feature to integrate your web API with Azure API Management while publishing the app.
In the next couple of exercises, you’ll explore how to publish your web API application to Azure App Service and integrate it using Azure API Management.
Template components that you can reuse across multiple apps provide a foundation of tried and tested layout and logic for UI element customization. Template components apply a standardized design across a web app by defining common elements and applying them to all pages. Templates can streamline updates, such as rebranding, because you make modifications only at the central template location.
In this unit, you learn about template components and how you can incorporate them into a Blazor application.
Blazor components have a well-defined lifecycle that starts when they’re first created and ends when they’re destroyed. A set of events that occur in response to specific triggers governs the component lifecycle. Such triggers include the component being initialized, users interacting with the component, or the page where the component resides being closed.
In this unit, you learn about the events that occur during the Blazor component lifecycle. You see how to handle these events to optimize the work done and increase the responsiveness of a Blazor page.
Blazor uses C# components rather than JavaScript to create web pages or HTML sections with dynamic content. But you can use Blazor JavaScript interoperability (JS interop) to call JavaScript libraries in Blazor apps and call JavaScript functions from .NET C# code.
In this unit, you learn how to call JavaScript from C# code in a Blazor page, and how to invoke C# methods from JavaScript functions. In the next unit, you use an alert component from a JavaScript library to update your Blazor pizza delivery website.
Use Blazor JavaScript interoperability
A typical Blazor component uses layout and user interface logic to render HTML at runtime. You use C# code to handle events and other dynamic page features that interact with the user and external services. In many cases, you don’t need to use JavaScript code. Instead, you can use Blazor with .NET libraries, which provide many equivalent capabilities.
However, sometimes you need to use an existing JavaScript library. For example, some open-source JavaScript libraries render components and handle user interface elements in a specialized manner. Or, you might have existing tried and tested JavaScript code that you want to reuse instead of converting it into C#.
You can integrate JavaScript libraries into your applications by using Blazor JavaScript interoperability, or JS interop. You use JS interop to call JavaScript functions from .NET methods and to invoke .NET methods from JavaScript functions. JS interop handles the marshaling of data and object references between Blazor and JavaScript to ease the transition between them.
A task that you often need to perform is packaging libraries for reuse by other developers. NuGet packaging makes it trivial for any developer anywhere to acquire and properly configure all the .NET references for their applications.
In the preceding unit, you built your modal dialog component and used it in your own application. Now you want to reuse it in other applications.
In this unit, you learn the steps necessary to configure a Razor class library as a NuGet package. You also learn how to package the library for distribution by using a package-repository service, such as NuGet.org, or GitHub repositories.
Configure a Razor class library for NuGet packaging
The .NET ecosystem makes it easy to define the properties that are necessary for other developers to identify and use your components. You can define all these properties in the project file (*.csproj) of your Razor class library so they travel with the library. The properties are then updated appropriately when your library is updated.
Components in web applications give developers the ability to reuse portions of an application user interface throughout the application. By using Razor class libraries, developers can share and reuse these components across many applications.
In this unit, you learn how to create a Razor class library. You then use it to share rendered and static content for Blazor applications to customize and display.
Razor class libraries
A Razor class library is a .NET project type. It contains Razor components, pages, HTML, Cascading Style Sheet (CSS) files, JavaScript, images, and other static web content that a Blazor application can reference. Like other .NET class library projects, Razor class libraries can be bundled as a NuGet package and shared on NuGet package repositories such as NuGet.org.
Let’s look at the default template for creating a Razor class library.
Create a project by using the default template
You can optionally begin creating a Razor class library in Visual Studio by selecting File > New Project.
You can also create projects on a command-line interface by running the following command:
.NET CLICopy
dotnet new razorclasslib -o MyProjectName
This template delivers an initial component named Component1, which contains several important features that your components can use:
An isolated cascading style sheet named Component1.razor.css, which is stored in the same folder as Component1.razor. The Component1.razor.css file is conditionally included in a Blazor application that references Component1.
Static content, such as images and JavaScript files, which is available to a Blazor application at runtime and referenced within Component1. This content is delivered in a wwwroot folder that behaves in the same way as a wwwroot folder in an ASP.NET Core or Blazor application.
.NET code, which executes functions that reside in the included JavaScript file.
Differences between a class library and a Razor class library
A class library is a common package delivery structure in .NET applications, and a Razor class library is similar in structure with a few other features configured in the project file.
The project file contains an SDK reference to Microsoft.NET.Sdk.Razor to declare that it contains and creates Razor content as a Razor class library.
The SupportedPlatform entry declares that this library can be used in a browser platform, namely WebAssembly.
The PackageReference to the Microsoft.AspNetCore.Components.Web library gives access to the base Blazor components that are shipped with the framework. This access lets you use those simple components to help you build more complex components.
Razor component contents
This initial Razor component is simple. It contains only an HTML div element with a short block of text:
razorCopy
<div class="my-component">
This component is defined in the <strong>FirstRazorLibrary</strong> library.
</div>
Server-side request forgery (SSRF) describes situations where a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination.
Attackers might also use this functionality to import untrusted data into code that expects to only read data from trusted sources, allowing them to circumvent input validation.
A URL or query string seen in a web browser’s address bar, when used as an input parameter, could be a perfect example of user input needing sanitization.
During code review, you came across a seemingly harmless REST web GET request:
C#Copy
string url = Request.Form["url"];
var client = new HttpClient();
HttpResponseMessage response = await client.GetAsync(url);
Without validating the supplied URL, an attacker can hijack the network connection and control the request schema by supplying ldap://, jar:// or file:// instead of https://. Furthermore, the POST method allows an attacker to force the application to send a crafted request to an unexpected destination.
How do you detect if you’re breached? How can you determine what steps the attacker took to penetrate your system?
Without sufficient logging and monitoring, you can’t detect breaches. Logging and monitoring give you an opportunity to stop an attacker in their tracks. Telemetry, logging, and monitoring enables digital forensics and post-mortem after a breach. Logging and monitoring are essential components in ensuring that you can detect any suspicious activity in close to real time, or diagnosed after the fact.
More importantly, collecting this data is useless without actively reviewing it or having alerting rules in place.
Make sure to sanitize the data to prevent from over-logging or storing sensitive information as logs.
Establish effective monitoring and alerting mechanisms. Ensure that sign in and access-control failures are logged with sufficient user context for identifying suspicious or malicious accounts. Take advantage of different logging levels (Info, Warning, Error, and so on) and log destinations. Avoid server-side error details from ever reaching client side, which can result in leaking your system’s implementation details.
Highly configurable and distributed software, along with supporting services and tooling, introduces complexity. Increased complexity also increases the attack surface by introducing more components that should be secured. Security misconfigurations can occur when an application is missing the appropriate security hardening across any part of the application stack. It can manifest itself by reusing passwords or improperly configuring permissions on cloud services.
Security hardening
The application might be vulnerable if it’s missing a rigorous, repeatable application security configuration process.
The following image shows a typical enterprise-scale application with supporting DevOps process. Here, security misconfiguration can apply to how you protect developer workstations, handle app secrets in your application, protect the CI/CD process, and so on.
Security misconfiguration can manifest itself in many places, from web.config or appsettings.json settings, a database account, connectivity, or Internet Information Services (IIS) configurations. The automation workflows and cloud hosting can be misconfigured or abused too. A CI/CD system could be storing plain-text environment credentials for release. A cloud environment could be using managed shared admin accounts instead of following the least-privileged principle. In the world of Microsoft cloud, Azure role-based access control offers granular control over permissions granted to users and cloud services.
The preceding example demonstrates one of many native integrations between Azure DevOps and Azure Cloud, where Azure DevOps Library is linked with Azure KeyVault to securely access secret pipeline parameters.
Secret values should never be found in a codebase. The same practice applies to infrastructure as code (IaC) release workflows and CI/CD services themselves.
As the new addition to the team, be on the lookout for default accounts and their passwords being enabled and unchanged. Use secure settings for your application servers, frameworks, libraries, and databases. As you familiarize yourself with your team’s codebase, take this opportunity to remove any unused features, components, accounts, or services from your applications.
So far, you focused on unwanted coding errors leading to security flaws; that is, implementation issues surrounding user authenticating, data encryption, and so on. Insecure design is different from insecure implementation. Insecure design has more to do with risks related to design and architectural flaws. A secure implementation might have an insecure design, which still renders an application vulnerable to attacks and exploits.
Exercise assume breach mentality: minimize the blast radius for breaches and prevent lateral movement by segmenting access by network, user, devices, and application awareness. Verify all sessions are encrypted end-to-end. Use analytics to get visibility, drive threat detection, and improve defenses. Authenticate and authorize based on all available data points. User identity, location, device health, service, or workload are some common data points.
You might be familiar with the term shift left. Most often, the term refers to testing your application early on during the application lifecycle to ensure high quality. Shift left also applies to considering security before you write a single line of code. A few activities to employ early on in the design process could include reviewing secure design patterns and principles, using reference architectures, and performing threat modeling.
Let’s discuss the latter in more detail. Threat modeling is an essential part of DevSecOps, because it informs your security design process and helps find vulnerabilities in your application. While it does fall under DevSecOps, it also sits neatly under education too.
You can use threat modeling to help mitigate threats from the early stages of application design.
