Yvan G.J. Boily wrote:
This name for the issue is misleading; this is a state management
issue combined with a session management issue.
Although there is an attempt to separate this type of an attack,
it is still a session hijacking attack
I actually like Thomas' name for this and I think we should stick with it to
distinguish it from session hijacking. The two issues are very similar and
might even be used together but I would differentiate the two as follows:
Session hijacking is when an attacker gains access to the target's session
(usually via a cookie or some other token) and therefore controls the target's
session from his own browser. With this type of attack the attacker has full
interactive control of the session and can do things such as take measures to
keep the session alive.
Session riding is a form of a luring attack that specifically takes advantage
of a session kept open on the target. It would likely require some action on
the user's end or exploiting a browser vulnerability to initiate the attack. As
Thomas points out, session riding is the user taking the action so therefore
repudiation is difficult.
Noah Gray wrote:
1) Most sites use some form of Session Expiration. The whole of this paper
assumes the when the user is attacked, they are still logged in, and have a
valid session cookie intact. In reality, this attack is only useful while a
user is logged in, and shortly thereafter. Which, while being very plausible
in intranet application, is unlikely in internet applications, except in
focused attacks.
This might not always be true. An attack might involve some kind of session
fixation and/or session keep-alive technique that keeps the session alive in
definitely. You need to be sure to implement techniques such as absolute
session expiration (regardless of idle time) and expiring sessions after a
specified number of uses.
In the paper, Thomas recommends several countermeasures but I wanted to comment
on those. The idea of attaching a secret token to every link does raise the bar
on this attack, but it does not completely compensate for poor session
management and will not stop all forms of this attack. For example, suppose
that the attack occurs on a web-based mail account where the attacker sends a
link in the e-mail body or perhaps even in the subject or some other e-mail
header. The application will attach the secret session token to those links as
well and therefore still make an attack p ossible.
Others have suggested a unique secret that changes with every browser action.
This might work in cases where you can control continuity, but it doesn't work
when the user takes multiple simultaneous paths through a web site by opening
up multiple browser windows. A unique ID would work, however, in conjunction
with a confirmation page. Although the paper states that confirmation pages are
not effective, when combined with a unique ID for that one action they can be
effective. Of course, this will still not completely eliminate the problem.
The problem is that like many application threats we currently have no single
solution to completely stop this type of attack. And unless users suddenly get
much smarter and hackers get much dumber, the potential for this attack will
always be there. However, the paper does mention that certain countermeasures
will raise the bar and that's the key here. While no single solution will stop
this type of attack, we can raise the bar enough to make it difficult for any
one attack to succeed. In effect, we add so many conditions that mitigate the
attack that it might require unusual circumstances for an attack to actually
succeed. This is an area that obviously needs more research and more discussion.
Mark Burnett
-----------------------------------
Are Your Web Applications Really Secure?
Read Hacking the Code: ASP.NET Web Application Security
http://www.hackingthecode.com
