Re: Doing Authorization using mod_perl from a programmers perspective

[David Young <dy...@nettonettech.com>]

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

[Daniel Little <da...@metrex.net>]

From: "Jon Robison" <jo...@uniphied.com>

> 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

[David Young <dy...@nettonettech.com>]

I would still say this is dangerous. There is no guarantee that the same
client will use the same IP and/or socket every time. Think about the
thousands of AOL users behind hundreds of proxies. There is no consistency.
Even with 10 users behind one NAT firewall I bet you'll have problems.

> From: Jon Robison <jo...@uniphied.com>
> Date: Mon, 10 Dec 2001 18:06:00 -0500
> Cc: modperl@apache.org
> Subject: 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

[Jon Robison <jo...@uniphied.com>]

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.