1. Home
  2. Web App Vulnerabilities
  3. How to remediate – Web.config File Information Disclosure
Searching...

How to remediate – Web.config File Information Disclosure

Contents

1. Introduction

The Web.config File Information Disclosure vulnerability allows an attacker to view sensitive configuration details stored in a web server’s Web.config file. This can expose database connection strings, API keys and other secrets, potentially leading to data breaches and system compromise. Systems running IIS web servers are typically affected. A successful exploit could lead to the disclosure of confidential information, impacting confidentiality.

2. Technical Explanation

The vulnerability occurs when a web server is configured to allow direct access to its Web.config file. An unauthenticated attacker can request this file via a simple HTTP GET request and receive its contents. The primary root cause is improper restrictions on accessing configuration files. Exploitation requires only network connectivity to the affected web server. A typical attack involves sending an HTTP GET request to the path of the Web.config file, for example http://example.com/web.config.

  • Root cause: Lack of proper access controls on the Web.config file.
  • Exploit mechanism: An attacker sends a standard HTTP GET request to retrieve the Web.config file.
  • Scope: IIS web servers are affected. Specific versions were noted in OWASP documentation (see section 8).

3. Detection and Assessment

You can confirm vulnerability by attempting to directly access the Web.config file. A thorough assessment involves scanning for accessible configuration files across your web estate.

  • Quick checks: Use a web browser or command-line tool like curl to request the Web.config file from target servers.
  • Scanning: Nessus plugin ID 38965 and OpenVAS scanner family “Web Server Configuration” may identify this issue, but results should be verified manually.
  • Logs and evidence: Check web server logs for GET requests targeting /web.config or similar paths. Look for HTTP status code 200 (OK) responses to these requests.
curl -I http://example.com/web.config

4. Solution / Remediation Steps

The following steps will help fix the issue. Ensure proper restrictions are in place, or remove the file if it is not required.

4.1 Preparation

  • Ensure you have access to IIS Manager and appropriate permissions. A roll back plan involves restoring the Web.config file from backup.
  • Changes should be made during a scheduled maintenance window with approval from relevant stakeholders.

4.2 Implementation

  1. Step 1: Open IIS Manager on the affected server.
  2. Step 2: Navigate to the website in question.
  3. Step 3: Double-click “Handler Mappings” in the features view.
  4. Step 4: Locate and remove any handler mapping that allows access to static files with a .config extension.
  5. Step 5: In IIS Manager, navigate to the website’s root directory.
  6. Step 6: Open “Features View” then double-click “Directory Browsing”.
  7. Step 7: Ensure Directory Browsing is disabled.

4.3 Config or Code Example

Before

<system.webServer> <modules> <module name="StaticFileModule" type="System.Web.Handlers.StaticFileHandler, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d0a9c3" /> </modules> </system.webServer>

After

<system.webServer> <modules> <remove name="StaticFileModule" /> </modules> </system.webServer>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

  • Practice 1: Least privilege access control – limit user permissions to only what is necessary, reducing the impact of a potential compromise.
  • Practice 2: Secure defaults – configure systems with restrictive settings by default, preventing unintended exposure of sensitive information.

4.5 Automation (Optional)

PowerShell can be used to check and disable directory browsing.

# Check if Directory Browsing is enabled
$websiteName = "YourWebsiteName"
$iisSite = Get-WebConfiguration -Filter xpath "//system.webServer/directoryBrowsing" -PSPath IIS:Sites$websiteName
if ($iisSite.directoryBrowsing.enabled -eq $true) {
    Write-Host "Directory Browsing is enabled for '$websiteName'. Disabling..."
    # Disable Directory Browsing
    Set-WebConfigurationProperty -Filter xpath "//system.webServer/directoryBrowsing" -PSPath IIS:Sites$websiteName -Value @{enabled=$false}
    Write-Host "Directory Browsing disabled."
} else {
    Write-Host "Directory Browsing is already disabled for '$websiteName'."
}

5. Verification / Validation

  • Post-fix check: Use a web browser or curl to request the Web.config file. You should receive an HTTP 403 (Forbidden) error.
  • Re-test: Repeat the quick check from section 3. The server should no longer return the contents of the Web.config file.
  • Monitoring: Monitor web server logs for any attempts to access /web.config or similar paths. An alert could be triggered if such requests are detected.
curl -I http://example.com/web.config

6. Preventive Measures and Monitoring

Regular security assessments and patching can help prevent this issue.

  • Baselines: Update your IIS server baseline configuration to include restrictions on accessing configuration files.
  • Asset and patch process: Implement a regular patch management cycle for all servers, including timely installation of security updates.

7. Risks, Side Effects, and Roll Back

Removing handler mappings or disabling directory browsing could potentially impact other website functionality if not carefully configured.

  • Risk or side effect 2: Incorrectly configured restrictions could cause unexpected errors on the website.
  • Roll back: Restore the Web.config file from backup if issues occur. Re-enable handler mappings and directory browsing if necessary, then test functionality.

8. References and Resources

Links to resources related to this vulnerability.

Was this article helpful?

Yes No

Related Articles