[WEB SECURITY] On Session Riding, Client-side Trojans and Cross-site Request Forgeries
jeremiah at whitehatsec.com
Wed May 4 17:12:02 EDT 2005
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?
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>
> 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.
The Web Security Mailing List
More information about the websecurity