Session Fixation Vulnerability in Web Based Apps

[Ben Laurie]

James A. Donald wrote:

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

The obvious answer is you always switch to a new session after login.
Nothing cleverer is required, surely?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


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