[WEB SECURITY] On Session Riding, Client-side Trojans and Cross-site Request Forgeries

[Jeremiah Grossman]

This is a perfect example, worthy of being used verbatim in a future 
release of the threat classification. :)

Clearly the issue you've described is a valid attack and presents a 
real risk exploitable on most any website. Depending on a persons 
understanding of XSS, it may or may not fall into that particular 
class. It could also be argued that some amount of Insufficient 
Authorization and social engineering is required for success in 
exploitation. As we all know, the exact definition of XSS has never 
been clear or widely agreed upon in the industry. The details have 
always been cloudy. This is the one of the main reasons the Threat 
Classification project was born. In order to further define the attack 
classes and widely agree upon they're scope and meaning.  I think your 
example shows a deficiency in the current model that needs to be 
addressed (I've place this thread in the TODO notes for the next TC 
release initiative). I'd personally be hard pressed to confidently 
define the example using any number of classes.

Moving onto possible solutions for your example.  I think a ticketing 
system (among others) could be made to work quite nicely, then 
something strange occurred to me. Couldn't Referer header checking be 
used to defeat this attack as well? I find it hard even to suggest, 
since Referer's are something not to trust on the client. But, if we 
look at the specifics of your example, I do not think an attacker would 
be able to manipulate the Referer header after the user click submit on 
badguy.org. This seems like a very easy and *gulp* reliable security 
measure. Or amy I just missing something simple here?

Last, having JavaScript automatically posting a form normally creates 
an alert of some kind (Browser/configuration dependent). However, I'm 
inclined to believe the user will click OK anyway. So a bank.com 
solution must be enabled.


On Wednesday, May 4, 2005, at 11:46  AM, Sverre H. Huseby wrote:

> [Sverre H. Huseby]
>
> |   It works on servers which are not vulnerable to HTML Injection, so
> |   it's not XSS in the traditional meaning of the word.  In fact,
> |   scripting need not even be involved.
>
> [Jeremiah Grossman]
>
> |   So I'm clear, can you give describe an example of this?
>
> Certainly.  You can be the attacker, and I'll play the victim.  You
> happen to know that I'm working with finances for a large corporation.
> One of my jobs is to pay all the company bills, a task I perform using
> a special enterprise web application at a bank (the kind of bank web
> application I have in mind does exist).  You also know that I pay so
> many bills that I'm logged into the bank application almost
> continously throughout the day.
>
> For some reason you are familiar with the payment form the bank
> presents me with when I make payments.  A simplified version of it may
> look like this:
>
>   <form action="/enterprise/pay.do" method="post">
>     From account:
>     <select name="fromaccount">
>       <option value="1">1234.56.78901</option>
>       <option value="2">2345.67.89012</option>
>          :
>     </select>
>     To account:
>     <input type="text" name="toaccount"/>
>     Amount:
>     <input type="text" name="amount"/>
>   </form>
>
> The bank server runs at bank.com.  And you control the domain
> badguy.org.  For some reason you also know, or guess, that I have this
> bad habit of surfing for beautiful women while at work.  You prepare a
> very tempting web page for me at badguy.org, and inside that web page
> you embed the following form:
>
>   <form action="https://bank.com/enterprise/pay.do" method="post">
>     <input type="hidden" name="fromaccount" value="1"/>
>     <input type="hidden" name="toaccount" value="3456.78.90123"/>
>     <input type="hidden" name="amount" value="1000"/>
>     <input type="submit" value="Click for free porn"/>
>   </form>
>
> This form, on _your_ web server, now contains a lot of tiny, tempting
> pictures, and a button telling me to "Click for free porn" (OK, Kevin
> Mitnick would probably come up with a much more plausible SE attack.).
> Note how the form also contains prefilled stuff that matches the
> expectations of the bank I use, and that the action attribute points
> to the payment handler at the bank web server.
>
> Somehow you trick me into visiting your web site while I'm at work.
> And since I'm such a miserable person, I click on the button on _your_
> site, hoping to find those babes (trojan).  What happens?  _My_ web
> browser, which is already authenticated over at bank.com, follows the
> instructions from your form, and thus visits that bank (cross-site
> requests) with the values you have dictated, along with the session
> cookie that proves that I'm in fact me (session riding).  Result?  The
> bank accepts my request to transfer 1000 money to some account,
> probably belonging to you or to someone you do not like.
>
> There's no scripting involved.  Just the posting of a form given on
> one web site to another web site.  The bank need not be open to any
> HTML Injection/Cross-site Scripting attacks.
>
> You _could_ add a script to _your_ web page to automatically post the
> form with no need for me to push that button, but that would still not
> be XSS, since the script is on _your_ page, and running in the context
> of my browser's request to your web server.  The bank would not be
> involved in the scripting in that case, and it would work even if the
> bank application was immune to HTML Injection.








---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/