Web apps built with ASP.NET Core MVC are definitely some of the most well-liked of their kind worldwide. While their popularity undoubtedly has great advantages for businesses and individuals, it also puts them at the top of the list for hackers and attackers. As a result, protecting such apps need more attention.

High-grade security is necessary for all organizations and services operating in the digital sphere, and for good reason—users frequently share sensitive information with them. Therefore, the risk is multiplied when one of the most popular digital tools is being discussed. Consequently, there is an increasing need to put security measures in place to protect such apps from attackers.

Although there are a number of approaches, adopting industry best practices remains to be the most effective. And now it’s time to talk about some more best practices to Secure ASP.NET Core MVC Applications.

Cross-Site Scripting (XSS): 

Cross-site Scripting (XSS) attacks are when a malicious script is injected through the input/form fields of a web page with the goal to steal private information such login credentials or other authentication information, cookies, and session data. There are several effective ways to stop it, involving HTML encoding, regular expression attributes, regular expression object models, URL encoding, and more. It includes injecting a malicious script into a web page.

How to Prevent Cross-Site Scripting (XSS)?

• Regular Expression Attribute
• Regular Expression Object Model
• HTML Encoding
• URL Encoding

 

Prevent cross-site fraud:

Cross-site fraud is yet another way that hackers can access the website. In order to get private data and information, they pose as a trustworthy source and then spread false, harmful information. AntiForgryToken is among the most effective means of preventing these kinds of attacks.

For example, when a person successfully logs into a bank website and transfers money from one account to another, a trusted relationship is made. Users click on a malicious link from a spam email sent by the attacker at the same time.

Because the user and the bank site have created a secure session, the attacker can exploit this connection to carry out malicious actions like financial transfers.

However, it is a server (web application) side vulnerability rather than an end-user side one.

Using AntiForgeryToken, we can stop this attack. We must set this value and use the HTML attribute’s “asp-antiforgery” element. The [ValidateAntiForgeryToken] element must then be added to the form post action.

 

Leverage SSL and HSTS:

The encrypted connection between the client and the server is established via Secure Socket Layer. To protect the app, it is advised to use the HTTPS protocol. Let’s go on to the second component of this phase, the HTTP Strict Transport Security Protocol (HSTS), which is responsible for protecting the web app from threats like cookie hijacking and downgrade protocol attacks, among others. Your main concern will always be the security of an offering as long as you are working with the digital world. And for good reason—one of the main factors in the popularity of any app is data confidentiality and safety.

Although it comes with ASP.NET Core as standard, we strongly advise against using it in the development environment.

 

Custom Error Page for Error Handling:

Web applications occasionally lack or improperly create error handling code, which causes us to reveal to customers sensitive information relating to database configuration details, table names, stored procedures, and data structures, as well as programming coding structure.

How can we add proper custom error handling?

The custom error handling page can be added to the Core application in two different methods.

The first method involves using ExceptionFilterAttribute to build a unique error handling attribute. The exception will be handled by this attribute. In order to write an exception in a text file that is placed inside the chosen folder path, we can override the OnException method. Additionally, we have database storage for the exception.

The second strategy entails setting up UseExceptionHandler in a real-world setting. The custom error page will only be displayed in the error controller if the hosting environment is set to Production; otherwise, the actual error will be displayed in the browser in staging and development environments.

 

Version Discloser:

We should continue to restrict end users from knowing what version we used to develop the application because if an attacker learns what version the application was produced in, they might try to focus their attacks on that version that is made public.

Every time a browser submits an HTTP request to the server, the browser receives a response header with the following data.

server,

x-powered-by,

x-aspnet-version,

x-aspnetmvc-version,

x-sourcefiles

By including the code UseKestrel(c => c.AddServerHeader = false) in the CreateWebHostBuilder method of the Program.cs class, we can get rid of the server header. Also We must add a web configuration file and add the element to delete the X-Powered-By element under “system.webServer” in order to remove the X-Powered-By header.

 

Enforce SSL (Secure Socket Layer) and HSTS:

Secure Socket Layer, as its name suggests, creates a secure, encrypted connection between the client and the server. To preserve the integrity of the data, the requests that were sent from the client browser to the server end and the responses that were sent from the server end to the client browser would both be encrypted.

You can have your ASP.NET Core application secured using the HTTPS (HyperText Transfer Protocol Secure) protocol.

Applications configured over HTTPS can be readily created using ASP.net Core 2.1 and subsequent versions. Prior to the release of the.NET Core Framework 1.1, HTTPS could also be configured with ASP.NET Core, but it was a challenging process. 

 

Improper Authentication & Session management:

The majority of online applications feature modules for authentication, thus when writing this authentication code, we should take care. We frequently made mistakes throughout this process, such as failing to delete the authentication cookies after a successful logout. Attackers may gain access to the entire application and have a significant impact if they make this type of error, which enables them to steal user credentials such cookies and session information.

The following errors may enable data theft by attackers:

• Storing plain (unencrypted) credentials
• Use predictable login credentials
• Improper Application logs out
• Insecure connection (Without SSL)

How to avoid these mistakes?

• SSL provides cookie and session security.
• Cookie removal upon successful logout
• Protect cookies by configuring HTTP Only

 

File Upload Validation: 

Attackers will have many options to upload a script that is harmful and causes trouble using the file upload control. Therefore, we must always validate files in the right manner.

File extension expectations are the primary validation we perform on files. However, the uploader here has the option of changing the file extension. For instance, if you only permitted picture files, the attacker may submit the script by saving it with the.jpeg extension. In this instance, your validation allows the files by interpreting them for images while, in fact, they are malicious script files.

How can correct validation be done?

Check the file upload count first; if it’s zero, no files have been uploaded. Continue with additional validation if the upload count is more than 0.

Next, look at the file extension. This will only accept files with valid extension. Attacker may occasionally send a malicious file with a valid extension. Do additional validation in that situation.

Next, we must examine the file’s content type and bytes. Uploading a file is only permitted when the preceding three steps have been validated.

 

Conclusion:

I hope this post has given you the best security procedures to follow while developing web apps using the ASP.NET Core and MVC framework.