Some time ago, someone posted a supposed vulnerability in ht://Dig to the
BugTraq mailing list about Cross-Site Scripting attacks using the htsearch
CGI. To the best of our knowledge, this is not a problem in versions
3.1.5, 3.1.6, 3.2.0b2, 3.2.0b3 or 3.2.0b4 snapshots of ht://Dig. However,
we are sending out this security advisory to let you know the issue and
how to tell if your htsearch templates could allow a cross-site scripting
* The Problem: (About Cross-Site Scripting)
Cross-site scripting (also known as XSS) is an attack when a web
application gathers malicious data from a user. For example, a link in
another website, e-mail, instant message, etc. could call your CGI,
collect data and then present an output page in a manner to make it appear
as valid content from your website.
XSS is the most dangerous for sites where users have authenticated
accounts or logins and could allow access for remote users to obtain
access to data not available to outside users.
* How Does XSS Affect ht://Dig?
Since the htsearch CGI presents web templates containing data from the
original query, a query could be constructed which adds HTML code to the
template--potentially sending data to remote sites or users or otherwise
hijacking the client's browser. Remember that the HTML would appear to be
from _your_ site and would have a "trust rating" associated with your site
(e.g. an intranet).
In versions 3.1.5 and later, the htsearch templates were changed to allow
variable expansion using the syntax $&(VAR) to HTML-encode all
output. This was done to force more standards-compliant HTML as well as
providing proper encoding for special characters, including < > and &. The
default templates (headers, footers, no_match pages, etc.) were all
changed to use this syntax where appropriate.
This "HTML-encoded" output also prevents XSS attacks as all attempts at
inserting XSS queries would result in text, rather than HTML, e.g.
XSS malicious code <script ...>
htsearch output <script ...>
(this would show up on a user's screen, rather than executed by the
As stated, versions 3.1.5, 3.1.6, 3.2.0b2, 3.2.0b3 and snapshots of
3.2.0b4 are *NOT* vulnerable by default. The templates installed use the
$&(VAR) syntax for proper HTML expansion.
However, if you have upgraded from older versions and have not changed
your templates, or you have changed your templates and use other forms of
variable expansion, you may be allowing XSS attacks. Future versions of
htsearch will likely make the $&(VAR) HTML-expansion the default, unless
other forms (for URL encoded or URL decoded output) are specified
In particular, the following rules should be used (to "protect" user-input):
$&(WORDS) not $(WORDS)
$&(LOGICAL_WORDS) not $(LOGICAL_WORDS)
$&(URL) not $(URL)
$&(CONFIG) not $(CONFIG)
$&(RESTRICT) not $(RESTRICT)
$&(EXCLUDE) not $(EXCLUDE)
Once again, to the best of our knowledge, the default installation of
versions 3.1.5, 3.1.6, 3.2.0b2, 3.2.0b3 and snapshots of 3.2.0b4 are not
vulnerable to XSS. If a repeatable example or exploit can be demonstrated,
we would like to know of it, and will respond ASAP with appropriate fixes.
Original BugTraq Posting and my reply:
For more on htsearch templates or upgrading ht://Dig:
(Current recommended production version is 3.1.6)
(Current 3.2 beta is the latest possible 3.2.0b4 development snapshot)
For more about Cross-Site Scripting:
Williams Students Online