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

["Thomas Schreiber" <ts () securenet de>]

Noah,

  > -----Original Message-----
  > From: Noah Gray [mailto:NGray () worldrelief net]
  > Sent: Thursday, December 16, 2004 6:49 PM
  > To: 'Thomas Schreiber '; 'webappsec () securityfocus com '
  > Subject: RE: Whitepaper "SESSION RIDING - A Widespread Vulnerability in
  > Today's Web Applications"
  > 
  > 
  > While agreeing with much of the paper, I feel that there are 
  > two mitigating
  > factors not stronly enough reinforced:
  > 
  > 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.

You are right that a valid session must still be there which is mentioned in the paper as well. Typically session 
lifetimes are around 1/2 to 2 hours in internet applications. In other environments it's much more, sometimes never 
ending.

But to my opinion short session lifetime is only a very weak mitigating factor. Just one example to illustrate this: An 
attacker might put hundreds of 'effective links' to hundreds of web applications into one malicious web page or email 
and send it out to many users. There is a certain chance that he catches a lot of them with an appropriate session 
still open.

Web Application Security to me is a concern of the server side, not at first place of the client side. A provider 
should be interested in not allowing such kind of vandalism. 

  > 
  > 2) Less secure sites often allow for persistent cookie 'auto-login'
  > features. These sites are particularly vulnerable to this 
  > attack. However,
  > many of these still redirect the user through the login page, 
  > then redirect
  > to a 'start' page, rather than the requested page. This 
  > effectively strips
  > malicious commands. Further, in the case of eBay, which is not 
  > so clearly
  > named in the paper, that DO have an auto-login feature (My eBay), still
  > require entering a password to bid.

In the case where the session has expired it is as you describe. But asking for a password each time a sensitive 
command is executed is generally not a practicable solution against session riding (nevertheless, Amazon is a good 
counter example where it works well to ask for the password before each order). Additionally, asking the user too often 
for his password is bad practice on the semantic layer of Web Application Security: You condition your users to accept 
this and make them more susceptible to phishing attacks.

  > Other than that, this is very plausible attack that I would agree hasn't
  > received enough attention. I would also add that in the case of 
  > the img tag
  > in the email, an iframe could also be used, similar to recent 
  > viruses. It
  > needn't even be visible.

iframes and frames are not allowed in the default configuration of eg. outlook and thunderbird any more. But, yes, 
inside the browser this is a trigger as well as are Stylesheets (link-Tag) and others.

Thomas

  > 
  > Regards, 
  > 
  > Noah Gray
  > 
  > -----Original Message-----
  > From: Thomas Schreiber
  > To: webappsec () securityfocus com
  > Sent: 12/15/04 8:13 PM
  > 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 () securenet de