At 10:25 AM 4/28/00 +0100, Matt Sergeant wrote:
>On Fri, 28 Apr 2000, Marc Slemko wrote:
>
> > On Thu, 27 Apr 2000, Matt Sergeant wrote:
> >
> > > Unfortunately there's also a browser bug to contend with. They treat \x8b
> > > (I think that's the right code) as < and there's a similar code for
> > > >. Since most web developers are just doing s/</</g; they are open to
> > > attacks based on character sets like this. Sad, but true. Even our loved
> > > CGI.pm was (is?) open to this bug - I think Lincoln has fixed the
> > > HTMLEncode function now though.
> >
> > Mmm? Which browsers? Do they have to be configured for any particular
> > character set? And can you provide an example that demonstrates it?
> >
> > I can't reproduce it...
>
>Well if you have Apache 1.3.12, it implicitly sets the Content-Encoding,
>or the character set, so this bug is minimised. But only on static
>content. If there's no character set in the Content-type or
>Content-Encoding the browser sniffer comes into play, and Netscape
>(IIRC) picks it up as Latin-1, or US-ASCII, I can't recall which. The
>details are all available over the web. Tom Christiansen had an excellent
>informative discussion about it on p5p - search the archives.
The latest version of CGI.pm also mitigates this for scripts or apps that
use it to print the header.
perl -MCGI -e '$q = new CGI(); print $q->header();'
Content-Type: text/html; charset=ISO-8859-1
I assume Apache's request object send_http_header does whatever Apache does
to get the header printed out with the charset stuff when the static pages
are displayed?
Later,
Gunther
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
