Re: Session Fixation Vulnerability in Web Based Apps

2003-06-17 Thread Ian Grigg
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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-16 Thread Matthew Byng-Maddick
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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-15 Thread James A. Donald
-- 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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-15 Thread Rich Salz
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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-15 Thread Ng Pheng Siong
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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-15 Thread Adam Back
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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-14 Thread Ben Laurie
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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-14 Thread 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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-14 Thread James A. Donald
-- 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

Re: Session Fixation Vulnerability in Web Based Apps

2003-06-13 Thread tom st denis
--- 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

Session Fixation Vulnerability in Web Based Apps

2003-06-12 Thread Steve Schear
http://www.acros.si/papers/session_fixation.pdf A Jobless Recovery is like a Breadless Sandwich. -- Steve Schear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]