> On Thursday 07 February 2002 12:42, Bill Pennington wrote:
> > Ok maybe I am being a bit to grumpy here (or am I turning into a
> > curmudgeon?!?!?!?) but you can't do anything with the client IP
address on
> > the Internet, it is just not feasible. NAT/PAT/Proxies will break it
every
> > time.
>
> No, I don't really care if the IP is YOUR IP, as long as its consistent
> across a session. Very few implementations of NAT don't insure that.
Proxies,
> same thing. Use the same proxy for the life of the session, no problem.
>
> >
> > Hashing is good but I could steal the entire hash and still get in.
>
> No, you didn't listen to me, that is why you have to hash in something
unique
> to the client (or nearly so). IP number or domain name are feasible in
some
> cases at least. Otherwise you have to go to the "one time cookie" where
the
> server only accepts the cookie once, then gives you a different cookie
for

Hey,

It's called private-key cryptography. In order for this method to work,
there must be some information that the user cannot (within reason) know
placed into the data being hashed. A private key, accessible only to
the session-verification component, can be stored on the server. It's
not the best solution, but it solves some problems.

I wrote a package last August that used a similar scheme, but there was
an additional problem: we couldn't make a database call. The solution
was, as described below, to create a sessionID using a message digest,
or hashing, algorithm. The message passed to the algorithm was a
concatenation of information known by the user, and information known
only to the server. Creating a session id in this manner provides the
user (and possible attacker) with no information about our session-key
that could be used to reverse-engineer the processes of creation and
confirmation.

For the information provided to us by the user, we used the HTTP_REFERER,
REMOTE_ADDR, and a number of other application-specific values
gauranteed to be known and provided by a user most of the time. (Note,
I said MOST of the time.) This information was concatenated with a
private key. The authentication token was the string representation of
the hash-value of this information.

This key that I speak of was, of course, not meant to be used for very
long. It was intended to be somewhat disposable. Nor was the method
gauranteed to be very secure. It was merely an elegant solution to basic
web-app authenication needs. A successful attack did not cary much
weight, as the information being protected was not particularly valuable.
The system was flexible: securing the system following a successful attack
really only meant changing they private key, and patching whatever holes
allowed a user to access the key to begin with. Of course, SSL with
client-side authentication would be the best solution, but who in the
world wants to do that? <grrr>

The most important assumption made was the unreliability of the info
we were using for the message. If a client's IP address changed during
a session, guess what? That session was no longer valid, and they
were forced to re-authenticate. (In fact, most exceptions dumped the user
to a login page, but we were pressed for time.) All that mattered was
that most of the users could access most of the site most of the time.
The few random users whose IP addresses mysteriously changed between
sessions (null values were considered valid), were forced back to the
login page.

vert

On Thu, 7 Feb 2002, Security Coordinator wrote:

> On Thursday 07 February 2002 12:42, Bill Pennington wrote:
> > Ok maybe I am being a bit to grumpy here (or am I turning into a
> > curmudgeon?!?!?!?) but you can't do anything with the client IP address on
> > the Internet, it is just not feasible. NAT/PAT/Proxies will break it every
> > time.
>
> No, I don't really care if the IP is YOUR IP, as long as its consistent
> across a session. Very few implementations of NAT don't insure that. Proxies,
> same thing. Use the same proxy for the life of the session, no problem.
>
> >
> > Hashing is good but I could steal the entire hash and still get in.
>
> No, you didn't listen to me, that is why you have to hash in something unique
> to the client (or nearly so). IP number or domain name are feasible in some
> cases at least. Otherwise you have to go to the "one time cookie" where the
> server only accepts the cookie once, then gives you a different cookie for
> the 2nd request, etc. Once you do that its VERY hard for anyone to hijack it,
> and if the server is paranoid and blows away the entire session if it sees a
> bad cookie, then chances are pretty good that a hijacker doesn't get
> anywhere. Combine that with some IP checking and you're pretty good. Add in
> re-auth for critical functions, and I think things are real solid. If you
> need more than that, you should be using SSL.
> >
> > I had a couple of thoughts. Combine cookie values with URL values. For
> > example I have a cookie (hashed) that has some value, A=foo, where foo is
> > some pseudo random value. Then have a URL value that is B=foo+bar where bar
> > is a hard to guess value or the output of some math applied to foo. Store
> > all that junk in a DB and check it before dong any "sensitive"
> > transactions. Since the cookie is hashed the attacker will not know the
> > value of foo in order to get the output for the URL variable so the attack
> > has a much greater chance of failure. You could be nasty and destroy the
> > session if they start playing with the session ID (B) as well.
>
> Sounds good. ;o).
> >
> > I just slammed a few donuts so the sugar rush could have me a little loopy
> > at the moment...
>
> Well, I had a long hard day, so I'm cranky myself!!! hehe. I agree with you
> that it is at best HARD to totally stop someone from getting off one request
> on your session. We really need HTTP-NG.
> >
> > ----- Original Message -----
> > From: "Security Coordinator" <securityaptusventures.com>
> > To: "Gabriel Lawrence" <gabebutterflysecurity.com>
> > Cc: <owaspowasp.org>; <webappsecsecurityfocus.com>
> > Sent: Thursday, February 07, 2002 8:58 AM
> > Subject: Re: OWASP How to test cookie manipulation
> >
> > > On Wednesday 06 February 2002 11:29, Gabriel Lawrence wrote:
> > > > So, we've had some good debate about this one in the past where I've
> > > > worked. The big question I have is how does this really make it harder
> > > > for someone to bruteforce guess cookies? In some ways it may make
> > > > things a little easier because there is some part of the cookie hash
> > > > that isn't completely random. Instead if you used all the bits you have
> > > > in your cookie as purely random numbers (using a very good random
> > > > number generator) then you'd be looking at a very large numberspace
> > > > where the probability of guessing a cookie with a valid session behind
> > > > it is so small its just so unlikely. Add to this an absolute timeout
> > > > where users are forced to re-autenticate periodically and you have a
> > > > system that is impossible to bruteforce and assuming the sky does fall,
> > > > there is a limited exposure.
> > > >
> > > > Any thoughts?
> > >
> > > Well, you can make it totally bulletproof actually... 1st of all if your
> > > cookie values are hashes of a bunch of data they will be HARD to guess.
> >
> > MD5
> >
> > > hashes are pretty unpredictable...
> > >
> > > 2nd if you hash in something like the IP number of the client, then you
> >
> > can
> >
> > > do additional checking to verify that the request came from the same IP
> > > number (else you're test rehash won't match). So instead of storing the
> > > IP number on the server side in the session state database, just get it
> > > back from the web server (Apache request object stores that I believe for
> > > instance). Also you can create a DIFFERENT cookie value for each page
> >
> > access,
> >
> > > say by hashing in the server time and then you record that time in your
> > > session state database and use it in the rehash, thus making each cookie
> > > a "one time token".
> > >
> > > With those safeguards in place an attacker would have to spoof an IP
> >
> > number
> >
> > > to your server AND recover the response, which is very difficult. If you
> >
> > want
> >
> > > even MORE security, have the client run a javascript locally that asks
> > > for
> >
> > a
> >
> > > passphrase and have javascript hash THAT plus some other info into
> > > another cookie that changes with each page submission. I think that gives
> > > you
> >
> > pretty
> >
> > > close to complete integrity of the session.
> > >
> > > > -gabe
> > > >
> > > > On Wed, 2002-02-06 at 06:54, Security Coordinator wrote:
> > > > > The main point is that as long as you mix some data into the cookie
> >
> > hash
> >
> > > > > that the client CAN'T know, you should have a signature they can't
> >
> > forge
> >
> > > > > and it isn't too computationaly intensive to do an MD5 (twice
> > > > > actually due MD5's quirks) for every login.
>

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