[WEB SECURITY] On Session Riding, Client-side Trojans and Cross-site Request Forgeries
mfisher at spidynamics.com
Wed May 4 15:12:32 EDT 2005
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>
> To account:
> <input type="text" name="toaccount"/>
> <input type="text" name="amount"/>
> 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"/>
> 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.
> shh at thathost.com My web security book: Innocent Code
> http://shh.thathost.com/ http://innocentcode.thathost.com/
> The Web Security Mailing List
The Web Security Mailing List
More information about the websecurity