Much simpler than the bugfix printed on your site, the following change will
secure the script from reading any file. I found this especially helpful
when I discovered that you could, with a few tries for how many dot-dots to
include, actually dump your /etc/passwd file.

change:
$read = $in{"read"};
to:
($read = $in{"read"}) =~ s/\.\.\///g;

This does not print a nice and friendly error message at all, it simply
bitches at the user that it cannot open the file unless they happen to get
something that actually is a message, which is unlikely.

I have never been one to feel the need to be particularly user-friendly to
hackers when informing them that a supposed security hole they attempted to
utilise exists. Due to the considerable thought someone would have to put in
to get this error message, I think it is safe to assume someone wouldn't
accidentally use this.

And, as said above, this fix is a LOT simpler to implement than the more
complicated one you have listed.

My copy of WebBBS is online at http://www.gothic-classifieds.com/bbs

If you look around the site, some other things may look familiar: especially
the chatroom. In reality, the chatroom is a totally different script that
uses a DBM tied hash. The reason it has almost the exact same interface as
your webchat, however, is that a prior incarnation of this site did use your
webchat, and the users would not let me change anything *L*. WebBBS is the
only program I use as found (with HTML changes, Y2K fixes, and the above
security patch). Everything else is totally from scratch except, as
mentioned, the look of the chat interface.

Security holes abound in both your chat and mine (I intend to fix mine
soon). These aren't system security holes, but simply chat security issues.
Obviously, anyone using someone else's name can read their PMs.
Additionally, if a counter setup like you get from SiteMeter
(www.sitemeter.com) is added to the page to count the chat's hitrate, and
the person has autorefreshed, their session ID becomes accessible by others
as the referer is stored in the SiteMeter or similar site's visitor log.
Cookies would be a better implementation in this case (actually, in
general).

My chat, aside from the engine changes, DBM base, and thus speed increase,
also has some other interesting additions: an admin chat enables passworded
individuals to provide some crowd control by banning or frogging abusive
individuals. Frogging makes a user unable to say anything but 'Ribbit.
Ribbit' in neon green until unfrogged. Banning restricts them from using the
program at all. Checking is by IP address, so people can sometimes get
around it with IP spoofing, but it takes a lot of work. In addition, I have
a sometimes-on feature that strips out HTML _IF_ they don't have a
successful reverse DNS lookup, for the times when hackers do attack. I also
have several kludgy quick-fixes:

Close every tag I can think of at the beginning of each message. Yes,
improperly nested HTML, but it works to stop HTML colour leaks and such. I
close font five times, actually.

The word script cannot be spoken. It becomes srcipt.
Phrases like 'onXXXX = ' and 'XXXXX()' cannot be spoken, as they appear to
be javascript, and have almost no use in English or most non-programming
languages. After some jerk decided that he wanted to remove everyone's HTML
privleges by posting things like <img src=""
onError="document.location.replace(some.other.site)"> I cracked down on the
possibility of JavaScript. I also need to crack down on the ability to set
CSS styles.