-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark,
I have a few questions myself. See inline. Mark Thomas wrote: | Annony Mouse wrote: |> 2.) If (1) is fact, can the exploit expose ALL Session IDs? Is it |> dumping all of the data in all the sessions, or 'just' the sessionID |> map? | | The worst case is that the attacker will obtain the ID for the current | session. With this the attacker has access to the session as the current | user. Who is "the current user"? If the attacker already has the session id, there's no need to hit the server to ... obtain the session id, right? Knowledge of the id of a session pretty much gives someone the right to act as that user. Any (valid) user has easy access to their session id: it's either in the URL or in a cookie value. If the only way to exploit this is to have foreknowledge of a session id, isn't the security question moot? The session id must have been leaked previously, right? Maybe I'm seriously missing the point. :( |> 3.) Could this affect authenticated sessions over HTTPS? | | Yes, depending on the authentication used. Eg, if you use FORM the | session is vulnerable, if you use CLIENT-CERT it isn't. Why is the session protected if CLIENT-CERT is being used? Because the attacker presumably does not have the correct client cert? If that's the case, how was the attack carried out in the first place? |> 5.) Is there anything we can do to limit the scope of this bug with |> config settings alone? Binding the session to the IP address that it |> was first initialized with, for instance. | | That should mitigate the issue. Be aware that some ISPs play games with | IP addresses that mean a user's IP address might not be constant between | requests. Note that securityfilter will soon have a filter that performs this exact function. We're currently testing it ourselves before it even goes into CVS. I'd be happy to share the code with anyone who wants it. |> 7.) If this is as big of a deal as it looks like, why is there no more |> information available / more questions being posted / the world seems |> shockingly quiet about this. | | I think your worst case assumption re Q2 has lead to an over estimate of | the impact of this. | It is made worse when an app allows user provided data to find its way | unfiltered into cookie content - this shouldn't happen and where it does | should be easy to fix. Any client can send a bogus cookie, though, right? On the other hand, what good is sabotaging your own request...? Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhO2WAACgkQ9CaO5/Lv0PCArgCguHpT41UILNrttSGhthO9CRZZ fIIAn2euPBcBye/f0psXR0xzaY8r9r1y =kuUr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
