Table of Contents
# The Hidden Dangers of `info.php.old` and How to Secure Your Server
In the world of web development and server administration, seemingly innocuous files can harbor significant security risks. One such culprit, often overlooked and forgotten, is `info.php.old`. This file, a relic of past debugging or system checks, can expose a treasure trove of sensitive server information to malicious actors, paving the way for targeted attacks.
This comprehensive guide will illuminate what `info.php.old` is, detail the severe security vulnerabilities it introduces, and provide actionable steps for identifying, remediating, and preventing its presence on your servers. By the end, you'll have a clear understanding of why this seemingly harmless file is a critical security blind spot and how to fortify your web infrastructure against it.
Understanding `info.php` and its "Old" Counterpart
To grasp the danger of `info.php.old`, we first need to understand its predecessor: `info.php`.
What is `phpinfo()`?
The `phpinfo()` function in PHP is a powerful diagnostic tool. When executed, it outputs a large HTML page containing a vast amount of information about the current PHP installation. This includes:
- **PHP Version and Configuration:** The exact PHP version, build date, and various configuration directives (e.g., `memory_limit`, `upload_max_filesize`).
- **Loaded Modules:** A list of all active PHP extensions (e.g., MySQLi, cURL, GD, OpenSSL).
- **Server Environment:** Details about the web server (Apache, Nginx, IIS), operating system, system hostname, and environment variables.
- **Path Information:** The full server path to the document root, temporary directories, and loaded configuration files.
- **Variable Information:** Details about `$_GET`, `$_POST`, `$_COOKIE`, `$_SERVER`, and `$_ENV` variables.
Developers frequently use `phpinfo()` during development or troubleshooting to verify PHP settings, check if modules are loaded correctly, or debug environmental issues. It's an invaluable tool for ensuring a script runs in the expected environment.
The Genesis of `info.php.old`
The `.old` suffix typically indicates a backup or a previously active file that has been renamed. `info.php.old` usually arises in a few common scenarios:
1. **Temporary Debugging:** A developer creates `info.php` (containing ``) on a production server for a quick check, then renames it to `info.php.old` with the intention of deleting it later, but forgets. 2. **System Updates/Migrations:** During server or application upgrades, existing files might be renamed as backups before new versions are deployed. If `info.php` was present, `info.php.old` could be created. 3. **Accidental Uploads:** In some cases, a development environment's `info.php` might accidentally be included in a deployment package and renamed upon a conflict or manual intervention. The key problem is that these "old" files, despite their `.old` extension, are often still accessible via a web browser if they reside within the web root (e.g., `public_html`, `www`, `htdocs`). If a web server is configured to serve `.php` files, it might also serve files with a `.old` extension, treating them as plain text or, in some misconfigurations, even attempting to execute them if the PHP handler is too broad. Even if not executed, revealing the source code of `info.php.old` (which is just ``) is enough to trigger the `phpinfo()` output.The Grave Security Risks of `info.php.old`
The continued presence of `info.php.old` on a live server is a severe security oversight, primarily due to information disclosure.
Information Disclosure Vulnerability
Attackers thrive on information. An `info.php.old` file provides a detailed blueprint of your server's configuration and software environment, allowing them to:
- **Identify PHP Version:** Knowing the exact PHP version (e.g., PHP 7.4.3) allows attackers to search for known Common Vulnerabilities and Exposures (CVEs) specific to that version. An outdated PHP version with known exploits becomes a direct target.
- **Discover Server OS and Architecture:** Reveals if the server is running Linux, Windows, or another OS, along with its architecture (e.g., x86_64). This helps attackers tailor exploits for the specific environment.
- **Expose Loaded Modules:** A list of loaded PHP extensions (e.g., `pdo_mysql`, `curl`, `json`) indicates potential functionalities and libraries that might have their own vulnerabilities.
- **Uncover Environment Variables:** While direct database credentials or API keys are rarely exposed *directly* by `phpinfo()` unless misconfigured, paths to configuration files, temporary directories, and other sensitive system variables are often revealed. These paths can be crucial for directory traversal or local file inclusion attacks.
- **Reveal Full Server Path:** Knowing the absolute path to your document root (e.g., `/var/www/html/mysite.com/public_html`) is invaluable for attackers attempting path manipulation, file uploads, or exploiting file inclusion vulnerabilities.
- **Internal IP Addresses:** In some network configurations, `phpinfo()` might display internal IP addresses, helping an attacker map out your internal network if they gain initial access.
Facilitating Other Attacks
The information gleaned from `info.php.old` isn't an attack itself, but it acts as potent reconnaissance, significantly lowering the bar for subsequent attacks:
- **Targeted Exploitation:** With PHP version and module details, an attacker can quickly find and deploy public exploits (e.g., an RCE exploit for an old PHP version or a vulnerability in a specific loaded extension).
- **Local File Inclusion (LFI) / Remote File Inclusion (RFI):** Knowing server paths and temporary file locations makes LFI/RFI attempts much more precise and likely to succeed.
- **Social Engineering:** While less direct, specific server details can sometimes be used to craft more convincing phishing attempts against administrators.
- **Bypassing Security Measures:** Information about disabled functions or `open_basedir` settings can help attackers craft payloads designed to bypass these restrictions.
Identifying and Locating `info.php.old` Files
Given the risks, the first step is to identify if these files exist on your servers.
Manual Server Inspection
For administrators with SSH or FTP/SFTP access, manual inspection is a straightforward method:
- **SSH Command Line:**
- Navigate to your web server's document root (e.g., `/var/www/html/` or `/home/user/public_html/`).
- Use the `find` command to search for suspicious files:
- Combine these for a more comprehensive search:
- **FTP/SFTP Clients:** Browse through your web directories visually. Look for files named `info.php.old`, `phpinfo.php.old`, `test.php.old`, or anything similar with `.old` or `.bak` extensions. Remember to check subdirectories.
Automated Scanning Tools
For larger environments or continuous monitoring, automated tools are indispensable:
- **Web Vulnerability Scanners:** Tools like OWASP ZAP, Nessus, Acunetix, Burp Suite, or even free online scanners (use with caution and only on your own servers) can crawl your website and often detect these files by attempting to access common filenames.
- **Command-Line Tools:** You can script `curl` or `wget` to check for common `info.php.old` variations:
- **Google Dorks:** While not a "scanning tool" for your *own* server, attackers use Google Dorks to find these files publicly. For instance, `site:yourdomain.com inurl:info.php.old` might reveal if Google has indexed such a file on your site. This is a good way to check if your server's exposed files are already publicly discoverable.
Remediation: Safely Handling `info.php.old`
Once identified, prompt action is crucial.
The Golden Rule: Delete Immediately
For any file named `info.php.old` (or `phpinfo.php.old`, `test.php.old`, etc.) found within your web root, the primary and most effective remediation is **immediate and permanent deletion**.
- **Why Delete?** These files serve no legitimate purpose on a production web server. They are remnants that only pose a risk. Deleting them removes the vulnerability entirely.
- **How to Delete:**
- **SSH:** `rm /path/to/your/webroot/info.php.old`
- **FTP/SFTP:** Right-click and choose "Delete" or "Remove."
- **Verification:** After deletion, try accessing the URL (e.g., `https://yourdomain.com/info.php.old`) in a browser. You should receive a 404 Not Found error.
Alternative: Restricting Access (Not Recommended for `.old` files)
While not recommended for `info.php.old` (which should be deleted), it's worth contrasting with how you might handle a *temporarily placed* `phpinfo.php` file.
If you *must* temporarily place a `phpinfo.php` file on a production server (which is generally discouraged), you should restrict access immediately after creation:
- **`.htaccess` (Apache):**
- **Nginx Configuration:**
- **Not for `.old` files:** This is *not* a solution for `info.php.old`. Those files are forgotten, unnecessary, and should be deleted.
- **Easily Forgotten:** Even for `phpinfo.php`, it's easy to forget to remove the restriction or delete the file, leading to the same vulnerability.
- **Still Exists:** The file still resides on the server, potentially discoverable by other means (e.g., local file inclusion if another vulnerability exists).
**Conclusion on Remediation:** For `info.php.old` and similar leftover files, **delete, delete, delete.** Restriction is a band-aid for a temporary `phpinfo.php` and should always be followed by immediate deletion.
Preventing Future `info.php.old` Occurrences
Prevention is always better than cure. Implement robust practices to stop these files from appearing.
Best Practices for Developers
- **Local or Staging Environments Only:** Use `phpinfo()` exclusively in your local development environment or a secure, access-restricted staging server. Never upload it to production.
- **Temporary & Unique Filenames (If Absolutely Necessary):** If you *must* use `phpinfo()` on production, use a randomly generated, obscure filename (e.g., `debug_ghj7k4.php`), restrict access by IP, and delete it immediately after use.
- **Avoid Renaming in Web Root:** Never rename files to `.old`, `.bak`, or `.tmp` within the web-accessible directories. If you need a backup, move it completely outside the web root or use version control.
- **Version Control Systems (VCS):** Use Git or similar VCS. Commit `phpinfo` files only to a `.gitignore`-d local branch or a dedicated development branch that never merges to production.
Server-Side Configuration and Monitoring
- **File Integrity Monitoring (FIM):** Implement FIM tools (e.g., Tripwire, AIDE) that alert you to new files, changes, or deletions in critical directories like your web root.
- **Regular Security Audits:** Conduct periodic security audits and penetration tests (ethical hacking) to identify forgotten files and other vulnerabilities.
- **Automated Scans:** Set up cron jobs to regularly scan your web roots for common dangerous filenames (`info.php.old`, `test.php`, etc.) and report them.
- **Restrict Web Server Access to Certain Extensions:** Configure your web server to only serve specific file types (e.g., `.php`, `.html`, `.css`, `.js`) and explicitly deny access to `.old`, `.bak`, `.tmp`, or other potentially revealing extensions.
- **Apache (httpd.conf or virtual host):**
- **Nginx (nginx.conf or server block):**
Build and Deployment Pipelines
- **CI/CD Integration:** Ensure your Continuous Integration/Continuous Deployment (CI/CD) pipelines explicitly exclude or remove all development, testing, and temporary files before deploying to production. This is the most robust automated prevention.
- **Pre-Deployment Hooks:** Add scripts to your deployment process that check for and delete known problematic files in the deployment target directory.
Common Mistakes to Avoid
- **Forgetting About Old Files:** The most common mistake. Developers often intend to clean up but get sidetracked.
- **Assuming Obscurity is Security:** Believing that because a file is named `info.php.old` instead of `info.php`, it's "hidden" or "safe." Attackers actively scan for these common filenames.
- **Renaming Instead of Deleting:** Renaming a file from `info.php` to `info.php.old` merely moves the problem, rather than solving it.
- **Not Understanding the Full Extent of Disclosure:** Underestimating how seemingly minor details from `phpinfo()` can be pieced together by an attacker to form a critical attack strategy.
- **Ignoring Warnings from Scanners:** Overlooking alerts from automated security tools about such files.
Conclusion
The humble `info.php.old` file represents a significant, yet easily preventable, security vulnerability. What appears to be a forgotten backup is, in reality, an open book to your server's deepest secrets, offering malicious actors a detailed roadmap for exploitation.
By understanding the information disclosure risks, proactively scanning your web servers, and implementing rigorous development and deployment practices, you can effectively eliminate this common security blind spot. Remember the golden rule: for `info.php.old` and similar forgotten files, **delete them immediately**. Take action today to audit your servers and ensure these hidden dangers are purged from your web infrastructure, contributing to a more secure online environment for everyone.
