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

[Matt Fisher]

Has anyone had the chance to test this on two different browsers ? 

I.e. I'm doing my bank work on my first instance of IE, I open another
IE to surf.  

> -----Original Message-----
> From: Sverre H. Huseby [mailto:shh at thathost.com] 
> Sent: Wednesday, May 04, 2005 2:46 PM
> To: Jeremiah Grossman
> Cc: websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] On Session Riding, Client-side 
> Trojans and Cross-site Request Forgeries
> 
> [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/
> 
> 

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