Session Fixation Vulnerability in Web Based Apps

[James A. Donald]

    --
James A. Donald wrote:
> > This flaw is massive, and the biggest villain is the server 
> > side code created for Apache.

Ben Laurie
> This isn't the case. I analysed several sites I work on for
> attacks of the type described when this paper first came out.
> None of them were vulnerable.

In the development environments that I am familiar with, the
code environment assumes one is using a session cookie.  If you
are using a session cookie automatically generated by the
environment for state management, if you are using the state
management supplied by the development environment, this flaw
will bite you.

To avoid it, one has to roll one's own state management, for
example by providing one's own cryptographically strong login
label in the Urls in the web page one generates in response to
a login, the label acting as primary key to a table of
currently active logins.

How did you do your state management, and why did you do it the
way that you did?

For the environments that I am familiar with, if one did a
server side coding for a login in the way the environment was
designed to be used, that login code would be flawed.

I do not see how this flaw can be avoided unless one
consciously takes special measures that the development
environment is not designed or intended to support. 

    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     kTr+tGmv2Tc7wtpF2vCQqPhk5dxOUN1yhHOu2VtM
     4uKcnZA607mHi4kFhb+yzpP4NHwUS/DukGoP89sdV


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com