[Zope-Coders] FastCGI leaking Authorization header

[Casey Duncan]

The point is not whether the issue shot be fixed, but whether it is serio=
us=20
enough to warrant a Hotfix and all of the cerimony and buzz that goes wit=
h=20
it.

IMHO, we should just patch 2.5 and the trunk and consider it a bugfix. Th=
is is=20
not an active flaw that can be exploited by walking up to a random Zope s=
ite.=20
And nobody can find out other peoples passwords using this exploit out of=
 the=20
box. The point is that it is no more insecure then HTTP basic auth itself=
=20
which is the way many people authenticate over the web.

So lets just fix the bug, make the release(s) and those people affected c=
an=20
upgrade to the fixed release.

-Casey

On Monday 19 August 2002 10:48 am, Toby Dickenson wrote:
> On Monday 19 Aug 2002 3:06 pm, Shane Hathaway wrote:
> > Matt Behrens wrote:
>=20
> > and even those sites will still have to deal with the
> > very same risk even after the change: site managers should never brow=
se
> > to untrusted users' pages while logged in.
>=20
> >  Until we have
> > "hat-switching", it will never be safe for privileged users to browse=
 to
> > untrusted users' pages.
>=20
> Thats a bogus argument, for two reasons. With this current problem even=
=20
honest=20
> trusted users could accidentally write code that exposes users password=
s.=20
> Also it doesnt just affect site managers - all users who provide=20
> authentication would have to be careful (realistically, that is asking =
too=20
> much of most users)
>=20
>=20
> want an example? I have products that occasionally send the result of=20
> <dtml-var "REQUEST.text()"> by email, to widely accessible mailbox, ove=
r an=20
> untrusted network. It would be a big suprise if those emails should sud=
denly=20
> contain passwords if I should downgrade (;-) to FastCGI