Re: Doing Authorization using mod_perl from a programmersperspective

2001-12-10 Thread Daniel Little

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

2001-12-10 Thread Jon Robison

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

2001-11-19 Thread David Young

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

2001-11-16 Thread David Young

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

2001-11-16 Thread David Young

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.