Insecure Configuration

This vulnerability category covers the following issues:

• Framework Security Settings
• Cookie Flag Configuration

Framework Security Settings

About Insecure Configuration

What is Insecure Configuration?

Insecure configuration refers to the situation where a system or application is configured with settings or parameters that do not adequately protect it against security threats.

Examples of insecure configurations include using default or weak passwords, allowing open access to network ports, enabling unnecessary services or protocols, and misconfiguring access controls.

Insecure configuration can occur at any layer of the technology stack, including hardware, operating systems, applications, and network devices.

It is a common cause of security incidents and is often exploited by attackers who take advantage of misconfigured systems to gain access to sensitive information or carry out attacks.

Check out this video for a high-level explanation:

What is the impact of Insecure Configuration?

The impact of insecure configuration can lead to financial and reputational losses and potential harm to individuals or organizations.

Insecure configurations can leave systems and applications vulnerable to a variety of security threats, including unauthorized access, data breaches, and denial of service. Attackers can exploit insecure configurations to gain access to sensitive information, steal data, install malware or ransomware, or disrupt services.

In addition to the direct financial and operational costs of such attacks, insecure configurations can also result in lost business, damage to brand reputation, and legal or regulatory penalties.

Insecure configurations can also make it difficult for organizations to comply with security and privacy regulations, such as GDPR, HIPAA, and PCI DSS. Non-compliance with these regulations can result in significant fines, legal actions, and reputational damage.

How to prevent Insecure Configuration?

To prevent insecure configuration, it is important to follow security best practices and guidelines, such as those provided by industry standards like NIST or CIS, and to regularly review and update configurations to ensure they are up-to-date and properly secured.

Here are some specific steps you can take to prevent insecure configuration:

• Use secure defaults: Always change the default configuration settings of software and hardware devices to more secure settings, such as changing default passwords and disabling unnecessary services.
• Limit access: Implement the principle of least privilege and limit access to systems and applications only to authorized users who need it to perform their job duties.
• Apply security updates: Keep systems and applications up-to-date with the latest security patches and updates to protect against known vulnerabilities.
• Use security tools: Deploy security tools, such as vulnerability scanners and security information and event management (SIEM) systems, to monitor and manage system configurations.
• Enforce strong passwords: Require the use of strong passwords and two-factor authentication for accessing systems and applications.
• Follow security standards and frameworks: Implement security standards and frameworks, such as NIST or CIS, to ensure that your configurations adhere to industry best practices.
• Regularly review and audit configurations: Regularly review and audit system configurations to ensure they are properly secured and to identify and address any vulnerabilities or misconfigurations.

By taking these steps, you can significantly reduce the risk of insecure configuration and protect your systems and applications from security threats.

References

Taxonomies

• OWASP Top 10 - A05 Security Misconfiguration
• CWE-16: Use of GET Request Method With Sensitive Query Strings

Related CVEs

• CVE Details: CWE-16

Training

• Secure Code Warrior: OWASP Top 10 2017 - A06 Security Misconfiguration
• Secure Code Warrior: Security Misconfiguration - Disabled Security Features

Enabling Request Validation

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

Rule-specific 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/MR.

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/MR.

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/MR.

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.

Rule-specific 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/MR.

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.

Rule-specific 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/MR.

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.

Rule-specific 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/MR.

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

About Insecure Cookie Flags

What are insecure cookie flags?

HTTP cookies are small pieces of data that are sent from a website to a user's web browser and stored on the user's device. Cookies can be used for a variety of purposes, such as tracking user sessions, remembering user preferences, and serving targeted ads.

However, if cookies are not configured correctly, they can be vulnerable to attacks that can compromise the security of a website and the privacy of its users. One common vulnerability is the use of insecure cookie flags. Insecure cookie flags are settings that can be configured for a cookie to specify how the cookie should be transmitted and stored.

Some common insecure cookie flags include:

• "Secure" flag: This flag indicates that the cookie should only be transmitted over HTTPS connections. If the cookie is transmitted over an insecure HTTP connection, it can be intercepted by an attacker and used to impersonate the user.
• "HttpOnly" flag: This flag indicates that the cookie should not be accessible by client-side scripts, such as JavaScript. If the cookie is accessible to client-side scripts, it can be vulnerable to cross-site scripting (XSS) attacks.
• "SameSite" flag: This flag indicates that the cookie should only be sent in requests that originate from the same site as the one that set the cookie. If the cookie is sent in requests from other sites, it can be vulnerable to cross-site request forgery (CSRF) attacks.

Check out this video for a high-level explanation:

What is the impact of insecure cookie flags?

Some of the potential consequences of using insecure cookie flags are:

• Session hijacking: If cookies are not configured with the "Secure" flag, they can be intercepted by an attacker and used to hijack a user's session. An attacker can use the stolen cookie to impersonate the user and access sensitive information or perform unauthorized actions on the website.
• Cross-site scripting (XSS) attacks: If cookies are not configured with the "HttpOnly" flag, they can be accessed by client-side scripts, such as JavaScript. This makes the cookie vulnerable to XSS attacks, where an attacker can inject malicious code into a website and steal the cookie.
• Cross-site request forgery (CSRF) attacks: If cookies are not configured with the "SameSite" flag, they can be sent in requests from other sites. This makes the cookie vulnerable to CSRF attacks, where an attacker can trick a user into unknowingly performing an action on the website that the user did not intend to perform.
• Data breaches: If cookies contain sensitive information, such as login credentials or personal data, they can be exposed in a data breach. If the cookie is not configured with the "Secure" flag, the data can be intercepted by an attacker and used for malicious purposes.

How to prevent insecure cookie flags?

The best practices to follow for secure cookie flags are:

• Set the "Secure" flag: This flag ensures that cookies are only transmitted over HTTPS connections. This prevents cookies from being intercepted by attackers and helps prevent session hijacking attacks. Ensure that all cookies that contain sensitive information or are used for session management are configured with the "Secure" flag.
• Set the "HttpOnly" flag: This flag ensures that cookies are not accessible by client-side scripts, such as JavaScript. This prevents cookies from being vulnerable to cross-site scripting (XSS) attacks. Ensure that all cookies that contain sensitive information are configured with the "HttpOnly" flag.
• Set the "SameSite" flag: This flag ensures that cookies are only sent in requests that originate from the same site as the one that set the cookie. This prevents cookies from being vulnerable to cross-site request forgery (CSRF) attacks. Ensure that all cookies that are used for session management or perform actions on behalf of the user are configured with the "SameSite" flag.
• Use a secure cookie storage mechanism: Ensure that cookies are stored securely on the user's device and are not accessible to other applications or users. Use a secure cookie storage mechanism, such as HttpOnly cookies, to prevent cookies from being accessed or modified by attackers. Regularly review and update cookie settings: Regularly review and update cookie settings to ensure that they are up-to-date with the latest best practices and security recommendations. Ensure that all cookies are configured with the appropriate secure flags and that any cookies that are no longer needed are deleted.

References

Taxonomies

• OWASP Top 10 - A05 Security Misconfiguration
• CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag
• CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

Explanation & Prevention

• OWASP: Secure Flag
• OWASP: HttpOnly

Related CVEs

• CVE Details: CWE-1004
• CVE Details: CWE-614

Training

• Secure Code Warrior: OWASP Top 10 2017 - A06 Security Misconfiguration
• Secure Code Warrior: Security Misconfiguration - Disabled Security Features

Option A: Set HTTPOnly and Secure Cookie Flags

1. Go through the issues that GuardRails identified in the PR/MR.

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 🌴