Description

AVideo has Pre-Captcha User Enumeration and Account Status Disclosure in Password Recovery Endpoint

Summary

The password recovery endpoint at objects/userRecoverPass.php performs user existence and account status checks before validating the captcha. This allows an unauthenticated attacker to enumerate valid usernames and determine whether accounts are active, inactive, or banned — at scale and without solving any captcha — by observing three distinct JSON error responses.

Details

In objects/userRecoverPass.php, the request flow is:

Line 11 — A User object is instantiated from unsanitized $_REQUEST['user'] with no authentication:

$user = new User(0, $_REQUEST['user'], false);

Lines 27-29 — If the user does not exist, a distinct error is returned immediately:

if (empty($user->getStatus())) {
    $obj->error = __("User not found");
    die(json_encode($obj));
}

Lines 31-33 — If the user exists but is not active, a different distinct error is returned:

if ($user->getStatus() !== 'a') {
    $obj->error = __("The user is not active");
    die(json_encode($obj));
}

Lines 37-41 — Captcha validation only occurs after both user enumeration checks:

if (empty($_REQUEST['captcha'])) {
    $obj->error = __("Captcha is empty");
} else {
    require_once 'captcha.php';
    $valid = Captcha::validation($_REQUEST['captcha']);

This ordering creates a reliable oracle: requests that hit the captcha check confirm the user exists and is active, while the two earlier error messages reveal non-existence or inactive status — all without requiring a valid captcha.

By contrast, the registration endpoint (objects/userCreate.json.php) correctly validates the captcha at lines 32-42 before performing any user existence checks, confirming this ordering in the password recovery endpoint is a bug.

No rate limiting (rateLimitByIP) or brute force protection (bruteForceBlock) is applied to this endpoint. The framework's session-based DDOS protection is trivially bypassed by omitting cookies (each request gets a fresh session).

PoC

# 1. Test a non-existent user — returns "User not found" without captcha
curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
  -d 'user=nonexistent_user_xyz&captcha=' | jq .error

# 2. Test a valid active user — passes user checks, hits captcha validation
curl -s -X POST 'http://localhost/AVideo/objects/userRecoverPass.php' \
  -d 'user=admin&captcha=' | jq .error
...
Show more

Impact

Username enumeration: Attackers can determine which usernames are registered on the platform without any captcha or authentication barrier.

Account status disclosure: Attackers can distinguish between active, inactive, and non-existent accounts, revealing moderation/ban status.

Credential stuffing enablement: Confirmed valid usernames can be used in targeted password brute-force or credential stuffing attacks against the login endpoint.

Phishing: Knowledge of valid active accounts enables targeted social engineering attacks against real users.

No throttling: The absence of rate limiting on this endpoint allows high-speed automated enumeration.

Recommended Fix

Move the captcha validation before the user existence checks, and return a generic message regardless of user status:

// In objects/userRecoverPass.php, replace lines 26-41 with:

    header('Content-Type: application/json');

    // Validate captcha FIRST, before any user lookups
    if (empty($_REQUEST['captcha'])) {
        $obj->error = __("Captcha is empty");
        die(json_encode($obj));...
Show more

Additionally, consider adding rateLimitByIP() to this endpoint as defense-in-depth.

Mitigation

Aliases

References