Limo Booking Software v1.0 - CORS

Limo Booking Software v1.0: A Critical CORS Misconfiguration Exploited in the Wild

On September 8, 2023, cybersecurity researcher nu11secur1ty uncovered a high-severity vulnerability in Limo Booking Software v1.0, a widely used web application developed by PHPJabbers. The flaw centers on a dangerously permissive CORS (Cross-Origin Resource Sharing) policy that allows unrestricted access from any domain — a configuration that opens the door to serious security risks, including cache poisoning and unauthorized data exposure.

Understanding CORS: The Security Mechanism That Failed

CORS is a browser-based security mechanism designed to prevent malicious websites from accessing sensitive resources on other domains. It operates through HTTP headers such as Access-Control-Allow-Origin, which dictates which origins (domains) are permitted to access a resource.

When implemented correctly, CORS restricts access to trusted domains only. However, in this case, the application responded with:

Access-Control-Allow-Origin: *

This wildcard * means any origin — including malicious domains — can access the application's resources. This is a fundamental misconfiguration, especially when combined with the absence of the Vary: Origin header.

The Critical Flaw: Missing Vary: Origin Header

According to the OWASP CORS Guide and security best practices, servers should include the Vary: Origin header when CORS policies are dynamic. This header signals to intermediate caches (like reverse proxies, CDNs, or load balancers) that the response varies based on the origin request.

Without Vary: Origin, cached responses can be served to different clients regardless of their origin — a classic cache poisoning attack vector.

For example, an attacker can:

• Send a request from a malicious domain (http://wioydcbiourl.com)
• Receive a response with Access-Control-Allow-Origin: *
• Have that response cached by a CDN or proxy
• Subsequently, deliver the same cached response to a legitimate user, allowing the attacker’s domain to access sensitive data via JavaScript

This attack is stealthy and difficult to detect, as the victim may never realize their browser has been served a poisoned response.

Exploitation Example: Real-World Payload

The researcher provided a detailed test payload to demonstrate the vulnerability:

GET /1694201352_198/index.php?controller=pjFrontPublic&action=pjActionFleets&locale=1&index=2795
HTTP/1.1
Host: demo.phpjabbers.com
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.5845.141 Safari/537.36
Connection: close
Cache-Control: max-age=0
Origin: http://wioydcbiourl.com
Referer: http://demo.phpjabbers.com/
Sec-CH-UA: ".Not/A)Brand";v="99", "Google Chrome";v="116", "Chromium";v="116"
Sec-CH-UA-Platform: Windows
Sec-CH-UA-Mobile: ?0

This request mimics a real user interaction but uses a malicious origin. The server responds with a 200 OK status and includes Access-Control-Allow-Origin: * — allowing any client to access the fleet data.

Since the response lacks Vary: Origin, it can be cached and later delivered to legitimate users, potentially exposing sensitive fleet information, pricing, or vehicle details — all without the victim’s knowledge.

Impact and Risk Assessment

Severity	High
Attack Vector	Cache poisoning, cross-origin data leakage
Exploitability	High — requires only a malicious domain and basic HTTP request
Impact	Exposure of internal data, potential for session hijacking or client-side XSS

The vulnerability is particularly dangerous because:

• It affects a public demo instance, making it accessible to attackers globally
• It enables passive data leakage without direct interaction with the victim
• It can be exploited even without user authentication

Best Practices for Secure CORS Implementation

Developers must avoid using Access-Control-Allow-Origin: * in production environments. Instead, adopt one of the following secure strategies:

• Whitelist specific origins: Set Access-Control-Allow-Origin: https://trusted-domain.com for known partners
• Dynamic origin validation: Use server-side logic to verify the Origin header and respond accordingly
• Always include Vary: Origin: Prevent cache poisoning by signaling that the response depends on the requesting origin
• Use Access-Control-Allow-Credentials only when necessary: If credentials are involved, avoid using * and require explicit origin matching

Example of a secure response:

Access-Control-Allow-Origin: https://trusted-site.com
Access-Control-Allow-Credentials: true
Vary: Origin

This configuration ensures that only trusted domains can access sensitive resources, and caches are properly invalidated based on origin.

Conclusion: A Wake-Up Call for Web Application Security

Limo Booking Software v1.0 serves as a stark reminder that even seemingly benign features like CORS can become critical vulnerabilities when misconfigured. The absence of Vary: Origin combined with a wildcard Access-Control-Allow-Origin creates a perfect storm for cache poisoning attacks — a threat often overlooked in traditional security assessments.

Developers and administrators should:

• Regularly audit CORS policies in their applications
• Use automated tools to detect misconfigurations
• Implement strict origin validation in production environments
• Never rely on * in CORS headers unless absolutely necessary (and even then, only in controlled, non-sensitive contexts)

Security is not just about authentication and encryption — it’s about context-aware configuration. A single missing header can compromise an entire system.