Re: Session Fixation

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Thanks for the comments. I disagree with a few, let me know what

Then their users are still spoof-able and in all likelyhood, still running inadequately secured Windows boxen. Loose-loose. Frankly, it doesn't make XSS much (if any) harder, so what's the point?

> I'm not, and no one in my neighborhood is. And

Which is a higher bar to hit than stealing an SSL session cert how?

> That's a lot smaller

You're still making the same broken assumption that an IP address can accutally be counted on with anything approaching certainty. So long as this "security measure" relies on borked assumptions, it's still worthless. Were it relying upon a cryptographically strong token it assigned to you instead, then we'd be able to talk about some real value. Which is what SSL and/or good session management schemes do, which is why they are actually valuable. They don't rely on untrustworthy information that they can't verify.

Security measures that don't start with a root in strong mutual distrust are doomed to fail. This "feature" doesn't pass that test.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

> >Better yet, if the connection is encrypted

Um, we're talking about the same SSL, right? The one that creates a stateful network socket and keypairs on both ends and remains active (recoverable) until such time as one side invalidates its session keys?

You may indeed initiate a different HTTP connection for each page view (HTTP is not a stateful protocol), but I'd be quite suprised to find out that your app server is re-negotiating SSL credentials for each subsequent connection.

What you describe sounds vaguely like HTTP-S which, fortunantly, died a grizly death at the hands of SSL some years back.

> Once the tunnel's established, the http

What, specifically, prevents you (the app designer) from requesting some sort of hash from the SSL layer and using that? What part of the SSL/TLS RFCs forbid it? Different layers or not, you _can_ rely on garuntees provided by lower layers to build security at higher layers. Whether or not you choose to do this is up to you.

> I can't recall the last web site I've reviewed where I was NOT able to

Let's leave historically wide-open apps out of it for the time being ;-)

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

> WebLogic, Netscape Enterprise Server,

What was required to do that? Transfer of cookies? Movement of some other token? If so, then you've transfered the thing bearing proof, which is where the trust _should_ be placed. IP address "locking" is a farce, and if any of these systems are designed sanely, then what you describe isn't a defect, it's the correct behaviour.

> Take a practical example: I had a user that would view document images

So the app designer was a moron. Not really unusual. But "locking" against an IP isn't the right solution here. The right solution is to make it harder for your users to give up the keys to the kingdom. Cookies come to mind. I'm sure you can think up a dozen others.

> OK, sure, there's a user education issue, but geez, how much are we going

IMO, the developer gets all the blame on this one. Additionally, did said session ever time out? If not then the developer should probably be shot.

> >This topic has been discussed at length on this list, and every time it

This result could have been caused by any number of measures (such as the afformentioned SSL session checking, which is a much stronger check than what you propose).

Can we help you?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

> This particular application dealt with high value, low volume

That doesn't change the fact that, if indeed they were relying on IP addrs, they were still relying on a metric that they didn't control exclusively. Perhaps the environment can _help_ tip you off when something goes wrong, but explicitly stating that it's a "security feature" that can/should be at the discretion of the user is missleading. Missleading is not trustable. That which is not trustable is not secure.

You can draw your own conclusions where to go from there.

> I have my own IP address from my ISP. I turned on the feature because

Only if it helped you sleep better at night. Otherwise it was just wasting database space on their end and bandwidth on yours.

• -- Alex Russell alex@netWindows.org alex@SecurePipe.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+iLBToV0dQ6uSmkYRAkwgAJ43uZ16a9dGeI9sFDxxWrMEL4tMYgCgmBxQ rUP+FOol8DfJF6789NWhI7g=
=cts/
-----END PGP SIGNATURE----- Received on Mon Mar 31 16:25:07 2003