bugtraq - KM-2004-01: Cross-Site Scripting in Blosxom writeback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Mon, 07 Jun 2004 22:29:26 -0500
From: Kyle Maxwell <kylem@...ll.org>
To: bugtraq@...urityfocus.com
Subject: KM-2004-01: Cross-Site Scripting in Blosxom writeback

Security Advisory KM-2004-01: Cross-Site Scripting in Blosxom writeback

Affected Application:
Blosxom (http://www.blosxom.com)

Severity: Medium to high (typical XSS impacts)

Introduction:
Blosxom, a weblog tool, has an optionally-installable plugin commonly
used for allowing users to post comments or trackbacks to entries in a
weblog, called writeback
(http://www.blosxom.com/plugins/input/writeback.htm). The filtering
function in all Blosxom 2.0 writeback version,s including the latest
(2004-02-19), is vulnerable to a simple bypass, allowing attackers to
embed scripts in their comment that will be run by any client viewing
the page.

Discussion:
In the writeback plugin, the code to filter out tags is a simple regular
expression: "s/<.*?>//mg". So entering scripts as
"<script>alert('test');</script>" will get filtered into
"alert('test');" and no code will be executed by the client.

This allows a straightforward bypass by using carriage returns before
the closing bracket in the script tags, so that the tags do not meet the
regular expression but are still interpreted as tags by browsers.
Additional bypassing methods may be possible using the existing
filtering.

Impact:
Attackers can take any action that the client permits the site to do,
including retrieving any cookies used on the site (even if they are not
Blosxom-related), exploiting browser vulnerabilities, rewriting the
page, etc. The overall impact of XSS vulnerabilities is well-known; see
References below if needed.

Solution:
Implement a more robust filtering scheme. One alternative would be to
replace "<" and ">" characters with "&lt;" and "&gt;" and other
sensitive characters with the appropriate HTML entities. Another would
be to only allow certain characters, such as alphanumerics and a few
additions. See References below if needed. An additional solution has
been proposed by Ivan Grynov at
http://groups.yahoo.com/group/blosxom/message/8034. The author has
chosen not to implement these solutions at this time, though the code is
undergoing a complete overhaul and may thus not be vulnerable in 3.0

A copy of this advisory (including very simple proof-of-concept code) is
available at
http://kylem.xwell.org/blosxom.cgi/tech/security/km-2004-01.html.
Additionally, a patch using HTML::Entities is available at 
http://kylem.xwell.org/wb.patch.

References:
http://www.cert.org/tech_tips/malicious_code_mitigation.html
http://www.technicalinfo.net/papers/CSS.html
http://www.perl.com/pub/a/2002/02/20/css.html