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
Funny that to get this comment box to appear I had to allow requests from this site in the "Request Policy" Firefox extension :)
ReplyDeleteI'd be interested in how such CSRF attacks would be mitigated by the Content Security Policy that is being implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=493857 if you've not already covered this that is.
@Michael: you are not missing anything, forging headers in a CSRF attack is fairly difficult (impossible?) now in the very latest browsers -- but I haven't fully investigated HTML5. WebSockets looks interesting. But as you know, this must assume that your victim isn't using a dated browser, which often not the case.
ReplyDeleteThis was proposed for Account Manager:
ReplyDeletehttps://groups.google.com/group/mozilla-labs-online-identity/browse_thread/thread/1c02d1bbfbfaafc
And I just learned today of a more established effort to do just that:
https://wiki.mozilla.org/Security/Origin
You can set headers on WebClient and WebRequest in Silverlight. I'm not sure if there are whitelists/blacklists applied by the framework though.
ReplyDeleteMaybe something to investigate?
Btw: Silverlight is limited by the clientaccesspolicy.xml just like flash/flex is limited by the crossdomain.xml, so this attack would only work on sites with open policies.
ReplyDelete@jeremiah - Good point on the web sockets. I'll start looking more into that realm. Also glad to get confirmation on the impossibility/difficulty of constructing such an attack.
ReplyDelete@dan - yes, I've seen that. That post was part of my motivation to investigate this issue more. Aside from whether or not its good for account manager, perhaps it can be used as a lightweight CSRF protection for many sites. We'll see as this conversation continues.
@erlend - Thanks for the Silverlight mention. I forget about that one sometimes :) As you pointed out in your second post the controls are governed by the clientaccesspolicy.xml just like flash's crossdomain.xml. So, I'm ok with that configuration since the control is given to the server via that config xml.
Let's keep this discussion going.
One vector to introduce a new header is HTTP request smuggling or splitting -- if you can fool a forward proxy into treating some part of a request's body as a new request, you can introduce arbitrary data.
ReplyDeletehttp://projects.webappsec.org/HTTP-Request-Smuggling
http://projects.webappsec.org/HTTP-Request-Splitting
These are a pain because the exploit isn't in the user-agent but in a badly implemented forward proxy somewhere between the victim and the target.
If you're planning on using this as a CSRF defense, how are you planning on forcing the browser to send you this header under normal (non-attack) circumstances?
ReplyDelete@tom - There are a couple ways that would work. This could be used for legitimate XHR request that are already built into the page (e.g. in compliance with SOP). Alternatively this approach could be used by browser enhancements such as the account manager idea mentioned by dan. With browser enhancements the key would be to ensure that the enhancement itself can not be instructed by a third party to initiate the action since this would just be shifting the CSRF attack out by one step.
ReplyDeleteMichael, I know that a bunch of pretty high profile websites is relying on the fact that only first-party webpages can send off requests with custom HTTP headers. These websites use XMLHttpRequest to communicate with the backend, only requests with an X-Foo-Bar header are accepted - that's how their CSRF protection works. And so far it seems that nobody found a way around this protection.
ReplyDeleteFact is, an important design criterion for new web browser features is that they shouldn't create holes in the same-origin policy. So with the old features (meaning Flash and XMLHttpRequest) all being secured long ago, the new ones shouldn't be a problem. For example, Cross Site XMLHttpRequest will only send a request with custom headers if the target website explicitly allows such requests. Web Sockets are restricted by same-origin policy. And I would be very surprised if Silverlight were to allow unrestricted requests (Microsoft has quite thorough security reviews).
wladimir, Thanks for the info. That's what this discussion was primarily focused on - would it be secure to use a header as CSRF protection when performing XHR requests. Based on all of the comments it seems like there are not any known weaknesses in this approach and, as you mentioned, some sites are actively using this approach already.
ReplyDelete