1. Introduction
Source Code Passive Disclosure occurs when a web server unintentionally reveals its underlying source code to clients. This is usually due to misconfiguration or errors in how the server handles code execution, meaning client-side users can view sensitive information like database credentials and application logic. Affected systems are typically any web applications using server-side scripting languages such as PHP, ASP, JSP, or similar technologies. A successful disclosure could compromise confidentiality, integrity, and availability of data and services.
2. Technical Explanation
The root cause is a server misconfiguration that prevents the correct execution of server-side code, resulting in its delivery to the client instead. Attackers typically discover these disclosures by requesting pages or endpoints where source code might be exposed due to errors or specific configurations. The Common Weakness Enumeration (CWE) identifier for this issue is 540. For example, an attacker could request a page with a syntax error in its PHP code, causing the server to return the unexecuted code as plain text.
- Root cause: Server-side code not being executed correctly due to configuration issues or syntax errors.
- Exploit mechanism: Attackers request pages that trigger source code disclosure through misconfiguration or error handling. A simple example is requesting a PHP file with an unclosed tag, which can reveal the entire script content.
- Scope: Web applications using server-side scripting languages (PHP, ASP, JSP) are affected. Specific versions depend on the web server and scripting engine configuration.
3. Detection and Assessment
Confirming vulnerability involves checking for server-side code in HTTP responses. A quick check is to attempt accessing a known PHP file with an intentional error. Thorough assessment requires scanning all application endpoints.
- Quick checks: Attempt to access a PHP file containing a syntax error, such as `example.php?error=1`. Look for server-side code in the response.
- Scanning: Use web vulnerability scanners like OWASP ZAP or Burp Suite with rules configured to detect source code disclosure. These tools may provide specific signatures for this issue.
- Logs and evidence: Examine web server logs (e.g., Apache access logs, IIS logs) for requests that return large amounts of text resembling source code. Look for error messages related to parsing or execution failures.
curl -I http://example.com/test.php?error=14. Solution / Remediation Steps
The solution is to ensure the server does not deliver server-side code to clients and correct any misconfigurations or errors in the server-side code.
4.1 Preparation
- Stop the web server service during configuration changes to prevent unexpected behaviour. A roll back plan involves restoring the backup or reverting the server snapshot.
4.2 Implementation
- Step 1: Review web server configuration files (e.g., Apache httpd.conf, Nginx nginx.conf) for any settings that might expose source code.
- Step 2: Check the application’s error handling routines to ensure they do not display raw source code in error messages.
- Step 3: Validate all server-side scripts for syntax errors and proper execution.
4.3 Config or Code Example
Before
After
4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue.
- Least privilege: Limit access to server-side code and configuration files to only authorized personnel, reducing the impact of a potential compromise.
- Secure error handling: Implement robust error handling that logs errors securely without exposing sensitive information to clients.
- Input validation: Ensure all user inputs are validated to prevent injection attacks that could lead to source code disclosure.
4.5 Automation (Optional)
Automation is not directly applicable for this vulnerability, as it requires configuration changes and code review.
5. Verification / Validation
Confirm the fix by attempting to access the same PHP file with an error that previously exposed source code. The response should no longer contain server-side code.
- Post-fix check: Attempt `curl -I http://example.com/test.php?error=1`. The HTTP response should not include any server-side code in the body or headers.
- Re-test: Re-run the scanner used earlier to confirm that no source code disclosure vulnerabilities are detected.
- Monitoring: Monitor web server logs for error messages related to parsing or execution failures. An alert can be set up if these errors exceed a certain threshold.
curl -I http://example.com/test.php?error=16. Preventive Measures and Monitoring
Preventive measures include regular security audits and code reviews.
- Baselines: Update web server configuration baselines to enforce secure settings that prevent source code disclosure.
- Asset and patch process: Implement a regular security review cycle for web application configurations and code changes.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 2: Changes to error handling routines might mask legitimate errors, making debugging more difficult. Mitigation involves careful logging and monitoring of error events.
8. References and Resources
Links to relevant resources.
- Vendor advisory or bulletin: N/A – This is a configuration issue rather than a specific product vulnerability.
- NVD or CVE entry: CWE-540
- Product or platform documentation relevant to the fix: Refer to your web server’s official documentation for secure configuration guidelines (e.g., Apache, Nginx, IIS).