The internet is a dangerous place, hackers are always looking for new ways to break into your system and steal your data.
As a developer, you know how important it is to protect your application. If your app is hacked, it can be a big problem for you and your customers. With the increase in internet security breaches and cyber attacks, protecting your app has never been more essential.
To help prevent potential threats, I’m going to share some mistakes and how to avoid them to help you better protect your ASP.NET applications.
The 3+3 is that I am going to explain 3 common simple ones and 3 security ones. Let’s start with the most common ones
3 Common Mistakes made in ASP.NET
ToLower() in LINQ Query Doesn’t Work
ToLower function returns a lowercased duplicate of a string. When you try to compare numbers from multiple sources, though, this might result in a perplexing error. Consider the following example:
One approach is use
IndexOf only with case-insensitive
OrdinalIgnireCase attribute within the query instead of
Not Making Use of Dependency Injection
Assume our Controller requires a FooService to obtain a Foo that it may deliver to the user, as seen below:
The problem is that our Controller requires specifics on how to establish a FooService. That implies we’ll have to repeat that reasoning every time a FooService is required.
Dependency Injection is a built-in feature of ASP.NET 5 MVC 6. As a result, you may indicate the dependence in the constructor. The ASP.NET 5 framework would then submit it on our behalf.
Incorrect usage of the Var keyword
The misuse and abuse of the
var keyword is a common and fundamental problem. The true function of var is to allow us to declare a local variable when you don’t know what type it is. This is frequently the case with anonymous types because you don’t know what the type name is until compile time.
Nonetheless, some programmers use
var every time they define a variable. The type name in a local variable declaration adds another layer of description:
3 Security Mistakes made in ASP.NET
Storing Secrets inside Web.config
This stems from the desire to save time by storing cryptographic keys in a
web.config file. Here’s an example:
You should never keep secrets in a
web.config file. Therefore, you must redirect the code to a protected file, as seen below:
Request with Potentially Dangerous Consequences.Form Value
By default, we’ll get an error because ASP.NET MVC prevents this sort of code from being sent to the server in order to prevent Cross Site Scripting (XSS) attacks. Here’s a fix for an issue that occurs when you try to transmit HTML code to a server.
As demonstrated below, you may deactivate ASP.NET MVC validation for a specific field by using the AllowHtml attribute for the model class.
Not using to the client an XSRF token
Cross-site request forgeries are prevented via XRSF tokens. You must utilize them whenever the browser can implicitly authenticate the user. This covers programs that use Windows authentication or use automated authentication using cookies.
Let’s see an example:
ASP.NET is a web development framework that can be either open-source or commercial. ASP.NET is used to create web pages, web applications, and XML Web Services.
Security is a major issue for many of the ASP.NET applications today because of the common vulnerabilities of SQL injection and Cross-site scripting (XSS).
Although it is difficult for a developer to make an error-free software product, these common security errors mentioned above can be easily avoided when developing ASP.NET applications.