Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Re: Re: Reading Foriegn Cookies

by ppg (Initiate)
on Dec 28, 2001 at 17:19 UTC ( [id://134869]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Reading Foriegn Cookies
in thread Reading Foriegn Cookies

Think I've got,
After RTFM, I found you only get access to cookies from your domain and currently the IIS and Apache systems are sitting on different domains.
Sorry.

Replies are listed 'Best First'.
Re: Re: Re: Re: Reading Foriegn Cookies
by termix (Beadle) on Dec 28, 2001 at 20:07 UTC

    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).

    -- termix

Re: Re: Re: Re: Reading Foriegn Cookies
by count0 (Friar) on Dec 28, 2001 at 19:46 UTC
    Fortunately, this isn't a limitation of the modules, or of Perl. This is the ways cookies are designed and implemented. You may wish to read RFC 2965, Unofficial cookie FAQ, or Netscape's brief cookie description.

    What if you could retrieve cookies from another domain?
    Imagine this scenario...

    You visit some great bookstore, buy some books, allow them to save your credit card number for your many future visits. Then somebody on irc invitse you to check out his new webpage, www.some-kiddiots-webpage.com, so you do. A clever Perl script at this site pulls all your cookies from your browser, ignoring the fact that they aren't in its domain, and "uh ohhh", your bookstore session is one of those cookies. Next day.. you have a $30,000 bill from your credit card company...

    oooops ;)
Re: Re: Re: Re: Reading Foriegn Cookies
by Fastolfe (Vicar) on Dec 29, 2001 at 09:24 UTC
    Your requirements seem to imply that the IIS side of this site is already setting and reading these cookies correctly. If this is the case, the domain attribute must already be set up correctly for the site and the browser should be cheerfully offering up the cookie. If this is the case, you should have no problem doing this stuff in Perl.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://134869]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2024-03-28 19:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found