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

[Bill Pennington]

Ok this is a better example than your voting one ;-)

This is why I hate the english language, there are not a lot of good 
words to describe this. I still think it is cross site scripting used 
to attack an insufficiently protected application, now that is a nasty 
bit of english... Just because the code is on my site does not mean 
that XSS is not occurring, it is just a different vector. If we step 
back and allow for XSS to include "Request" and not just scripting (aka 
javascript) then I still think it fits into the existing classification 
system. I do believe that there is a lot more work that could be done 
to tighten up the classification system and perhaps finding ways to 
explain and classify these types of situations would be a good start.

On 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.
>
>
> 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/
>
>

---
Bill Pennington, CISSP, CCNA
VP Services
WhiteHat Security Inc.
http://www.whitehatsec.com


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