Aloha, David.

> Facts of life:
> a) sometimes a single person shows up as multiple ip addresses

I suggest that you quantify this and analyze the
scenarios where a legitimate user ends up appearing
as multiple IP addresses. Yes, it happens. But in my
experience, it is effective server-side security
policy to force the user to reauthenticate in order
to keep the session alive on the server when an IP
address change occurs.

If you live in fear of the uncontrollable nature of
the Internet's addressing system, you end up
designing systems that are unnecessarily insecure
simply because you've given up hope of increasing
the level of security you can achieve. It isn't
acceptable server-side security policy to permissively
allow any request from any IP address to participate
in a session initiated by an authenticated user who
originally authenticated from a particular IP address.
A change of IP address must be viewed from the server's
perspective as fatal to the session's integrity.

There are scenarios in which a user's credentials
should even be temporarily locked-out based solely
on an IP address change from the client during a
secure session.

Aloha & Mahalo,

Jason Coombs
jasoncscience.org

-----Original Message-----
From: Cushing, David [mailto:David.Cushinghitachisoftware.com]
Sent: Monday, May 06, 2002 8:51 AM
To: Security Coordinator; Ingo Struck; Shields, Larry
Cc: webappsecsecurityfocus.com
Subject: RE: defense against session id replay attacks

SC,

> Yeah, I have to agree with Ingo. Its fine if you want to
> build a web app that DOES cater to those people, but don't
> even PRETEND you can make it secure!

Aren't we all pretending that we can turn a stateless session from an
non-trusted source into a stateful session from a trusted source? <g>

Facts of life:
a) sometimes a single person shows up as multiple ip addresses
b) sometimes more than one person show up as a single ip address

Many companies proxy web traffic through a single point. Two people can
browse the web from the same Linux box. Load balancing software can
send my requests to two different ISPs on-the-fly. Who you think you
are catering to? This is how the technology works.

The IP address of the requester is _not_ a positive identifying
characteristic.

Having said that, if you are in full control of your servers, clients,
and the devices in between, you may enforce the restriction that a user
can only come from one ip address. But it is an artificial restriction
that will break once brought outside your controlled environment.

> The best you can do is limit the damage that can be done via
> fairly trivial types of attacks, like CSS or session
> hijacking. Beyond that its a lost cause, though personally I
> would say that if you need more than that you need SSL anyhow.

I don't understand your point.

Throwing SSL into the mix here adds nothing [unless you are going to use
client certificates to improve authentication]. Standard use of SSL
[with server certificates] only gives you confidentiality. It doesn't
give you authentication, nor does it help you hold session state across
requests.

Mind you, all sites should use SSL during authentication to prevent
snooping credentials, but a session id/cookie is still needed to
maintain state of the "login" from page load to page load.

> beyond that you really have to use SSL. I mean I won't even
> use a non-SSL based webmail system. Why should I? They're
> totally vulnerable to 100 ways of being subverted and I DO
> consider my email important...

The only difference between the two is that one is not snoopable.
Granted, this is a good thing, but you seem to be thinking you are
getting more than that. I bet your SSL email site still uses a session
cookie to keep track of your session.

Regards,
David

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]