Lot Reservation Management System - Unauthenticated File Disclosure

Lot Reservation Management System — Unauthenticated File Disclosure (Analysis, Risks, and Remediation)

Overview

This article explains an unauthenticated file disclosure class of vulnerability identified in a demo PHP/MySQLi application (Lot Reservation Management System). The root cause is unsafe inclusion/dispatch logic that can be abused to reveal PHP source files (and other filesystem contents) to an unauthenticated attacker. Revealing PHP source can expose database credentials, API keys, business logic, and other sensitive information.

How this class of vulnerability works (conceptual)

• Many PHP applications use a parameter (commonly named page, view, or file) to decide which file to include or render.
• If that parameter is used directly in include/require or file-access functions without validation, an attacker can manipulate it to reference arbitrary filesystem locations or PHP stream wrappers.
• PHP stream wrappers (for example, internal streams) can be used to convert or read files in ways that disclose source code instead of interpreting it. If the application outputs the raw result, sensitive data can leak to the attacker.
• The attack requires no authentication when the vulnerable code runs in a publicly reachable page.

Why this is dangerous

• Disclosure of database credentials in configuration files allows full database compromise.
• Exposure of source code reveals logic vulnerabilities, hardcoded secrets, and potential privilege escalation paths.
• Attackers may further read files outside the webroot if filesystem access is permitted, increasing impact.
• Because the attack is unauthenticated, it can be automated and scanned at scale.

Typical vulnerable pattern (safe demonstration)

<?php
// Vulnerable pattern: using a request parameter directly in an include
$page = $_GET['page'];
include __DIR__ . '/pages/' . $page . '.php';
?>

Explanation: This code trusts the page parameter completely. An attacker can supply unexpected values to alter the included path and trigger unintended behavior, including attempts to read files or invoke stream wrappers.

Secure alternatives and fixes

Fixes fall into two categories: secure coding changes and server/configuration hardening. Apply both for robust protection.

1) Use an explicit whitelist for dispatching pages

<?php
// Secure pattern: map allowed tokens to real files (whitelist)
$allowed = [
  'home' => __DIR__ . '/pages/home.php',
  'about' => __DIR__ . '/pages/about.php',
  'contact' => __DIR__ . '/pages/contact.php',
];

$token = $_GET['page'] ?? 'home';
if (!isset($allowed[$token])) {
    http_response_code(404);
    echo 'Not found';
    exit;
}

require $allowed[$token];
?>

Explanation: The application accepts only predefined tokens and resolves them to explicit files. User input never directly controls filesystem paths; this eliminates path traversal, wrapper abuse, and arbitrary file inclusion.

2) Validate and canonicalize paths if dynamic names are required

<?php
// If dynamic files are absolutely necessary, constrain to a directory and validate
$dir = realpath(__DIR__ . '/pages');
$requested = basename($_GET['page'] ?? 'home') . '.php';
$full = realpath($dir . DIRECTORY_SEPARATOR . $requested);

if ($full === false || strpos($full, $dir) !== 0) {
    http_response_code(404);
    exit;
}

require $full;
?>

Explanation: basename() reduces attempts to inject directory traversal tokens; realpath() resolves symbolic links and canonicalizes the filesystem path; the check ensures the resolved file remains within the intended directory.

3) Move sensitive configuration files out of the webroot

Store credentials and configuration outside the publicly served directory. For example, put db_connect.php (containing DB credentials) one level above the document root and require it with an absolute path. That way, even if include logic fails, the file cannot be requested directly via HTTP.

4) Harden PHP and web server configuration

• Set open_basedir to restrict PHP to only required filesystem locations.
• Disable PHP exposure: expose_php = Off.
• Disable display_errors in production to avoid leaking code traces and file paths (display_errors = Off; log_errors = On).
• Limit stream wrapper usage where possible and audit uses of include/require, file_get_contents, and other filesystem functions.
• Ensure proper filesystem permissions so webserver user has only the minimum necessary read/write access.

5) Remove demo and backup files

Developer/demo packages often include sample code, backups, or test files. Remove those from production environments. Files like README, test.php, backup copies, or editors' swap files can contain secrets or helpful context for an attacker.

Detection and indicators of exploitation

• Web logs containing suspicious parameters with unusual tokens or suspicious wrappers (for example, strings referencing internal stream wrappers). Monitor for anomalous GET/POST values.
• Responses containing base64-encoded content or raw source fragments where compiled HTML was expected.
• Unexpected requests for files outside normal navigation patterns; spikes in 2xx responses that include long base64 blocks.
• File integrity checks failing or unexpected changes in backup/source files.

Incident response steps

• Immediately identify which files were accessed and what sensitive secrets were exposed (database credentials, API keys).
• Rotate any exposed secrets (database passwords, API keys) and regenerate credentials for affected services.
• Patch the code as described (whitelist or canonicalization) and redeploy to prevent further unauthenticated access.
• Review logs to identify the scope and timeline of access, and look for pivot attempts.
• Apply server-side hardening (permissions, open_basedir, disable display_errors) and run a security scan.

Priority checklist and mitigation table

Action	Why	Priority
Implement whitelist dispatch	Prevents arbitrary file inclusion	High
Move config files outside webroot	Prevents HTTP access to sensitive credentials	High
Apply path canonicalization and validation	Blocks directory traversal and wrapper abuse	High
Harden PHP settings (open_basedir, display_errors)	Reduces exposure and restricts filesystem access	Medium
Remove demo/backup files	Eliminates unnecessary sensitive artifacts	Medium
Log monitoring & IDS rules (detect wrapper usage)	Helps detect exploitation attempts	Medium

Developer best practices and long-term recommendations

• Adopt secure-by-default patterns for file inclusion: never trust user input for filesystem operations.
• Perform threat modeling for public pages to identify components that must never be influenced by unauthenticated input.
• Use configuration management and secrets vaults for credentials instead of storing them in web-accessible code.
• Include automated tests that exercise guard conditions (e.g., attempts to include unexpected files should be blocked).
• Harden CI/CD pipelines to prevent accidental deployment of development/demo artifacts to production.

Conclusion

Unauthenticated file disclosure via unsafe include/dispatch is a common and high-impact vulnerability in PHP applications. The safe remediation strategy combines secure coding (whitelists and canonicalization), configuration hardening (PHP and filesystem restrictions), and operational controls (credential rotation, logging, and monitoring). Applying these controls closes the immediate information disclosure path and reduces risk of follow-on attacks.