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

Sverre H. Huseby shh at thathost.com
Wed May 4 14:46:28 EDT 2005


[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.


Sverre.

-- 
shh at thathost.com               My web security book: Innocent Code
http://shh.thathost.com/       http://innocentcode.thathost.com/

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



More information about the websecurity mailing list