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, even though the attacker
is taking a different approach; the attacker still manages to
acquire the ability to execute a request using the original users.

The core of this type of a vulnerability is a lack of state
management; the token mechanism that you refer to on page
14 is a common state management technique.

The application should emit a unique (i.e. random) token for
each request in combination with the session identifier. If
the succeeding request does not have the same token, then the
application should take the appropriate action. This is a
crucial step in state management, as it becomes possible to
enforce state transitions using this method.

The issue is a serious one; I have seen this many times during
code reviews and application pen-tests. The important concern
here is educating web developers so that they understand that
even in a "stateless" protocol, maintaining an application state
in a secure fashion is crucial. Any type of exploit that takes
advantage of this type of issue can be corrected by implementing
a state management mechanism (typically these are more robust
than a page token system), and then ensuring that confirmation
is crucial, verified (i.e. CAPTCHA) process.

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. It is
certainly the case that this can be addressed by implementing this
type of functionality at the framework/api level with a development
platform, however there are a number of technical issues associated
with the technology.

The paper is a good introduction to the issue, but perhaps the title
is misleading as to the nature of the issue.

> -----Original Message-----
> From: Thomas Schreiber [mailto:ts (at) securenet (dot) de [email concealed]]
> Sent: Wednesday, December 15, 2004 7:14 PM
> To: webappsec (at) securityfocus (dot) com [email concealed]
> Subject: Whitepaper "SESSION RIDING - A Widespread
> Vulnerability in Today's Web Applications"
>
> Hello,
>
> I would like to point you to a whitepaper just released:
>
> SESSION RIDING - A Widespread Vulnerability in Today's Web
> Applications
> http://www.securenet.de/papers/Session_Riding.pdf
>
> ----------
> Abstract:
>
> In this paper we describe an issue that was raised in 2001
> under the name of Cross-Site Request Forgeries (CSRF). It
> seems, though, that it has been neglected by the community,
> as it is not part of recent Web Application Security
> discussions, nor is it mentioned in OWASP's Top Ten or the
> like. After having frequently observed this vulnerability in
> our Web Application Security assessments of custom Web
> applications, we started to examine various public Web
> applications and other browser-based applications:
>
> - popular (commercial) Web sites
> - popular browser-based console applications such as
> administration tools for databases, servers, etc.
> - browser-based administration clients of hardware devices
> - webmail sites and open source and commercial webmail solutions
>
> We have found out that this vulnerability is present in many
> of those sites, services and products, some of which perform
> sensitive tasks. Actually, the list of affected companies
> contains well-known big players. Our analysis has led us to
> the conclusion that this vulnerability is the most widespread
> one in today's Web applications right after Cross-Site
> Scripting (XSS). Even worse, in some scenarios it has to be
> considered much more dangerous than XSS.
>
> We feel that a concise description of this issue is
> necessary, along with a description of scenarios that
> highlight the danger to all browser-based applications that
> do not provide appropriate countermeasures, be it Intranet,
> Internet or console applications. In this paper, we explain
> this vulnerability in depth, show that it may be used
> unnoticed by the victim, describe potential threats, and
> finally give hints on how to make Web applications safe from
> such attacks.
>
> We prefer to call this issue Session Riding which more
> figuratively illustrates what is going on.
> ----------
>
> Feedback is very welcome - especially regarding our
> rating/experience as one of the most widespread
> vulnerabilities today.
>
> Thomas Schreiber
> ____________________________________________________________
> SecureNet GmbH - http://www.securenet.de
> +49 89/32133-610
> mailto:ts (at) securenet (dot) de [email concealed]
>
>

[ reply ]