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 [EMAIL PROTECTED]
