RE: Whitepaper "SESSION RIDING - A Widespread Vulnerability in Today's Web Applications"

[Mark Burnett <mb () xato net>]

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