How to remediate – Web Application Description Language (WADL) File Detected

1. Introduction

A Web Application Description Language (WADL) file has been detected on a URL under your control. WADL is an XML-based language used to describe RESTful web services. Its presence isn’t inherently malicious, but it can expose details about your application’s structure and functionality to potential attackers. This typically affects applications using REST APIs. A successful exploit could lead to information disclosure.

2. Technical Explanation

The detection of a WADL file indicates that the web service is publishing a description of its API endpoints. Attackers can use this to understand how the application works, identify potential vulnerabilities and craft targeted attacks. There isn’t a specific CVE associated with simply *having* a WADL file; the risk comes from information exposure. An attacker could download the WADL file to map out all available resources and methods.

• Root cause: The web service is configured to serve a WADL file, often for documentation or tooling purposes.
• Exploit mechanism: An attacker downloads and parses the WADL file to identify API endpoints, parameters, and data structures. They then use this information to craft malicious requests. For example, they might discover an endpoint without proper authentication checks.
• Scope: RESTful web services built with various technologies (Java, Python, .NET) are affected if configured to publish a WADL file.

3. Detection and Assessment

Confirming the presence of a WADL file is straightforward. You can also check for publicly accessible WADL files using automated scanning tools.

• Quick checks: Access the URL in a web browser. If a WADL file exists, you will see an XML document displayed or be prompted to download it.
• Scanning: Nessus plugin ID 16284 can identify exposed WADL files as an example.
• Logs and evidence: Web server logs may show requests for the WADL file (e.g., a request ending in .wadl). Check access logs for your web servers.

curl -I /application.wadl

4. Solution / Remediation Steps

The best solution is to remove the WADL file if it’s not actively required. If needed, restrict access to authorized users only.

4.1 Preparation

• Ensure you have a clear understanding of which services rely on the WADL file, and plan for potential impact. A roll back plan is to restore the original configuration from backup.
• Change windows may be required depending on your operational procedures. Approval from the application owner might be needed.

4.2 Implementation

1. Step 1: Remove the WADL file from the web server’s document root or public directory.
2. Step 2: If removal isn’t possible, configure your web server to restrict access to the WADL file using IP address filtering or authentication.
3. Step 3: Restart the web service to apply the changes.

4.3 Config or Code Example

Before

# Apache configuration allowing access to WADL file
<Directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

After

# Apache configuration restricting access to WADL file
<Directory /var/www/html>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require ip 127.0.0.1  # Allow only localhost
</Directory>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help mitigate the risks associated with WADL files.

• Practice 1: Least privilege – restrict access to sensitive resources like API documentation and configuration files.

4.5 Automation (Optional)

# Example Bash script to remove WADL file
#!/bin/bash
WADL_FILE="/var/www/html/application.wadl"
if [ -f "$WADL_FILE" ]; then
  rm "$WADL_FILE"
  echo "WADL file removed."
else
  echo "WADL file not found."
fi

5. Verification / Validation

• Post-fix check: Access the URL in a web browser. You should receive a 403 Forbidden or 404 Not Found error.
• Re-test: Re-run the curl command from the detection section; it should no longer return an XML document.
• Monitoring: Check web server logs for access attempts to the WADL file and alert if any unauthorized requests occur.

curl -I /application.wadl

6. Preventive Measures and Monitoring

Regularly review your application’s configuration and security policies.

• Baselines: Update your web server baseline to include restrictions on access to sensitive files like WADL documents.
• Pipelines: Implement static code analysis (SAST) tools in your CI/CD pipeline to identify potential exposure of API documentation.
• Asset and patch process: Review application configurations during regular security audits.

7. Risks, Side Effects, and Roll Back

Removing or restricting access to a WADL file could impact applications that rely on it for documentation or tooling.

• Risk or side effect 1: Applications using the WADL file for automated API testing may break if access is restricted.
• Risk or side effect 2: Developers relying on the WADL file for understanding the API structure might experience temporary disruption.
• Roll back: Restore the original configuration from backup, including the WADL file and its associated web server settings.

8. References and Resources

Link only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: N/A – This is a configuration issue, not a specific vendor flaw.
• NVD or CVE entry: N/A – No specific CVE for WADL file exposure.
• Product or platform documentation relevant to the fix: https://www.w3.org/Submission/wadl/