Thursday, May 13, 2010

CSRF Attacks and Forged Headers

I'd like to start a discussion on current attacks using CSRF to forge HTTP headers.  The attack would go something like this:

1. Victim visits attacker's site with CSRF attack in page
2. CSRF attack fires causing victim to initiate a HTTP request to targetsite.com
3. Victim's browser sends off a request to targetsite.com and browser happily includes the session ID
4. Bad action occurs as designed by CSRF

The above is the classic CSRF flow. I'm curious about modern day attacks that would be placed in step #2 to allow the attacker to forge arbitrary headers that would be sent by the victim's browser (e.g in step 3).  For example, perhaps the attacker wanted the x-forwarded-for header to be added in the victim's HTTP request (step 3) and set to 127.0.0.1 (not sure why, just an example). Could he craft a CSRF to accomplish this?

In the past there were two ways to launch such an attack:
1. setHeader in Flash action script
2. XHR requests

However, each of these items have been locked down by the following:
1. setHeader in Flash action script --> crossdomain.xml policy
2. XHR requests --> Same Origin Policy restrictions

So, here is the challenge, what methods are currently available to launch such an attack?  Am I just missing something obvious or is this attack not well publicized.  If there isn't such an attack available, should we start relying upon custom headers to prevent CSRF attacks (my gut says no, but let's make a case against it).

Looking for feedback here and clever attacks.

*****
Edit: 5/27/2010
As you'll see from the comments, the same origin policy does hold up here and this attack is not possible. Headers can be relied upon to be free from tampering unless of course the primary site is compromised via some other method and used to inject the malicious XHR.

-Michael Coates