RE: Session Fixation

[Information Security <InformationSecurity () federatedinv com>]

Alex,

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

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

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

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

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

> >  But the nice
> > thing was that the communications--calling it an "additional security
> > feature" rather than something very technical.
>
> Hrm, one might take them to task for even mis-labeling that. More 
> appropriately it could be "additional feautre we thought would be neat, but

> provides no real security value. Use it if you want to feel better about 
> not really doing anything about security."

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?

> Ok. I'll stop ranting now.

Well, you can start ranting again.  Or maybe we should both just stop
belaboring an old issue...thanks for bending an ear anyway.