Thomas,

Thanks for a nice writeup of this issue. I do think this is worth including
in the OWASP top ten. I'd appreciate people's thoughts on whether this fits
into the "Broken Authentication and Session Management" category
(http://www.owasp.org/documentation/topten/a3.html) or if this should be
separate somehow.

As Mark noted, there are several imperfect approaches proposed for dealing
with this on the server-side. In particular, I think URL rewriting
introduces more problems than it solves here. I would like to see more
discussion of the approaches to this problem.

Would it be reasonable for browsers not to send cookies with requests
generated from HTML that came from another domain? That would prevent
session riding attacks entirely, as all the cross-domain requests generated
by the attacker's HTML would not contain cookies. I can't think offhand of
why an image request to somebody else's site should require a cookie, but
it's possible this would break some apps.

--Jeff

Jeff Williams
Aspect Security, Inc.
http://www.aspectsecurity.com

----- Original Message -----
From: "Mark Burnett" <mb (at) xato (dot) net [email concealed]>
To: <webappsec (at) securityfocus (dot) com [email concealed]>
Cc: "'Thomas Schreiber'" <ts (at) securenet (dot) de [email concealed]>
Sent: Monday, December 20, 2004 12:56 PM
Subject: RE: Whitepaper "SESSION RIDING - A Widespread Vulnerability in
Today's Web Applications"

> 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
>
>
>
>
>
>

[ reply ]

Thomas,<br/>
<br/>
Thanks for a nice writeup of this issue. I do think this is worth including <br/>
in the OWASP top ten. I'd appreciate people's thoughts on whether this fits <br/>
into the "Broken Authentication and Session Management" category <br/>
(http://www.owasp.org/documentation/topten/a3.html) or if this should be <br/>
separate somehow.<br/>
<br/>
As Mark noted, there are several imperfect approaches proposed for dealing <br/>
with this on the server-side. In particular, I think URL rewriting <br/>
introduces more problems than it solves here. I would like to see more <br/>
discussion of the approaches to this problem.<br/>
<br/>
Would it be reasonable for browsers not to send cookies with requests <br/>
generated from HTML that came from another domain? That would prevent <br/>
session riding attacks entirely, as all the cross-domain requests generated <br/>
by the attacker's HTML would not contain cookies. I can't think offhand of <br/>
why an image request to somebody else's site should require a cookie, but <br/>
it's possible this would break some apps.<br/>
<br/>
--Jeff<br/>
<br/>
Jeff Williams<br/>
Aspect Security, Inc.<br/>
http://www.aspectsecurity.com<br/>
<br/>
----- Original Message ----- <br/>
From: "Mark Burnett" <mb (at) xato (dot) net [email concealed]><br/>
To: <webappsec (at) securityfocus (dot) com [email concealed]><br/>
Cc: "'Thomas Schreiber'" <ts (at) securenet (dot) de [email concealed]><br/>
Sent: Monday, December 20, 2004 12:56 PM<br/>
Subject: RE: Whitepaper "SESSION RIDING - A Widespread Vulnerability in <br/>
Today's Web Applications"<br/>
<br/>
> Yvan G.J. Boily wrote:<br/>
>> This name for the issue is misleading; this is a state management<br/>
>> issue combined with a session management issue.<br/>
>><br/>
>> Although there is an attempt to separate this type of an attack,<br/>
>> it is still a session hijacking attack<br/>
><br/>
> I actually like Thomas' name for this and I think we should stick with it <br/>
> to distinguish it from session hijacking. The two issues are very similar <br/>
> and might even be used together but I would differentiate the two as <br/>
> follows:<br/>
><br/>
> Session hijacking is when an attacker gains access to the target's session <br/>
> (usually via a cookie or some other token) and therefore controls the <br/>
> target's session from his own browser. With this type of attack the <br/>
> attacker has full interactive control of the session and can do things <br/>
> such as take measures to keep the session alive.<br/>
><br/>
> Session riding is a form of a luring attack that specifically takes <br/>
> advantage of a session kept open on the target. It would likely require <br/>
> some action on the user's end or exploiting a browser vulnerability to <br/>
> initiate the attack. As Thomas points out, session riding is the user <br/>
> taking the action so therefore repudiation is difficult.<br/>
><br/>
><br/>
> Noah Gray wrote:<br/>
>> 1) Most sites use some form of Session Expiration. The whole of this <br/>
>> paper<br/>
>> assumes the when the user is attacked, they are still logged in, and have <br/>
>> a<br/>
>> valid session cookie intact. In reality, this attack is only useful while <br/>
>> a<br/>
>> user is logged in, and shortly thereafter. Which, while being very <br/>
>> plausible<br/>
>> in intranet application, is unlikely in internet applications, except in<br/>
>> focused attacks.<br/>
><br/>
> This might not always be true. An attack might involve some kind of <br/>
> session fixation and/or session keep-alive technique that keeps the <br/>
> session alive in definitely. You need to be sure to implement techniques <br/>
> such as absolute session expiration (regardless of idle time) and expiring <br/>
> sessions after a specified number of uses.<br/>
><br/>
> In the paper, Thomas recommends several countermeasures but I wanted to <br/>
> comment on those. The idea of attaching a secret token to every link does <br/>
> raise the bar on this attack, but it does not completely compensate for <br/>
> poor session management and will not stop all forms of this attack. For <br/>
> example, suppose that the attack occurs on a web-based mail account where <br/>
> the attacker sends a link in the e-mail body or perhaps even in the <br/>
> subject or some other e-mail header. The application will attach the <br/>
> secret session token to those links as well and therefore still make an <br/>
> attack p ossible.<br/>
><br/>
> Others have suggested a unique secret that changes with every browser <br/>
> action. This might work in cases where you can control continuity, but it <br/>
> doesn't work when the user takes multiple simultaneous paths through a web <br/>
> site by opening up multiple browser windows. A unique ID would work, <br/>
> however, in conjunction with a confirmation page. Although the paper <br/>
> states that confirmation pages are not effective, when combined with a <br/>
> unique ID for that one action they can be effective. Of course, this will <br/>
> still not completely eliminate the problem.<br/>
><br/>
> The problem is that like many application threats we currently have no <br/>
> single solution to completely stop this type of attack. And unless users <br/>
> suddenly get much smarter and hackers get much dumber, the potential for <br/>
> this attack will always be there. However, the paper does mention that <br/>
> certain countermeasures will raise the bar and that's the key here. While <br/>
> no single solution will stop this type of attack, we can raise the bar <br/>
> enough to make it difficult for any one attack to succeed. In effect, we <br/>
> add so many conditions that mitigate the attack that it might require <br/>
> unusual circumstances for an attack to actually succeed. This is an area <br/>
> that obviously needs more research and more discussion.<br/>
><br/>
><br/>
> Mark Burnett<br/>
><br/>
><br/>
><br/>
><br/>
><br/>
><br/>
> -----------------------------------<br/>
> Are Your Web Applications Really Secure?<br/>
> Read Hacking the Code: ASP.NET Web Application Security<br/>
> http://www.hackingthecode.com<br/>
><br/>
><br/>
><br/>
><br/>
><br/>
>

[ reply ]