[12491] in bugtraq
Re: Guestbook.pl, sloppy SSI handling in Apache? (VD#2)
daemon@ATHENA.MIT.EDU (Chuck Phillips)
Tue Nov 9 11:56:30 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <14374.25256.842934.468986@cdp.localnet>
Date: Sun, 7 Nov 1999 22:42:00 -0700
Reply-To: Chuck Phillips <cdp@PEAKPEAK.COM>
From: Chuck Phillips <cdp@PEAKPEAK.COM>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <282526240@toto.iv>
Marc Slemko writes:
> Note that the following is a valid SSI:
>
> <!--#include file="/foo1"
> file="/foo2"
> file="/foo3" -->
>
> Apache does "reject" invalid SSIs, but does not validate that a
> SSI is valid before it begins processing it so the rejection only
> happens after it has been partially processed. ...
Understandable. And, of course:
> As always, don't enable SSIs unless you need them. If you do need them,
> use IncludesNOEXEC (which does not allow random files to be executed, but
> does allow CGIs in ScriptAliased directories to be executed) unless you
> really need to allow exection of other things. If you really do need
> to allow execution of other things, don't do it globally, but only where
> it is absolutely necessary.
Similar warnings apply for malicious users who may inject PHP (also server
side threat) and javascript (client side threat) into data that might wind
up on a web page.
If the intent is to disallow HTML altogether, escape "<" and "&" at least,
preferably also ">" and perhaps even double quotes. "&" needs to be first.
E.g.,
s/\&/\&\;/g;
s/\</\<\;/g;
s/\>/\>\;/g;
s/\"/\"\;/g;
A side effect of doing this is that it will be obvious when someone tries
to hack your page with SSI, PHP, etc. -- and fails.
If you *must* allow HTML tags in user input _at all_, limit them to
specific tags. Something like:
@okTags= ($userInput =~
s,(\</?(?:B|I|Whatever\>?)|\&(?:copy|amp)\;),\0,gi);
$userInput=~ s/\&/\&\;/g;
$userInput=~ s/\</\<\;/g; # Escape remaining "<"s.
# Note that ">"s are *not* escaped because only the beginnings of
# tags are matched when attributes exist.
$userInput=~ s/\0/shift(@okTags)/ge;
The above example is to allow the tags <b>, </b>, <i>, </i>, <whatever
attribute=value>, </whatever> and © and & -- and disallow all
other tags and comments by turning them into ordinary content. If you want
to silently remove certain tags first, do that. If you want to completely
disallow an entry because of *any* undesirable content, do that.
As others have stated, try not to anticipate everything that might possibly
be bad. Rather, filter out anything that isn't good whenever possible.
Blue Boar's criticism of the guest book script is certainly valid, but only
scratches the surface of possible exploits. IMHO, the main problem
regarding both HTML comment *and* HTML tag removal, is that this script
assumes all undesirable content -- in a guest book -- will be syntatically
valid HTML. :-)
For people who don't consider Javascript a threat, consider malicious web
pages (e.g., Active X, the recent MS JVM exploit) that Javascript can call
up without your explicit consent (e.g., mouseover event). Also consider
Javascript-enabled mail readers, but that's another topic.
Chuck
