Insecure Configuration

This vulnerability category covers the following issues:

• Framework Security Settings
• Cookie Flag Configuration
• Cross-Site Request Forgery

Why is this important?

Dotnet mostly adheres to secure defaults, but there are ways to introduce configuration issues.

Check out this video for a high-level explanation on the topic:

More information:

• OWASP Top 10 - A6 Security Misconfiguration

Framework Security Settings

Enabling Certificate Validation

Disabling certificate validation is often used to connect easily to a host that is not signed by a trusted root certificate authority. This creates opportunities for Man-in-the-middle attacks as the client will trust any certificate. In addition to the option listed below, certificate pinning or properly signed certificates can be leveraged for development environments.

References:

• WASC-04: Insufficient Transport Layer Protection
• CWE-295: Improper Certificate Validation

Option A: Ensure validation is only enabled for testing environments

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;

3. And add the following check:

#if DEBUG
  ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;
#endif

4. Test it, ship it 🚢 and relax 🌴

Enabling Request Validation

Request validation allows the filtering of some Cross-Site Scripting (XSS) attack vectors passed to the application.

References:

• MSDN: Request Validation in ASP.NET
• OWASP: ASP.NET Request Validation

Option A: Ensure Request Validation is Enabled on the Controller Level

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

public class TestController
{
    [HttpPost]
    [ValidateInput(false)]
    public ActionResult ControllerMethod(string input) {
        return f(input);
    }
}

3. And change it to:

public class TestController
{
    [HttpPost]
    public ActionResult ControllerMethod(string input) {
        return f(input);
    }
}

4. Test it, ship it 🚢 and relax 🌴

Option B: Ensure Request Validation is Enabled Globally

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

<system.web>
   ...
   <pages [..] validateRequest="false" [..]/>
   ...
</system.web>

3. And change it to:

<system.web>
   ...
   <pages [..] validateRequest="true" [..]/>
   ...
</system.web>

4. Test it, ship it 🚢 and relax 🌴

Option C: Ensure Request Validation is Not Only Enabled For Pages

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

<system.web>
   ...
   <httpRuntime [..] requestValidationMode="2.0" [..]/>
   ...
</system.web>

3. And change it to:

<system.web>
   ...
   <httpRuntime [..] requestValidationMode="4.5" [..]/>
   ...
</system.web>

4. Test it, ship it 🚢 and relax 🌴

Enabling Event Validation

Request validation allows the filtering of some Cross-Site Scripting (XSS) attack vectors passed to the application. Event validation reduces the risk of unauthorized or malicious post-back requests and callbacks. When the EnableEventValidation property is set to true, ASP.NET validates that a control event originated from the user interface that was rendered by that control.

References:

• MSDN: pages Element (ASP.NET Settings Schema)
• MSDN: Page.EnableEventValidation Property

Option A: Ensure Event Validation is Enabled Globally

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

<system.web>
   ...
   <pages [..] enableEventValidation="false" [..]/>
   ...
</system.web>

3. And change it to:

<system.web>
   ...
   <pages [..] enableEventValidation="true" [..]/>
   ...
</system.web>

4. Test it, ship it 🚢 and relax 🌴

Encrypt View State

Web Forms controls use hidden base64 encoded fields to store state information. If sensitive information is stored there it may be leaked to the client side.

References:

• MSDN: pages Element (ASP.NET Settings Schema)
• MSDN: ViewStateEncryptionMode Property
• MSDN: machineKey Element (ASP.NET Settings Schema)

Option A: Ensure that the View State is Always Encrypted

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

<system.web>
   ...
   <pages [..] viewStateEncryptionMode="Auto" [..]/>
   ...
</system.web>

or:

<system.web>
   ...
   <pages [..] viewStateEncryptionMode="Never" [..]/>
   ...
</system.web>

3. And change it to:

<system.web>
   ...
   <pages [..] viewStateEncryptionMode="Always" [..]/>
   ...
</system.web>

4. Test it, ship it 🚢 and relax 🌴

Protect the View State

Web Forms controls use hidden base64 encoded fields to store state information. If the View State MAC is disabled it could be altered by an attacker.

References:

• MSDN: pages Element (ASP.NET Settings Schema)

Option A: Ensure that the enableViewStateMac is Set to True

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

<system.web>
   ...
   <pages [..] enableViewStateMac="false" [..]/>
   ...
</system.web>

3. And change it to:

<system.web>
   ...
   <pages [..] enableViewStateMac="true" [..]/>
   ...
</system.web>

4. Test it, ship it 🚢 and relax 🌴

Cookie Flag Configuration

Cookies support the secure and httpOnly flags. The Secure flag is a directive to the browser to make sure that the cookie is not sent over an unencrypted channel. The httpOnly flag prevents JavaScript to access its value. Which helps to reduce the risk of “Cross-Site Scripting” attacks.

References:

• CWE-614: Sensitive Cookie in HTTPS Session Without ‘Secure’ Attribute
• CWE-315: Cleartext Storage of Sensitive Information in a Cookie
• CWE-311: Missing Encryption of Sensitive Data
• OWASP: Secure Flag
• Rapid7: Missing Secure Flag From SSL Cookie
• Coding Horror blog: Protecting Your Cookies: HttpOnly
• OWASP: HttpOnly
• Rapid7: Missing HttpOnly Flag From Cookie

Option A: Set HTTPOnly and Secure Cookie Flags

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

<httpCookies requireSSL="false" httpOnlyCookies="false" [..] />

3. And modify it to either

<httpCookies requireSSL="true" httpOnlyCookies="true" [..] />

or:

var cookie = new HttpCookie("test");
cookie.Secure = true;
cookie.HttpOnly = true;

4. Test it, ship it 🚢 and relax 🌴

Cross-Site Request Forgery

In a Cross-Site Request Forgery (CSRF) attack, an untrusted application can cause a user's browser to submit requests or perform actions on the user's behalf.

References:

• OWASP: CSRF

Fixing Cross-Site Request Forgery

Option A: Verify the AntiForgeryToken

A CSRF can occur when a controller does not leverage the ValidateAntiForgeryToken annotation.

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following pattern:

public class TestController
{
    [HttpPost]
    public ActionResult ControllerMethod(string input)
    {
        //Do an action in the context of the logged in user
    }
}

3. And ensure that the AntiForgeryToken is verified

// In your view:
@Html.AntiForgeryToken()

//In your controller:
public class TestController
{
    [HttpPost]
    [ValidateAntiForgeryToken] //Annotation added
    public ActionResult ControllerMethod(string input)
    {
        //Do an action in the context of the logged in user
    }
}

4. Test it
5. Ship it 🚢 and relax 🌴