The security of.NET applications is required, and knowing how to protect them is not always
easy. As developers, we must understand that an insecure application can cause serious issues
ranging from modifying the application’s operation or stealing the source code to exposing a
company to legal liability.
Each developer clearly applies the security that he believes is appropriate for his applications,
and I’d like to add that the possibilities and methods for doing so are limitless.
However, when developing a.NET application, any developer should always adhere to a set of
best practises. Following these best practises will help to keep your application secure. And it is
for this reason that I have decided to compile the 5 commandments of .NET application
security.
1. When you log out, you must delete all cookies.
We use sessions to keep users logged in across visits. There is no session timeout setting on
some login pages if you check a box and choose not to sign out. The AspNetCore all at once.
The browser stores a session cookie to keep track of the currently logged-in user.
Remember to delete the Cookies your application has created when logging out, as a Hacker may
be able to use them in an unauthorised login.
If we want to overwrite the default cookie session, we can use SessionOptions as follows:
Builder.Services.Addsession(option =>
{
option.cookie.Name = “.AdventureWorks.Session”;
option.IdleTimeout = TimeSpan.FromSeconds (10);
option.Cookie.InsEssential = true;
} };
The options used are used for:
Cookie: Determine the settings used to create the cookie.
Cookie: Determine the settings used to create the cookie.
IdleTimeout: Indicate how long the session can be left idle before its contents are deleted.
IOTimeout: Indicate the maximum amount of time that can be spent loading a session from the store or committing it back to the store.
2. XSS injections will stay with you forever.
XSS is a vulnerability that allows an attacker to inject client-side scripts into web pages.
When you visit an affected page, the attacker’s scripts will run, allowing them to steal your session tokens and cookies, change the content of the web page via DOM manipulation, or even redirect you away from your intended destination. When an application takes user input and outputs it to unvalidated pages, a Cross Site Scripting Vulnerability occurs.
This type of attack is typically carried out in the following locations:
- HTTP Headers
- Form Inputs
- URL Query Strings
The first approach is to use proper HTTP headers. The X-XSS-Protection HTTP header causes the browser to enable a script filter. Certain XSS attacks that can occur between sites will be prevented by this filter. This is one method.
This will activate the XSS filter, which will sanitise the page and remove any unsafe elements:
X-XSS-Protection: 1;
It is also possible in this manner. Adding mode=block enables XSS filtering, which, if an attack is detected, will directly prevent the page from being displayed rather than sanitizing it:
X-XSS-Protection: 1; mode=block;
Let’s look at the proper and incorrect ways to do this:
In a bad way:
If you look closely, you’ll notice that the data sent has the potential to be executed.
document.getElementById(“id”).innerHTML = “user data”;
Excellent method:
In this manner, any data entered will be interpreted as plain text, and no amount of code injection
will be possible:
document.getElementById(“id”).textContent = “user data”;
3. You must avoid making direct connections to databases.
It is obvious that we will frequently need to connect our application to a database. One of these
approaches is to use a connector for our application.
The issue arises when that connector is in plain text, as shown in the following example:
string connectionString =
“datasource=day.bytehide.com;
port=3306;
username=root;
password=secret;
database=test;’;
MySqlConnection databaseConnection = new MySqulConnection { connectionString};
This method is completely unsafe. We can clearly see that sensitive data, such as the server, username, port, or password, is accessible to anyone with access to our application.
If you’re looking for some quick fixes, here are a few ideas that might work:
- Don’t use Universal Data Link (UDL) files
- Use Azure Key Vault Secret
- Encrypt the configuration files
- Use Windows Authentication
4. You must not store sensitive data in your databases.
A database is required for almost every web application to store user data. Hackers, on the other hand, will always try to steal user data from databases, even if it means attacking servers and gaining unauthorized access. If someone gains unauthorized access to your database, they can exploit it by stealing any sensitive information they find there, such as passwords and credit card information.
This may appear to be a joke, but I still see databases that store passwords in plain text, so this is a commandment.
To accomplish this, sensitive information must be encrypted so that it is not stored in plain text in the database. Regardless, standard encryption may fall short of password protection. In the case of sensitive data, hashing the information and then verifying it without the need for decryption keys ensures that the original information cannot be reversed.
5. You must always deal with errors.
Errors in application development are something that no one wants to happen, but they always do. They are nearly impossible to avoid, but when they do occur, you must be prepared to deal with them appropriately. If this is not done, errors may cause internal information to leak, which is not a good thing.
One possible solution would be to keep a record of the exception stack at all times. It is preferable to use throw; rather than throw e; because the latter will return an empty string in production.
try
{
FunctionThatMightThrow();
}
catch (Exception error)
{
logger.LogInfo (error);
throw new CustomException (error);
}
Another viable and effective method would be to always analyse the detected errors.
If you find an error, please do not ignore it or simply ignore it without correcting it. There is no point in doing so because you will never be able to solve the problem. If you know that errors are possible and want to prevent them from occurring, use a try/catch block in code where they might occur.
try
{
FunctionThatMightThro();
}
catch (Exception error)
{
NotifyUserOfError(error); //Another option
ReportErrorToService(error);
}