[13623] in cryptography@c2.net mail archive
Re: Session Fixation Vulnerability in Web Based Apps
daemon@ATHENA.MIT.EDU (James A. Donald)
Fri Jun 13 18:22:50 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: "James A. Donald" <jamesd@echeque.com>
To: cryptography@metzdowd.com
Date: Fri, 13 Jun 2003 15:17:56 -0700
In-reply-to: <20030613181626.46567.qmail@web41104.mail.yahoo.com>
--
On 12 Jun 2003 at 16:25, Steve Schear wrote:
> > > http://www.acros.si/papers/session_fixation.pdf
"James A. Donald"
> > Wow.
> >
> > This flaw is massive, and the biggest villain is the server
> > side code created for Apache.
On 13 Jun 2003 at 11:16, tom st denis wrote:
> You really lack some fundamental understanding.
>
> https uses a secure private link to create a private http
> session. It has NOTHING todo with authentication nor
> identity.
If https really had nothing to do with authentication or
identity, that would be a very great flaw indeed.
The defect described by Steve Schear has the result that an
https session has no direct equivalence to what the server code
that accepts a password sees as a session.
Thus the real user can have one https session, and the attacker
a different https session, and server side code may well think
they are one and the same session, allowing the attacker to
modify the target user's account while the target user is
logged in.
To make the system entirely secure against this attack, we need
to be able to enforce a one to one mapping between login
sessions and https sessions. The existing tools for writing
server side code do not provide us with any direct means of
enforcing such a relationship.
> For example, when you first login to say yahoo [for email]
> you're on https. Even before yahoo knows who you are. Think
> of a verbal handshake in the "get smart" cone of silence..
Trouble is, that as Steve Schear has just demonstrated, it is
not a cone of silence. The environments for writing server
side code does not permit the server side code to know which
https session a client request is coming from. Thus the user
logs in, and then the attacker sends a request from a
completely different computer in a completely different https
session, and the server side code will treat is as if it was a
request from the user, enabling the attacker to do transactions
on your bank account while you are logged in to your bank.
> The fact that people randomly give away *their* secrets
> doesn't mean the system is flawed. It means the people are
> ignorant.
The attack described Steve Schear does not involve giving away
secrets. Rather it relies on the fact that there is no easy
way for the server side code to enforce a one to one mapping
between login sessions and https sessions. The server accepts
an request from the attacker as if he was the currently logged
in end user, even though the attacker is in a completely
different https session.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
F02/E7jwR2ptvCs0wMAjvVQ3252ZqQj1v9IfOMUQ
4SzwtxVqooT5OUw1MxnZaPDp5Hq7bikFt9LRlvk85
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
