[WEB SECURITY] On Session Riding, Client-side Trojans and Cross-site Request Forgeries
bill at whitehatsec.com
Wed May 4 16:26:00 EDT 2005
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
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>
> 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
Bill Pennington, CISSP, CCNA
WhiteHat Security Inc.
The Web Security Mailing List
More information about the websecurity