[Security] Stored XSS in Trackback functionality (excerpt parameter not sanitized) #1977

Describe the Bug

The excerpt parameter in the Trackback functionality has no XSS filtering. An attacker can inject Stored XSS by sending a malicious Trackback request. In the same codebase, Pingback is protected with removeXSS() + strip_tags(), but Trackback was missed. Additionally, Common::stripTags() does not check for javascript: protocol in attribute values during output rendering, allowing malicious scripts to trigger on both the frontend and admin panel.

Steps to Reproduce

Precondition: The allowed HTML tags in comment settings include <a href=""> (the default example value in admin panel).

1. Confirm the target post exists and allows trackbacks (allowPing = 1)

2. Send a malicious Trackback request (no authentication, no CSRF token required):

   curl -X POST "http://target/archives/1/trackback" \
     -d 'blog_name=XSSTest&url=http://example.com/xss&excerpt=<a href="javascript:alert(1)">click here</a>'

3. Server returns <success>0</success>, payload is stored raw in the database

4. Visit the post's comment section, click the "click here" link, alert(1) pops up

5. Visit the admin comment management page, same XSS triggers

Expected Behavior

The Trackback excerpt field should be sanitized with removeXSS() + strip_tags() just like Pingback. The javascript: protocol should not appear in the final rendered output.

Screenshots

Platform

• OS: Ubuntu 20.04 (Linux 5.4.0)
• Apache/Nginx: PHP built-in server
• Database: SQLite 3 (PDO)
• PHP: 7.4.3
• Typecho: 1.2.1
• Browser: Chrome latest