ASP anti request forgery, why wouldn't the hacker do a get first?

Question

I've been implementing ASP ARF tokens in my MVC3 web application and read into the workings of the CSRF exploit and how ARF tokens defend against it. Now I was wondering if 'hackers' couldn't bypass the ARF check by using an extra step. The normal CSRF scenario is like:

1. Create a site (we call it HackerSite) that posts to the target website BankingSite
2. Use social engineering (or XSS in ads etc.) so that a user will visit site HackerSite
3. A script on HackerSite will post to the BankingSite using the users cookies/credentials thus posting under his/her name

Because of our ARF token, the BankingSite knows to ignore the POST coming from site HackerSite. Because it's missing the right AFR token. Could anyone tell me why the hacker couldn't just get the token by doing a GET request first on the BankingSite? Like this:

1. Create a site (we call it HackerSite) that posts to the target website BankingSite
2. Use social engineering (or XSS in ads etc.) so that a user will visit site HackerSite
3. A script on HackerSite will do a GET request and grabs the ARF token from the HTML in the response, this request will also set the ARF token in the user's cookie
4. A second script on HackerSite will post to the BankingSite using the grabbed ARF token + the users cookies/credentials thus posting under his/her name

Does anyone know what I'm missing here, and how ARF is secured against such an attack?

Answer 1

Attacker doesn't know cookies of victim. Token generating based on it. If your site has another XSS's holes, this method can't help from CSRF vulnerability.

If you send AJAX referer header would be HackerSite, not BankSite. So you haven't access to closed part of site (can't access to CSRF Token). It's Http-Only so you can't just take it by javascript. Your plan will fail on part when you want to send get request to victim site.