Re: Doing Authorization using mod_perl from a programmersperspective
From: "Jon Robison" <[EMAIL PROTECTED]> > What about sockets? I am in the middle of trying to use $c = > $r->connection and $c->remote_addr as part of the cookie name. (So far > I am having trouble with the fact that remote_addr returns packed info, > and I am still searching for how to unpack it - if you know, tell me!). > > It's not 'foolproof', but how many casual cookie stealers can force > their browser to use a particular socket? How would this be effective? If multiple users are behind a firewall that uses NAT, they will all have the same remote IP address. As for the remote port, that changes from connection to connection so it's not possible to use it as a reliable indicator either.
Re: Doing Authorization using mod_perl from a programmersperspective
To insert a new comment on this old item: What about sockets? I am in the middle of trying to use $c = $r->connection and $c->remote_addr as part of the cookie name. (So far I am having trouble with the fact that remote_addr returns packed info, and I am still searching for how to unpack it - if you know, tell me!). It's not 'foolproof', but how many casual cookie stealers can force their browser to use a particular socket? This little method would even allow me to open multiple windows into a secured area, each with a different username, etc. (Very usefull during user interface development, etc. where menus differ based on some criteria for users) --Jon Robison David Young wrote: > > fliptop wrote: > > Joe Breeden wrote: > >> > >> How does this work in an environment with two (or more) computers with the > >> exact same configuration, and probably the same HTTP_USER_AGENT behind the > >> same proxy? How do you know that one user isn't using another users session? > > > > you don't. the session hijacker still would need to know the real > > user's username, password, and HTTP_USER_AGENT configuration. > > The session hijacker would not need to know the username and password. They > would only need to sniff the cookie from the network, and then send it from > a client identifying itself as the same User Agent. > > > my point > > was that this solves the problem of using the ip address in the md5 hash > > when the client is behind a proxy server. > > This does not solve the problem: IP address of users behind Proxy is not > unique. The User Agent is not unique either. Using User Agent solves > nothing, and is in fact far less secure, since the client can set the User > Agent header to be just about anything. At least the IP address has to be > correct (but not unique) if the client wants to get a response.
Re: Doing Authorization using mod_perl from a programmersperspective
There seems to be some confusion over exactly what we're talking about... Apache::Session may work fine for creating a unique session ID, however this thread has really been about how to ensure that a session hasn't been hijacked. People have been suggesting various bits of info they could get from the client (IP, User Agent) and set in the cookie, thereby ensuring that the cookie is coming back from the client to whom they sent it. There isn't anything you can use that will work 100%. The only way you can ensure that your cookies aren't being hijacked is to only send them over an SSL connection. > From: Jon Robison <[EMAIL PROTECTED]> > Date: Mon, 19 Nov 2001 10:47:33 -0500 > To: "Randal L. Schwartz" <[EMAIL PROTECTED]> > Cc: fliptop <[EMAIL PROTECTED]>, "Jonathan E. Paton" > <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Doing Authorization using mod_perl from a programmers perspective > > How about using an Apache::Sessions id instead of IP address?
Re: Doing Authorization using mod_perl from a programmersperspective
Yes I remember reading about this some time ago. Of course I am short on specifics, but IIRC those were some sort of signature put in by ISPs who were bundling IE, and the id transmitted only configuration info but not specific user details. > From: Stephen Adkins <[EMAIL PROTECTED]> > Date: Fri, 16 Nov 2001 12:13:48 -0500 > To: Joe Breeden <[EMAIL PROTECTED]>,[EMAIL PROTECTED] > Subject: RE: Doing Authorization using mod_perl from a programmers perspective > > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::81100320025802f901780505000b > > This indicates to me that some vendors who distribute MSIE 5.0 > on their PC's include some sort of ID in the HTTP_USER_AGENT > that the browser reports. (!?!) (privacy advocates beware!)
Re: Doing Authorization using mod_perl from a programmersperspective
fliptop wrote: > Joe Breeden wrote: >> >> How does this work in an environment with two (or more) computers with the >> exact same configuration, and probably the same HTTP_USER_AGENT behind the >> same proxy? How do you know that one user isn't using another users session? > > you don't. the session hijacker still would need to know the real > user's username, password, and HTTP_USER_AGENT configuration. The session hijacker would not need to know the username and password. They would only need to sniff the cookie from the network, and then send it from a client identifying itself as the same User Agent. > my point > was that this solves the problem of using the ip address in the md5 hash > when the client is behind a proxy server. This does not solve the problem: IP address of users behind Proxy is not unique. The User Agent is not unique either. Using User Agent solves nothing, and is in fact far less secure, since the client can set the User Agent header to be just about anything. At least the IP address has to be correct (but not unique) if the client wants to get a response.