Re: Session Fixation

[Alex Russell <alex () netWindows org>]

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

> Thanks for the comments.  I disagree with a few, let me know what 
> you think:
>
> > On Monday 31 March 2003 07:19 am, Information Security wrote:
> > > I recently visited a site (I think it might have been my bank) where
> > > they actually had an option for "additional security" where you could
> > > link the session to your IP address.  I was impressed, and thought it
> > > was a great option, but I'm not sure how many non-security folks
> > > would.
> >
> > I'm afraid I fail to see the value. What if you're an AOL subscriber?
>
> But what if you're not?  

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
> what about all those corporate users?  They're typically hidden behind a
> proxy / NAT device and all share one address, but someone else in the
> company would have to steal the session id.

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

>  That's a lot smaller
> population than everyone on the internet.  I think this is a "half full /
> half empty" discussion, and we probably should leave it at that.

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.

> > Better yet, if the connection is encrypted
> > with SSL (it is, isn't it?), you've already bought AT LEAST this much
> > security (an attacker would have to comprimise your session key in order
> > to spoof your session, not just something as trivial as an IP addr).
>
> I disagree.  Each request to the web site builds up a new SSL connection,
> with a new SSL symmetric key.  

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
> session key (aka session id--or more approprately, a session token) is
> sent to the server to establish identity to the web application.  SSL and
> the session token operate on different layers.  The session token is not
> linked to my IP address, nor to anything related to the SSL tunnel.

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
> forward a session from one PC to another, with both PCs on very different
> subnets.  Outlook Web Access, IIS, 

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

> WebLogic, Netscape Enterprise Server,
> Domino, Websphere...none care if a session is moved from one IP to
> another, regardless of whether or not SSL is in use.

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
> on a secure website.  If she had a question about a particular document,
> she'd e-mail it to someone else by selecting "File | Send | Page by
> e-mail" to someone else.  The session was managed by URL re-writing, so
> the token went along with the mail message to the other user, and they
> could view more than just the document they'd been sent--all the links on
> the page stayed active. 

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
> to blame on the user, and how much are we going to blame on the developer?

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
> > is, the consensus is reached that "binding" some session identifier to
> > an IP address is not only innefectual, it provides a false sense of
> > security.
>
> Again, I disagree.  In one web application review, when I forwarded a
> session between two different subnets, it generated a phone call directly
> to me. 

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).

> This particular application dealt with high value, low volume
> transactions, and they had a 24x7 data center that monitored for
> anomalies like this.  Like everything else, it's a matter of how much
> risk you're willing to accept.  This company was unwilling to accept the
> risk, and their mitigation strategy required a manned and knowledgable
> operations staff able to respond.

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
> without it, someone might be able to steal my session id (session
> fixation, XSS, etc); however, with the option on, my session can only be
> used by my IP address.  That provided value to me, don't you think?

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-----