Christopher Schultz wrote:
Mark Thomas wrote:
| 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.
This attack requires luring a user who is already logged in to a webapp running on a vulnerable Tomcat server to a malicious site. With a suitably crafted URL, the attacker is able to steal the authentication cookie for the user who was lured to the malicious site. It is the user that is lured who is the 'current user'.

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. :(
See above.

|> 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?
Yes.

If that's the
case, how was the attack carried out in the first place?
Again, see above.

|> 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...?
They can but that is harder (but not impossible) for an attacker to trick a client into doing that. When a request parameter is used in/as the cookie value the attack is a lot easier.

Mark


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to