Re: Session Fixation Vulnerability in Web Based Apps
Ben Laurie wrote: James A. Donald wrote: 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? Having read all these discussions and having looked in my own PHP code and the PHP documentation, I have to agree with James D. This cleverness challenges! I knew how to start and maintain a session, I think. (That was no easy task. The PHP documentation is a mess, and over the last several versions different ways started and stopped working... I'm sure the obvious answer is to use a better tool, but I'm a bit stuck with a huge dose of reality at the moment, being one of the million or so PHP developers, and can't junk the man-years of habit just this month :-) I just spent an hour or so skimming the doco for PHP, and apparently, there is an ability to set another session id with a call called session_id(), oddly enough :-) Which only leaves the problems of a) inventing a new session id, b) rewriting the code so that it carefully implements the unclever notion of setting this at the new login, c) deleting this at logout, and finally d) praying that this works as expected. On the face of it, PHP doesn't appear to have much support for this. It will require each developer to (re-)implement their own solution. I'd love to be wrong in this: does anyone know how the easy way to secure a PHP website against session_fixation? Or is it another case of you gotta write it all yourself again? Rich Salz wrote: From http://www.modssl.org/docs/2.8/ssl_reference.html#ToC25 The following environment variables are exported into SSI files and CGI scripts: SSL_SESSION_ID The hex-encoded SSL session id Care to try again? Please. How does one get access to that in PHP? That would be a wonderful answer to a) above. Which would only leave me with b) thru d) :-( PS: Steve, thanks for the aviso! Very interesting attack! -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
On Mon, Jun 16, 2003 at 10:47:04AM +0100, [EMAIL PROTECTED] wrote: session id). Authentication of subesequent pages is assumed only if the client's IP address matches the IP address stored in the session variable corresponding to the client's session. Is this secure? If not, why not? It's not a question of whether it's secure or not, in any kind of environment with distributed proxies, it just plain won't work. A more useful fix is to not allow arbitrary sessionids to be created, and generate the state on login, and destroy it on logout. There may be a condition I've missed with this, but I'm not sure. MBM -- Matthew Byng-Maddick [EMAIL PROTECTED] http://colondot.net/ - 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 19:07, Rich Salz wrote: When I've done login and state management, it's all maintained on the server side. It's completely independant of SSL sessions -- that's transport, has no place in application -- just like it's completely independant of HTTP/1.1 session management. A logout page isn't the same as Connection: close :) The only thing in the cookie is an opaque identifer. It's purely random bytes (for which OPenSSL's RANDbytes() is useful), Which is fine provided your code, rather than the framework code provided the cookie, and provided you generated the cookie in response to a valid login, as Ben Laurie does.. The framework, however, generally provides insecure cookies. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG hOTy2gXIGpC8U37+/qzVoX8ytaUtHZWZGueU4kX5 4GiXuHCpc1B85Pv2WN8p5d7FESFJMHlg5qC2hqlGr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
The framework, however, generally provides insecure cookies. No I'm confused. First you said it doesn't make things like the session-ID available, and I posted a URL to show otherwise. Now you're saying it's available but insecure? /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
On Sun, Jun 15, 2003 at 11:34:55AM -0700, James A. Donald wrote: Which is fine provided your code, rather than the framework code provided the cookie, and provided you generated the cookie in response to a valid login, as Ben Laurie does.. The framework, however, generally provides insecure cookies. Dynamic programming environments like Lisp, Smalltalk and Python allow the application programmer to replace parts of a framework with other code easily. Lisp does it better than Python. Dunno about Java, PHP, whatnot. Build your applications with a superior programming system. -- Ng Pheng Siong [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Session Fixation Vulnerability in Web Based Apps
I think he means higher level frameworks, web programming libraries, toolkits, and web page builder stuff; not hooks into SSL sessions. Not to say that a hook into an SSL session is not a good place to get an application sessions identifier from -- it would be, presuming that you can't trick a browser into adopting someone else's SSL session. I wouldn't know one way or the other if these higher level frameworks fall victim to the session adoption problem as I haven't used them; but it seems plausible that there might exist some that do. If this were the case it would be quite bad as there would presumably be many users of them who had relied on the security of the high-level framework. But I would be suprised if most or many of them did for similar reasons to the reason people are expressing doubt that many hand coded login pages would be affected: it seems like generally a mistake natural login and session managing web programming idioms would not lend themselves to. Adam On Sun, Jun 15, 2003 at 05:52:17PM -0400, Rich Salz wrote: The framework, however, generally provides insecure cookies. No I'm confused. First you said it doesn't make things like the session-ID available, and I posted a URL to show otherwise. Now you're saying it's available but insecure? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
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]
Re: Session Fixation Vulnerability in Web Based Apps
--- James A. Donald [EMAIL PROTECTED] 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. 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. 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.. The fact that people randomly give away *their* secrets doesn't mean the system is flawed. It means the people are ignorant. Tom __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
