I believe that one of the conditions that need to exist to enable this
kind of attack is being overlooked. The paper says that the user has
to be logged on the application. Of course that this is possible and
even plausible in lots of situations, but let's remember that it
creates a time window for the attack (session timeout) and that the
users shall logoff from the application (when it offers the
possibility for user).

Perhaps the applications that are more likely to be exploited are
those that the user stays logged in and that periodically refreshes
theirselves, like webmails. I don't see them as a huge threat for
systems like Internet Bankings, for example.

Regards,

Augusto.

On Tue, 21 Dec 2004 11:31:57 -0500, Jeff Williams
<jeff.williams (at) aspectsecurity (dot) com [email concealed]> wrote:
> 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
> >
> >
> >
> >
> >
> >
>
>

--
Augusto Paes de Barros, CISSP
http://www.paesdebarros.com.br

[ reply ]

I believe that one of the conditions that need to exist to enable this<br/>
kind of attack is being overlooked. The paper says that the user has<br/>
to be logged on the application. Of course that this is possible and<br/>
even plausible in lots of situations, but let's remember that it<br/>
creates a time window for the attack (session timeout) and that the<br/>
users shall logoff from the application (when it offers the<br/>
possibility for user).<br/>
<br/>
Perhaps the applications that are more likely to be exploited are<br/>
those that the user stays logged in and that periodically refreshes<br/>
theirselves, like webmails. I don't see them as a huge threat for<br/>
systems like Internet Bankings, for example.<br/>
<br/>
Regards,<br/>
<br/>
Augusto.<br/>
<br/>
On Tue, 21 Dec 2004 11:31:57 -0500, Jeff Williams<br/>
<jeff.williams (at) aspectsecurity (dot) com [email concealed]> wrote:<br/>
> 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/>
> ><br/>
> <br/>
><br/>
<br/>
-- <br/>
Augusto Paes de Barros, CISSP<br/>
http://www.paesdebarros.com.br

[ reply ]

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

[ reply ]

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

[ reply ]