> This name for the issue is misleading; this is a state management
> issue combined with a session management issue.
I don't quite agree. Some developers use stateless authentication
methods specifically to avoid the pitfalls of improper session
management (and session token theft due to cross-site scripting
vulnerabilities).
I don't think the vulnerability has much to do with state or session
management. What we really need is a form of remote attestation,
namely that the user has actually triggered the action the browser
claims he has. In this particular case, it turns out that you can
provide part of this attestation by carrying additional state
information through the client, but this is more or less an accident,
and not really inherent to the underlying problem. (The general
attestation problem is much harder to solve, of course.)
If we look at the problem from a different angle, it's a leak between
different trust domains (for example, from an Internet site to an
intranet application). Disabling cross-site requests in the client
would stop it. Actually, doing this is extremely desirable from a
security point of view, but is impossible because too many deployed
applications rely on this client feature.
Those of us who run different browser instances for internal and
external content, on different hosts (sometimes called a "graphical
firewall"), have at least some protection from these issues because
the different trust domains are separated to some extent.
> The "Session Riding" vulnerability is not just an issue of immature
> web technology; it will affect any stateless protocol which does
> not have a strong method of enforcing state compliance.
On the other hand, this lack of state compliance is a feature which
users expect. They want to use the Back button in their browsers.
They want to bookmark pages deep within the application. Some users
even want to script requests to the applications.
* Yvan G. J. Boily:<br/>
<br/>
> This name for the issue is misleading; this is a state management <br/>
> issue combined with a session management issue.<br/>
<br/>
I don't quite agree. Some developers use stateless authentication<br/>
methods specifically to avoid the pitfalls of improper session<br/>
management (and session token theft due to cross-site scripting<br/>
vulnerabilities).<br/>
<br/>
I don't think the vulnerability has much to do with state or session<br/>
management. What we really need is a form of remote attestation,<br/>
namely that the user has actually triggered the action the browser<br/>
claims he has. In this particular case, it turns out that you can<br/>
provide part of this attestation by carrying additional state<br/>
information through the client, but this is more or less an accident,<br/>
and not really inherent to the underlying problem. (The general<br/>
attestation problem is much harder to solve, of course.)<br/>
<br/>
If we look at the problem from a different angle, it's a leak between<br/>
different trust domains (for example, from an Internet site to an<br/>
intranet application). Disabling cross-site requests in the client<br/>
would stop it. Actually, doing this is extremely desirable from a<br/>
security point of view, but is impossible because too many deployed<br/>
applications rely on this client feature.<br/>
<br/>
Those of us who run different browser instances for internal and<br/>
external content, on different hosts (sometimes called a "graphical<br/>
firewall"), have at least some protection from these issues because<br/>
the different trust domains are separated to some extent.<br/>
<br/>
> The "Session Riding" vulnerability is not just an issue of immature<br/>
> web technology; it will affect any stateless protocol which does <br/>
> not have a strong method of enforcing state compliance.<br/>
<br/>
On the other hand, this lack of state compliance is a feature which<br/>
users expect. They want to use the Back button in their browsers.<br/>
They want to bookmark pages deep within the application. Some users<br/>
even want to script requests to the applications.<br/>
<br/>
We need to support such features.
> This name for the issue is misleading; this is a state management
> issue combined with a session management issue.
I don't quite agree. Some developers use stateless authentication
methods specifically to avoid the pitfalls of improper session
management (and session token theft due to cross-site scripting
vulnerabilities).
I don't think the vulnerability has much to do with state or session
management. What we really need is a form of remote attestation,
namely that the user has actually triggered the action the browser
claims he has. In this particular case, it turns out that you can
provide part of this attestation by carrying additional state
information through the client, but this is more or less an accident,
and not really inherent to the underlying problem. (The general
attestation problem is much harder to solve, of course.)
If we look at the problem from a different angle, it's a leak between
different trust domains (for example, from an Internet site to an
intranet application). Disabling cross-site requests in the client
would stop it. Actually, doing this is extremely desirable from a
security point of view, but is impossible because too many deployed
applications rely on this client feature.
Those of us who run different browser instances for internal and
external content, on different hosts (sometimes called a "graphical
firewall"), have at least some protection from these issues because
the different trust domains are separated to some extent.
> The "Session Riding" vulnerability is not just an issue of immature
> web technology; it will affect any stateless protocol which does
> not have a strong method of enforcing state compliance.
On the other hand, this lack of state compliance is a feature which
users expect. They want to use the Back button in their browsers.
They want to bookmark pages deep within the application. Some users
even want to script requests to the applications.
We need to support such features.
[ reply ]