[pubcookie-dev] Interesting multiple server behavior

[Bradley Schwoerer]

We don't want single sign-on between the prod, dev, and test systems.  We
were doing some testing of single sign-on between the migration of
weblogin.services.wisc.edu to login.wisc.edu.  We did have, for testing, the
cookie scoped at .wisc.edu.  We had already decided not to do this because
of the security problems, even though our window of exposure would have been
short in duration while the app admins switched over.

The issue it identified though was a possible DOS.  With the cookie scoped
properly at login.wisc.edu a person in the .wisc.edu domain could set a
pubcookie_l cookie at wisc.edu.  This would send both the login.wisc.edu and
the wisc.edu pubcookie_l cookies to the login server at login.wisc.edu.  The
login server can not handle multiple pubcookie_l cookies and asks the user
to re-authenticate.  This will always happen until the pubcookie_l  cookie
at .wisc.edu expires.


-Bradley 



On 10/11/05 12:01 PM, "Nathan Dors" <dors at cac.washington.edu> wrote:

> Here at UWash we have dev, test, and production environments, but
> they're logically different services. It seems a bit strange to
> want single sign-on between them. We have fewer than 10 people who
> ever use the dev environment, maybe 1000 people who frequent our
> test environment, and then everyone else uses only the production
> environment.
> 
> Questions about your general motivations aside, I don't think you
> can use .wisc.edu as your login server cookie domain. Wouldn't
> that overexpose the login cookie? The threat model assumes the
> login cookie will only ever go back to login servers; there are no
> protections on it like there are for the granting cookie, which
> when using the classic cookie-based login method, is exposed to
> the whole enterprise domain and therefore requires the pre-session
> cookie for protection. To use login_host_cookie_domain you really
> need your login servers to be in their own exclusive subdomain.
> 
> -Nathan
> 
> On Fri, 7 Oct 2005, Bradley Schwoerer wrote:
> 
>> We were doing some testing in our different environments (dev, test,
>> production) and ran across a DOS of sorts.  We had defined
>> "login_host_cookie_domain: wisc.edu" in one of our environments to see if
>> going from weblogindev.services.wisc.edu to logindev.wisc.edu was possible
>> in dev with both up at the same time and logging into one would work for the
>> other.  This way we could eventually do prod the same way.  This works for
>> one environment at a time.  We could define pubcookie_l_dev,
>> pubcookie_l_test, and pubcookie_l to make it work.
>> 
>> To make a long story short if a browser sends two pubcookie_l cookies to the
>> login server it would break the single sign-on.  This is due to the code
>> only looking at the first of the two cookies.
>> 
>> We are looking into having the login server iterate through the cookies
>> until it could decrypt one and then make the assumption that this is the
>> cookie we want.  By not doing this, someone in the same domain scope could
>> poison the login cookie by setting some arbitrary pubcookie_l cookie at the
>> highest scope.
>> 
>> I know this is not well written but I am trying to get out of here for the
>> weekend.  :)
>> 
>> 
>> -Bradley Schwoerer
>> 
>> 
>> _______________________________________________
>> pubcookie-dev mailing list
>> pubcookie-dev at u.washington.edu
>> http://mailman1.u.washington.edu/mailman/listinfo/pubcookie-dev
>>