|
|||||||||||
|
RE: Session Fixation
From: Information Security <InformationSecurity(at)federatedinv.com>
Date: Mon Mar 31 2003 - 15:08:07 EST
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:
>Better yet, if the connection is encrypted
>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
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. >provides no real security value. Use it if you want to feel better about
Well, you can start ranting again. Or maybe we should both just stop belaboring an old issue...thanks for bending an ear anyway. Received on Mon Mar 31 15:24:34 2003 This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:49 EDT |
||||||||||
|
|||||||||||