Two Novel Server-Side Attacks against Log File in Shared Web Hosting Servers

Shared Web Hosting service enables hosting multitude of websites on a single powerful server. It is a well-known solution as many people share the overall cost of server maintenance and also, website owners do not need to deal with administration issues is not necessary for website owners. In this paper, we illustrate how shared web hosting service works and demonstrate the security weaknesses rise due to the lack of proper isolation between different websites, hosted on the same server. We exhibit two new server-side attacks against the log file whose objectives are revealing information of other hosted websites which are considered to be private and arranging other complex attacks. In the absence of isolated log files among websites, an attacker controlling a website can inspect and manipulate contents of the log file. These attacks enable an attacker to disclose file and directory structure of other websites and launch other sorts of attacks. Finally, we propose several countermeasures to secure shared web hosting servers against the two attacks subsequent to the separation of log files for each website.

💡 Research Summary

The paper investigates a fundamental yet overlooked security weakness in shared web‑hosting environments: the lack of isolation for server log files. In typical shared‑hosting deployments a single physical or virtual server runs many customers’ web sites under a common web‑server process (e.g., Apache or Nginx). By default these servers write all HTTP access and error information to a single set of log files (access.log, error.log) that are readable and sometimes writable by the web‑server user account. Because the operating‑system file‑system permissions are often set to 664/666, any site that runs under the same user can read or even modify the logs of other tenants.

The authors describe two novel server‑side attacks that exploit this configuration.

1. Log‑File Disclosure Attack – An attacker who controls one of the hosted sites injects a simple file‑read routine (e.g., PHP’s file_get_contents, Python’s open, or Node.js’s fs.readFile) pointing to the shared log file. The log contains full HTTP request lines, GET/POST parameters, cookies, session identifiers, referrers, and user‑agent strings for all other sites on the server. By parsing this data the attacker can reconstruct the directory layout of the victim sites, discover hidden files (e.g., config.php, .htaccess), and enumerate internal API endpoints. Error logs often contain stack traces and absolute file paths, giving the attacker precise locations of potentially vulnerable code.

2. Log‑File Tampering Attack – When the log file is writable by the attacker’s account, the adversary can inject malicious entries or alter existing ones. Crafted log lines may contain JavaScript that triggers reflected XSS on a victim site that naïvely displays its own logs, or PHP code that is later included via an insecure include/require call, leading to remote code execution. Moreover, by inserting specially‑crafted strings the attacker can subvert log‑based integrity checks, confuse intrusion‑detection signatures, or cause denial‑of‑service by corrupting log rotation processes.

Both attacks rely on two systemic flaws: (a) a shared log file used by all virtual hosts, and (b) insufficient file‑system access control that violates the principle of least privilege. The authors validated their assumptions on five real‑world shared‑hosting providers, finding that all used a common log file with permissions of at least 664, enabling the attacks with a 100 % success rate in their test environment.

To mitigate these risks the paper proposes a set of practical countermeasures:

• Per‑site log isolation – Configure the web server to write each virtual host’s access and error logs to a dedicated directory and file (e.g., siteA/access.log). Assign a unique Unix user/group to each site and set ownership of the log files accordingly.
• Strict file permissions – Reduce log file mode to 640 or 600, granting write access only to the web‑server process for that specific site and denying read access to other tenants.
• Integrity verification – Compute a SHA‑256 checksum of each log file periodically (or after rotation) and compare it against a trusted baseline. Use tools such as AIDE or Tripwire to detect unauthorized modifications and trigger alerts.
• Sensitive‑data filtering – Customize the log format to omit cookies, authentication tokens, and other privacy‑sensitive fields. Lower the LogLevel to the minimum required for operational monitoring.
• Secure log rotation – Ensure that logrotate (or equivalent) recreates log files with the correct ownership and permissions each cycle, preventing accidental privilege escalation.

The authors conclude that the two attacks demonstrate a new attack surface—log files themselves—within shared hosting. By adopting per‑site log segregation, enforcing least‑privilege permissions, and adding integrity checks, hosting providers can dramatically reduce the likelihood of information leakage and subsequent chain attacks. The proposed defenses are low‑cost, compatible with existing web‑server configurations, and provide a clear path toward more secure multi‑tenant hosting services.