Session Fixation Vulnerability in Web Based Apps

[James A. Donald]

    --
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 at metzdowd.com