[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: user/3875: HTTP client authorization in lynx and firefox doesn't work



The following reply was made to PR user/3875; it has been noted by GNATS.

From: "Christian Jones" <chjones_(_at_)_speakeasy_(_dot_)_net>
To: "Otto Moerbeek" <otto_(_at_)_drijf_(_dot_)_net>, gnats_(_at_)_openbsd_(_dot_)_org
Cc:  
Subject: Re:  user/3875: HTTP client authorization in lynx and firefox  doesn't work
Date: Sun, 19 Sep 2004 19:13:12 +0000

 > I am able to reproduce this with a cheap, lousy e-tech router. The web
 > based management interface uses frames. From following the http
 > transaction it looks like the browsers do not send the password info with
 > all requests.
 >
 That's what I'm getting.  Attached are two tcpdump -w files, one from 3.5 and
 one from CURRENT, detailing the transaction between the router and lynx.
 Firefox transactions are similar, but much more cluttered.  Notice especially
 that the packet which should be sending authorization code is truncated in
 3.6.
 
 (Yes, I know it looks like there's sensitive information in the tcpdumps.
 There's not.)
 
 > My conclusion is that changes to the authentication mechanism of
 > both firefox and lynx has made them more strict. In particular, they
 > refuse to send password info related to one frame together with a request
 > for another frame, or something similar to that. This is probably to
 > prevent certain types of password stealing techniques using frames.
 >
 > Probably these routers do not use frames properly and are not compatible
 > with the updated authentication mechanism of these browsers.
 >
 My router doesn't use frames, and I can't determine why the packet seems to be
 cut off even before it is finished.  I don't think frames/javascript is the
 problem, but can't be sure.
 
 [demime 0.98d removed an attachment of type application/octet-stream which had a name of lynx-tcpdump-35v36.tar.gz]



Visit your host, monkey.org