Re: post to bugtraq about "session fixation"

["Panayiotis A. Thermos" <pthermos () telcordia com>]

Based on the paper's description  it appears that
there are two critical points for this attack to succeed:

     a) attack the victim's browser and set the Session-ID:
          which I think is an erroneous assumption especially for
          banking applications.
                     If a browser tries to use a session ID with a web
application
                     other than the one that it has issued the session ID,
it will fail.
                     Well developed web applications will not accept
session id's
                     set by the user! It defeats the purpose of user
session management.


                b) Compromise the web application in order to issue a
specific session ID
                      that it was generated by the attacker. In this case,
if an attacker has already
                     compromised the web application/server they  can
manipulate or gather
                     sensitive information without going through the
exercise of setting  their own
                     session ID generator. Does "man in the middle" attack
sound familiar?

The paper states that this vulnerability exists in "almost  all web based
systems
(including many high profile web banking systems) that we've ever come
across".
I'm curious to see if there are any credible  statistical information to
support this
conclusion. Not to be picky, but when you say in 15 pages that "there is a
major
vulnerability in Web based banking applications", it can cause arrhythmia
(a change in the rhythm of your heartbeat ) to some people that maintain
and develop web financial applications.

So providing verifiable and usable information is helpful versus some
scenario
that is supported with assumptions and generalizations.




                                                                                                              
                    securityarchitec                                                                          
                    t () hush com              To:     webappsec () securityfocus com, alex () netWindows org          
                                            cc:     (bcc: Panayiotis A. Thermos/Telcordia)                    
                    12/18/2002 02:28        Subject:     Re: post to bugtraq about "session fixation"         
                    PM                                                                                        
                                                                                                              
                                                                                                              






With respect I think its a great marketing paper but nothing more. You
should never allow the same token to be used over HTTP that is then valid
over SSL. At least one variant of this attack relies on that assumption.

Correct way if for the user to enter username and password over SSL and
session cookie is set to that browser session over SSL. A pre-fixed cookie
would get you to the public site (which maybe customized for a user
experience but not show logged in details) but shouldn't get you to
anywhere other than a login screen.

This paper also assumes that application session management is closely tied
to web server session management. IMHO its not and this is a good reason
why not. People think it is cause IIS and others still sends ASPSession IDs
by default but just because the cookie protcol says they get returned if
the domain path matches, doesn't mean to say they get processed by an app.

This is nothing new (although a good write-up).

On Wed, 18 Dec 2002 12:13:26 -0800 Alex Russell <alex () netWindows org>
wrote:
> 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



Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Big $$$ to be made with the HushMail Affiliate Program:
https://www.hushmail.com/about.php?subloc=affiliate&l=427