A Comprehensive Approach to Abusing Locality in Shared Web Hosting Servers

With the growing of network technology along with the need of human for social interaction, using websites nowadays becomes critically important which leads in the increasing number of websites and servers. One popular solution for managing these large numbers of websites is using shared web hosting servers in order to decrease the overall cost of server maintenance. Despite affordability, this solution is insecure and risky according to high amount of reported defaces and attacks during recent years. In this paper, we introduce top ten most common attacks in shared web hosting servers which can occur because of the nature and bad configuration in these servers. Moreover, we present several simple scenarios that are capable of penetrating these kinds of servers even with the existence of several securing mechanisms. Finally, we provide a comprehensive secure configuration for confronting these attacks.

💡 Research Summary

The paper investigates security weaknesses inherent to shared web‑hosting environments, where many distinct websites run on a single server to reduce operational costs. Because the web server (Apache in the study) runs under a single system account (e.g., apache, www‑data) and processes all HTTP requests, every script executed for any site inherits the same privileges. This architectural choice eliminates isolation between tenants and enables a malicious actor who compromises one site to reach the resources of all other sites on the same host.

The authors first describe the typical shared‑hosting architecture: each site has its own FTP account, but the Apache process must be able to read every site’s files, and in many CMS configurations it also needs write access for uploads. Two script‑execution models are discussed – loading the interpreter as an Apache module versus spawning a CGI process per request. The module model is more efficient but shares the same process space, making it far less secure than CGI.

Based on this lack of isolation, the paper enumerates ten attack categories that can be performed by an attacker who controls a single compromised site:

1. Data Confidentiality Violation – The attacker reads configuration files (e.g., database credentials) of other sites because all scripts run under the same user and have read access to every directory.

2. Data Integrity Violation – With write permissions, the attacker can modify existing files or create new malicious scripts in other sites, effectively hijacking their functionality.

3. Session Poisoning – Because default PHP sessions are stored in a common directory such as /tmp, the attacker can create a forged session file containing privileged variables (e.g., admin flag) and force the victim site to accept it, gaining administrative access.

4. Session Snooping – The attacker reads legitimate session files of other sites, alters values (e.g., username), and re‑uses the session ID to impersonate other users.

5. Log Poisoning – Apache’s parent process opens the access log with root privileges and passes the file descriptor to child processes. When PHP runs as an Apache module, a malicious script can locate the inherited descriptor via /proc/self/fd/ and write arbitrary data into the log, erasing evidence or injecting malicious entries.

6. Log Snooping – Using the same descriptor‑discovery technique, the attacker can open the log file for reading, extract request patterns, reconstruct site directory structures, and discover hidden admin pages.

7. Intensive Local File Inclusion (LFI) – In shared hosting, the attacker can place a malicious file in a globally writable location (e.g., /tmp) and then exploit a vulnerable LFI parameter on another site to include that file, achieving remote code execution without needing to inject into a large log file.

8. CSRF Token Poisoning – By combining session poisoning with knowledge of how a site stores CSRF tokens (often in the session), the attacker can replace the token value, bypassing the anti‑CSRF protection.

9. Fast Brute‑Force – Because many sites share the same IP address, the attacker can launch simultaneous login attempts across multiple sites, effectively increasing the rate of password‑guessing attacks while evading simple per‑IP throttling.

10. Convenient Phishing – The attacker can host a fake login page on the same shared server, leveraging the shared domain or sub‑domain to trick users into submitting credentials, which are then harvested.

For each attack the authors provide concise PHP code snippets that demonstrate how the vulnerability can be exploited, and they clearly state the pre‑conditions required (common user account, shared session/log directories, module‑mode interpreter, etc.).

The final contribution of the paper is a comprehensive hardening guide tailored to shared‑hosting deployments. The recommended measures include:

• Process isolation: Deploy per‑site PHP‑FPM pools, enable suEXEC/suPHP, or use containers to run each site under a distinct Unix user.
• Least‑privilege file permissions: Restrict the web‑server user to read‑only access for most directories; grant write rights only to designated upload folders.
• Separate session and log storage: Configure each site to use its own session directory (e.g., via session.save_path) and its own log file, preventing cross‑site reads/writes.
• Prefer CGI over module: Running PHP as a CGI binary prevents inheritance of the parent’s log file descriptor, mitigating log poisoning.
• Secure log handling: Keep logs owned by root, set permissions to 640, and consider using logrotate with strict ownership.
• Input validation and whitelist for file inclusion: Disallow user‑controlled paths, enforce a whitelist of includable files, and block directory traversal patterns.
• Robust CSRF defenses: Store tokens in server‑side memory (e.g., Redis) rather than in session files, and bind tokens to additional request attributes.
• Strong authentication policies: Enforce complex passwords, account lockout after failed attempts, CAPTCHA, and optionally two‑factor authentication to blunt brute‑force attacks.
• TLS and HSTS enforcement: Use per‑site SSL certificates and HTTP Strict Transport Security to mitigate phishing and man‑in‑the‑middle threats.

By applying these configurations, operators can retain the economic benefits of shared hosting while dramatically reducing the attack surface exposed by tenant cross‑contamination. The paper’s systematic taxonomy of attacks, practical exploit code, and concrete mitigation checklist make it a valuable reference for system administrators, security auditors, and researchers focusing on multi‑tenant web services.