RE: Cosign Loop Breaking

["Brett Lomas" <b.lomas@xxxxxxxxxxxxxx>]

Hi all,

I believe the bad configuration is having the action on the login form set
incorrectly (at least this is the one I know about). If the action is set
such that apache redirects (or re-writes the URL) via a GET rather than a
POST it will lose the data attached, and then the CGI displays the login
page.

I agree that this is a case of bad configuration, and perhaps, after further
thought I do not think it would really be worth extra work to detect it. If
the Sys Admin sets it up incorrectly then that is their fault. Perhaps a
good thing would be some detailed installation documentation which would
help this problem (and others) to no end.

Cheers

Brett

-----Original Message-----
From: Cory Snavely [mailto:csnavely@xxxxxxxxx] 
Sent: Wednesday, 9 June 2004 7:38 a.m.
To: Cosign Discussion
Subject: Re: Cosign Loop Breaking

What Mark says strikes a chord with me. In particular, my first reaction 
was that it's "not your problem", and similar to what Mark said, a 
somewhat disturbing notion: specific code in COSIGN to deal with 
somebody's weirdo application. 8)

But maybe I've just offended the person with the weirdo application 8), 
and maybe the rationale for having protection from this in COSIGN is 
clearer if we know the types of misconfigurations where this can happen. 
Could you share more details?

It may be worth noting that in either case the user is not particularly 
well served; although having this feature in COSIGN provides for an 
elegant exit, the user is likely still just as stranded. My point here 
is it's tough to justify based on the user experience.

Mark Montague wrote:
> On Thu, 3 Jun 2004, johanna bromberg craig wrote:
> 
> 
>>There are a few misconfigurations that can cause a loop where a service
>>will set a cookie, redirect back to the central cosign server, which
>>will try and register the cookie, succeed, redirect back, where the
>>"check" will fail, set a new cookie, redirect, re-register, etc. This
>>will go on until the browser detects "too many redirects" ( this
>>threshold varies by browser ) at which point a very unhelpful message
>>will be thrown by the browser and the user is "stranded."
>>
>>I propose that we add some code to the cgi that keeps track of the
>>number of REGISTERs in a given time period.  Our current idea is to
>>tack on a time stamp and a count to the end of the login (cosign=)
>>cookie, so we'd have:
>>
>>cosign=[random_bits_here]/[time in seconds]/[number of registers since
>>that time]
>>
>>If a give login cookie exceeds X registers in N seconds, the cgi can
>>throw a proper error screen giving the user some *actual* information.
>>:) The current defaults I'm thinking of are 10 registers in 30 seconds.
>>This is fairly arbitrary, and just where I'm starting?
> 
> 
> I've thought about this for a while.  The solution seems like it
> will work, and I can't think of problems that it would cause.  I
> can't think of any advantage that a person could obtain by
> deliberately falsifying the time or number of registers in their
> cookie that they couldn't obtain currently simply by making up
> their own cookies themselves from scratch.
> 
> I'm less than 100% comfortable with this solution, though, because
> I don't know that it's the best solution to the problem; you just
> say "there are a few misconfigurations that can cause a loop".
> What are these misconfigurations?  I'd like the chance to explore
> them and see if someone on the mailing list can come up with a way
> to ensure that the misconfigurations never occur as a preferable
> option to making the cookie more complicated and adding extra
> functionality and special-case logic to the "core" part of the
> cosignd code.  It may be that the solution proposed is the best
> one; my point though is I don't know that because it's not clear
> to me what sorts of misconfigurations are causing the problem.
> 
> I'm not saying "don't implement the proposed solution", I'm just
> sharing my thoughts in general.
> 
>                 Mark Montague
>                 LS&A Information Technology
>                 markmont@xxxxxxxxx