post to bugtraq about "session fixation"

[Alex Russell <alex () netWindows org>]

I don't know if anyone else has seen this yet:

        http://online.securityfocus.com/archive/1/303838/2002-12-15/2002-12-21/0

but I thought it would be on topic here. I realize that it's something of a 
rehash of the session authentication discussions we've had before, but I'd 
like to point out that it does expose a weak property of the "one sessionID 
for everything" model that's been proposed thust far, which is that it does 
not allow a interaction with the client to re-instate whatever security may 
have been previously broken.

I think that in earlier discussions, I wasn't able to adequately articulate 
why I felt that issuing a new nonce for ever privledged operation made more 
sense (and why, correspondingly, you should never send the "real" session 
ID along with said nonce), but this article confirms what my gut was 
telling me: if you guard each action individually and require that there is 
a continuious line of known good iteractions, you'll be safer in the long 
run. 

The paper also points out the folly of assuming that client input is somehow 
"right" without validating it. Why in the world would an app server ever 
allow the end user to present to it the session ID that it will use for 
that client's continued interactions?

-- 
Alex Russell
alex () netWindows org
alex () SecurePipe com