Re: Re: Re: Re: Reading Foriegn Cookiesby termix (Beadle)
|on Dec 28, 2001 at 20:07 UTC ( #134895=note: print w/replies, xml )||Need Help??|
We've run into that once. Thankfully domains are not very difficult beasts to deal with. If I recall correctly, a cookie posted by www.domainone.com can be checked by any machine inside the domainone.com domain.
If your apache machine is named something like www2.domainone.com, you should be able to read that cookie.
If your apache machine is named www.domaintwo.com, simply create a new domain called 'apache.domainone.com' (you will have to get in touch with the owners of that domain to get this done). Have the apache server run also under the apache.domainone.com name. You don't have to get the complete application work under that domain, just the apache authentication part.
Of course, then you have to spent the regular one month trying to find all the possible places where things can be broken into and securing them, but that is a problem with cross domain authentication anyways.
the rest of this is discussion
A flaw in the logic of using cookies to pass authentication I would like to present. If the ONLY way your apache server knows that the 'browser' has a valid session on the IIS machine is through the cookie (which comes from the browser), you have an inherent security flaw: You are trusting the browser; not the IIS server. Okay, so the cookie is encrypted, but no one needs to be able to read it for the purpose of reusing it (or stealing someone elses session).
Unless the cookie encryption algorithm also incorporates an authority mechanism (i.e. a very short time out through an ever changing key etc.), you cannot tell if someone is trying to ride in one someone elses session. (or if the cookie was simply fabricated or copied from the past).
The method I would recommend is to have a 'back-hand-shake' in addition to the cookie. The IIS applicaiton should tell the Apache application (on a secure line of communication that is not public) that it is sending a new user over with a particular token. Then the apache application should check for that token. (of course, you have to make sure it is the right token being used by the right person and the only way I have dealt with this is to give the token a very short life span (30 seconds)).
And then there would have to be logic tests of all sorts. You don't want the IIS server to send the same user to you twice (without apache sending them back out at least once). You also want to worry about their session time outs (if they spent hours on the Apache site, their IIS session times out, but that is the very session the Apache site is trusting, no?).
Sorry, I seem to have gone on and on about this without realizing that the specific situation you are dealing with might not call for this level of security (read: paranoia).
In Section Seekers of Perl Wisdom