How to remediate – web.config File Information Disclosure

1. Introduction

The web.config File Information Disclosure vulnerability affects applications hosting a web server configuration file. This allows an attacker to view sensitive information about how the application is set up, potentially aiding further attacks. Systems running IIS and using ASP.NET are commonly affected. Confidentiality may be impacted due to exposure of database credentials or API keys.

2. Technical Explanation

This vulnerability occurs because the web.config file is directly accessible via a simple HTTP request. An unauthenticated attacker can request this file and view its contents. No special privileges are needed for exploitation.

• Root cause: The web server does not restrict access to the web.config file.
• Exploit mechanism: An attacker sends an HTTP GET request to the location of the web.config file, typically at /web.config or in the root directory of the application. For example, http://example.com/web.config.
• Scope: IIS web servers running ASP.NET applications are affected. The vulnerability is present across multiple versions if default configurations are used.

3. Detection and Assessment

You can check for this vulnerability by attempting to access the web.config file directly. A thorough assessment involves scanning your web application with a vulnerability scanner.

• Quick checks: Use a web browser or curl command to request the /web.config file from your web server. If you receive the contents of the file, the system is vulnerable.
• Scanning: Nessus plugin ID 38965 and OpenVAS scanner script family ‘http’ can detect this issue as examples only.
• Logs and evidence: Check IIS logs for GET requests to /web.config or similar paths. Look for status code 200 (OK) responses.

curl -I http://example.com/web.config

4. Solution / Remediation Steps

To fix this issue, restrict access to the web.config file or remove it if not required.

4.1 Preparation

• Ensure you have administrator privileges on the server. A roll back plan is to restore from the previous backup.
• A change window may be needed depending on service impact. Approval from a senior IT team member may be required.

4.2 Implementation

1. Step 1: Open IIS Manager.
2. Step 2: Navigate to the website affected by this vulnerability.
3. Step 3: Double-click “Configuration”.
4. Step 4: In the Features View, double-click “Request Filtering”.
5. Step 5: Click “Hidden Segments” in the Actions pane on the right.
6. Step 6: Add “/web.config” to the list of hidden segments.
7. Step 7: Restart the website.

4.3 Config or Code Example

Before

<system.webServer> ... </system.webServer>

After

<system.webServer> <modules> <remove name="HiddenSegmentsModule" /> <add name="HiddenSegmentsModule" type="System.Web.Configuration.HiddenSegmentsModule, System.Web.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d0a9c3" /> </modules> ... </system.webServer>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact if an attacker gains access. Input validation is not directly applicable here, but is a good general practice. Secure defaults are important for web server configurations.

• Practice 1: Implement least privilege principles to limit the potential damage from compromised accounts.
• Practice 2: Regularly review and harden your web server configuration against known vulnerabilities.

4.5 Automation (Optional)

PowerShell can be used to add hidden segments via IIS administration cmdlets, but requires careful testing.

#Requires -Modules IISAdministration
Import-Module IISAdministration
$siteName = "YourWebsiteName"
Add-WebConfigurationProperty -Filter system.webServer/modules -PSPath IIS:Sites$siteName -Name hiddenSegments -Value @{collection.@xsi:type="ArrayOfHiddenSegment"} -Attributes 'name="/web.config"'

5. Verification / Validation

• Post-fix check: Use a web browser or curl command to request /web.config from your web server. You should receive a 403 (Forbidden) error, indicating access is denied.
• Re-test: Repeat the quick check described in Section 3. The file should no longer be accessible.
• Smoke test: Verify that users can still access key pages of the application and perform common tasks.
• Monitoring: Check IIS logs for failed GET requests to /web.config, which confirms the restriction is working as expected.

curl -I http://example.com/web.config

6. Preventive Measures and Monitoring

Regularly update your security baselines and policies to include restrictions on sensitive files like web.config. Incorporate vulnerability scanning into your CI/CD pipelines.

• Baselines: Update your IIS hardening baseline or CIS control configuration to explicitly deny access to the web.config file.
• Pipelines: Add static application security testing (SAST) tools to your build process to identify potential information disclosure vulnerabilities.
• Asset and patch process: Implement a regular patch review cycle for your web server software and applications.

7. Risks, Side Effects, and Roll Back

Restricting access to the web.config file could potentially break some custom application functionality if it relies on direct access. A roll back involves removing the hidden segment configuration in IIS Manager.

• Risk or side effect 2: Incorrectly configured request filtering rules could cause unexpected application errors.
• Roll back:
  1. Step 1: Open IIS Manager.
  2. Step 2: Navigate to the website affected by this vulnerability.
  3. Step 3: Double-click “Configuration”.
  4. Step 4: In the Features View, double-click “Request Filtering”.
  5. Step 5: Remove “/web.config” from the list of hidden segments.
  6. Step 6: Restart the website.

8. References and Resources

• Vendor advisory or bulletin: Updated on October 26, 2025