Hackernoon logoOWASP Top 10 .NET Protection Guide (Part 2) by@wownetort

OWASP Top 10 .NET Protection Guide (Part 2)

Nikita Starichenko Hacker Noon profile picture

@wownetortNikita Starichenko

7+ years full-stack developer

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

In this article, I want to cover the second part of the TOP 10 vulnerabilities and how to protect against them using .NET.

6. Security Misconfiguration

Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage. Such flaws frequently give attackers unauthorized access to some system data or functionality.

What to do?

  1. (When using TLS) Redirect a request made over Http to https:
  2. //Startup.cs
  3. Send the anti-forgery token with every POST/PUT request:

    To automatically validate all requests other than GET, HEAD, OPTIONS and TRACE you need to add a global action filter with the AutoValidateAntiforgeryToken attribute inside your Startup.cs
  4. services.AddMvc(options =>
        options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute());

    If you need to also validate the token on GET, HEAD, OPTIONS or TRACE - requests you can add the ValidateAntiforgeryToken attribute to the controller method (for MVC controllers) or parent class (for Razor pages):

    public IActionResult DoSomethingDangerous()
    public class SafeModel : PageModel

    In case you can't use a global action filter, add the AutoValidateAntiforgeryToken attribute to your controller classes or razor page models:

    public class UserController
    public class SafeModel : PageModel

7. Cross-Site Scripting (XSS)

XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two-thirds of all applications. The impact of XSS is moderate for reflected and DOM XSS, and severe for stored XSS, with remote code execution on the victim’s browser, such as stealing credentials, sessions, or delivering malware to the victim.

What to do?

  1. DO NOT: Trust any data the user sends you, prefer white lists (always safe) over black lists
  2. DO NOT: Use the [AllowHTML] attribute or helper class @Html.Raw unless you really know that the content you are writing to the browser is safe and has been escaped properly.

8. Insecure Deserialization

The impact of deserialization flaws cannot be overstated. These flaws can lead to remote code execution attacks, one of the most serious attacks possible.

What to do?

  1. Validate User Input Malicious users are able to use objects like cookies to insert malicious information to change user roles. In some cases, hackers are able to elevate their privileges to administrator rights by using a pre-existing or cached password hash from a previous session.
  2. Prevent Deserialization of Domain Objects
  3. Run the Deserialization Code with Limited Access Permissions If a deserialized hostile object tries to initiate a system processes or access a resource within the server or the host's OS, it will be denied access and a permission flag will be raised so that a system administrator is made aware of any anomalous activity on the server.
  4. Don't allow the datastream to define the type of object that the stream will be deserialized to. You can prevent this by for example using the DataContractSerializer or XmlSerializer if at all possible.
  5. Where JSON.Net is being used make sure the TypeNameHandling is only set to None.
  6. TypeNameHandling = TypeNameHandling.None
  7. If JavaScriptSerializer is to be used then do not use it with a JavaScriptTypeResolver.
  8. If you must deserialise data streams that define their own type, then restrict the types that are allowed to be deserialized. One should be aware that this is still risky as many native .Net types potentially dangerous in themselves.

9. Using Components with Known Vulnerabilities

Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date. While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components.

What to do?

  1. Keep the .Net framework updated with the latest patches
  2. Keep your NuGet packages up to date, many will contain their own vulnerabilities.
  3. Run the OWASP Dependency Checker against your application as part of your build process and act on any high level vulnerabilities.

10. Insufficient Logging & Monitoring

Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected. Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100%.

What to do?

  1. Ensure all login, access control failures and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts.
  2. Establish effective monitoring and alerting so suspicious activities are detected and responded to in a timely fashion.
  3. Log all errors from the Startup.cs, so that anytime an error is thrown it will be logged.
  4. public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        if (env.IsDevelopment())
            _isDevelopment = true;
        //Log all errors in the application
        app.UseExceptionHandler(errorApp =>
            errorApp.Run(async context =>
                var errorFeature = context.Features.Get<IExceptionHandlerFeature>();
                var exception = errorFeature.Error;
                Log.Error(String.Format("Stacktrace of error: {0}", exception.StackTrace.ToString()));
  5. Monitor key performance indicators. In .NET a great option to add monitoring capabilities is Application Insights.

Thanks for reading!

Part one - https://hackernoon.com/owasp-top-10-net-protection-a-guide-part-1-w92r3wis

Read more about OWASP - https://owasp.org/www-project-top-ten/


Join Hacker Noon

Create your free account to unlock your custom reading experience.