FWIW, Netscape 4.08 for Wintel is immune to this, as is I.E. 5 however Netscape 4.6 for Solaris succombs to it. Lynx is immune as well. Long live lynx! > -----Original Message----- > From: Chon-Chon Tang [mailto:ztangat_private] > Sent: Tuesday, October 05, 1999 12:52 PM > To: BUGTRAQat_private > Subject: Re: Time to update those CGIs again > > > I just tested this on Linux 2.0.34, Netscape Communicator 4.61 and the > same problem exists. > > On Tue, 5 Oct 1999, Tymm Twillman wrote: > > > Seems that at least some Unix versions of Netscape treat > characters 0x8b > > and 0x9b (NOT the strings "0x8b" and "0x9b" but the > characters with these > > ascii values) just like < and > respectively... > > > > This could be a problem for guestbooks/web email/filtering > programs which > > remove tags by filtering based on greater/less than characters. > > > > I've tested this on Linux with Netscape versions 4.51 and > 4.7; others have > > confirmed that Solaris versions behave the same... > Apparently Mac/Windows > > versions just display the characters instead of using them as tag > > delimiters. > > > > Here's a glob of code to show the problem: > > > > --- cut --- > > > > #!/usr/bin/perl > > > > $opentag = chr(0x8b).'a href="http://www.netscape.com"'.chr(0x9b); > > $closetag = chr(0x8b).'/a'.chr(0x9b); > > > > open OUT, '>uhoh.html' || die ("Couldn't open"); > > > > print OUT "If this $opentag link $closetag works, it could be bad."; > > > > close OUT; > > > > --- cut -- > > > > run this and point Netscape at the resulting uhoh.html file... > > > > It looks like this may be the result of some alternate character set > > compatability feature, but it's rather hard to tell... I > have not seen > > this documented anywhere however. > > > > -Tymm > > >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:07:00 PDT