Insecure Configuration
This vulnerability category covers the following issues:
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:
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:
Option A: Ensure validation is only enabled for testing environments
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;
- And add the following check:
#if DEBUG
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;
#endif
- 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:
Option A: Ensure Request Validation is Enabled on the Controller Level
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
public class TestController
{
[HttpPost]
[ValidateInput(false)]
public ActionResult ControllerMethod(string input) {
return f(input);
}
}
- And change it to:
public class TestController
{
[HttpPost]
public ActionResult ControllerMethod(string input) {
return f(input);
}
}
- Test it, ship it 🚢 and relax 🌴
Option B: Ensure Request Validation is Enabled Globally
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
<system.web>
...
<pages [..] validateRequest="false" [..]/>
...
</system.web>
- And change it to:
<system.web>
...
<pages [..] validateRequest="true" [..]/>
...
</system.web>
- Test it, ship it 🚢 and relax 🌴
Option C: Ensure Request Validation is Not Only Enabled For Pages
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
<system.web>
...
<httpRuntime [..] requestValidationMode="2.0" [..]/>
...
</system.web>
- And change it to:
<system.web>
...
<httpRuntime [..] requestValidationMode="4.5" [..]/>
...
</system.web>
- 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:
Option A: Ensure Event Validation is Enabled Globally
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
<system.web>
...
<pages [..] enableEventValidation="false" [..]/>
...
</system.web>
- And change it to:
<system.web>
...
<pages [..] enableEventValidation="true" [..]/>
...
</system.web>
- 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
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
<system.web>
...
<pages [..] viewStateEncryptionMode="Auto" [..]/>
...
</system.web>
or:
<system.web>
...
<pages [..] viewStateEncryptionMode="Never" [..]/>
...
</system.web>
- And change it to:
<system.web>
...
<pages [..] viewStateEncryptionMode="Always" [..]/>
...
</system.web>
- 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:
Option A: Ensure that the enableViewStateMac is Set to True
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
<system.web>
...
<pages [..] enableViewStateMac="false" [..]/>
...
</system.web>
- And change it to:
<system.web>
...
<pages [..] enableViewStateMac="true" [..]/>
...
</system.web>
- 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
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
<httpCookies requireSSL="false" httpOnlyCookies="false" [..] />
- And modify it to either
<httpCookies requireSSL="true" httpOnlyCookies="true" [..] />
or:
var cookie = new HttpCookie("test");
cookie.Secure = true;
cookie.HttpOnly = true;
- 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:
Fixing Cross-Site Request Forgery
Option A: Verify the AntiForgeryToken
A CSRF can occur when a controller does not leverage the
ValidateAntiForgeryToken
annotation.
- Go through the issues that GuardRails identified in the PR.
- Locate the following pattern:
public class TestController
{
[HttpPost]
public ActionResult ControllerMethod(string input)
{
//Do an action in the context of the logged in user
}
}
- 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
}
}
- Test it
- Ship it 🚢 and relax 🌴