Re: Session Fixation Vulnerability in Web Based Apps
James A. Donald wrote: -- On 12 Jun 2003 at 16:25, Steve Schear wrote: http://www.acros.si/papers/session_fixation.pdf Wow. This flaw is massive, and the biggest villain is the server side code created for Apache. When you login to your bank, your e-gold account, your stockbroker, or your domain registrar, someone else can share your login. It is a security design error in the development environments for active server pages (all of them) . Every such development environment will have to be changed, and every login script written for existing environments needs to have some kind of workaround cobbled into it. The ideal solution is to change the development environment so that your session identifier is linked to the shared symmetric key used in any https conversation during that session, which requires tight coupling of https and development environments for active server pages. In the long term, https must be amended to have a concept of login and session, and make that sessionID available to the server side coding environments. 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. I suggest you read and think more carefully. I will agree that an incautious implementor could get bitten by these attacks, though. 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]
Re: Session Fixation Vulnerability in Web Based Apps
-- 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 [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
-- On 14 Jun 2003 at 21:42, Ben Laurie wrote: The obvious answer is you always switch to a new session after login. Nothing cleverer is required, surely? I had dreamed up some rathe complicated solutions. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ocf99Mr7YN0oLlYWkZsE57yUHWMocE0Z+gK2yQOU 4RiX1d4bEHzLkunxq2FfwXmWFdySguhagGnZR4U7X - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
