fix: use hash_equals for legacy auth token comparison

[hacktron-app-stg]

Vulnerability

legacy_auth.php:9 validated the user-supplied token against a hardcoded hash using PHP's loose comparison operator (==):

$stored = "0e462097431906509019562988736854";
if ($_POST['token'] == $stored) {
    $_SESSION['auth'] = true;
}

The stored hash is "magic-hash" style: 0e followed by digits only. PHP's == coerces such strings to floats in scientific notation, so "0e462..." == "0e123..." evaluates as 0 == 0 => true. An attacker could POST token=0e0 (or any 0e<digits> value) to bypass authentication and set $_SESSION['auth'] = true.

Fix

• Use hash_equals($stored, $token) for validation. It performs a strict, length-checked, constant-time string comparison, eliminating both the type-juggling bypass and a timing side channel.
• Normalize the input to a guaranteed string via an isset/is_string guard so non-string inputs (e.g. token[]=...) cannot trigger coercion or a TypeError.

Verification

• Reviewed the taint path: source $_POST['token'] flows directly into the loose comparison sink at line 9. Confirmed the 0e-prefixed hash makes the bypass reachable.
• hash_equals requires two strings and compares them byte-for-byte, so "0e0" no longer matches the stored hash.
• Could not run php -l (PHP is not installed in the sandbox), but the change is a minimal, syntactically valid substitution.

Scope note: this PR only addresses the type-juggling finding on line 9. Other issues present in the file (extract() variable overwrite, preg_replace /e RCE, assert() RCE) are separate findings and intentionally left untouched.

---

Automated fix by Hacktron for finding: https://staging.hacktron.ai/testestesttest/findings/1857f818-c47a-4bb7-83ff-95ee0454719e