Preventing CSRF exploits

sneakyimp

I'm trying to understand how CSRF works and how to prevent it. I hope you guys might correct any mistakes. Maybe this will be useful for 'collected solutions' thread?

A Cross-Site Request Forgery (CSRF or XSRF) is a type of exploit where some user, VictimUser in the examples that follow, is tricked into making a forged request to a website that trusts that user. By 'trusts the user,' we mean that the user is considered to be authenticated by the site, usually by cookie or some other session technique. The exploit is possible because the request comes from VictimUser's browser and therefore contains session cookies or other authentication credentials.

Let's say VictimUser has logged into some site that lets them send money to another user -- let's call it SendMoney.example.com. VictimUser logs in -- they enter their username and password and the site authenticates these and stores a session cookie on VictimUser's machine. All subsequent requests from VictimUser use that cookie to locate his/her authenticated session. As long as the session cookie corresponds to a valid session, any request from VictimUser is considered authenticated by SendMoney.example.com.

EXPLOIT EXAMPLE 1
Now let's say some AttackerUser wants to exploit the situation to get money from VictimUser. Let's assume that SendMoney.example.com typically displays a form so that VictimUser can transfer money to someone. The form looks like this:

<form method="post" action="form-handler.php">
  <input type="text" name="amount_of_money_to_send">
  <input type="text" name="recipient_email_address">
  <input type="submit" name="submit" value="submit">
</form>

Obviously, form-handler.php needs to make sure that whoever submits this form is authenticated. Unfortunately, just making sure a user is authenticated is not enough to prevent exploitation. Why not? Because AttackerUser, might make an evil exploit form and trick VictimUser into submitting it. This form could be hosted anywhere -- even emailed to a user. Compare this carefully to the prior form:

<form method="post" action="https://sendmoney.example.com/form-handler.php">
  <input type="hidden" name="amount_of_money_to_send" value="1000000.00">
  <input type="hidden" name="recipient_email_address" value="AttackerUser@example.com">
  <input type="submit" name="submit" value="Take Me to My SendMoney Page">
</form>

Obviously, form-handler.php needs to look at more than just the session cookie and this form's POSTed data to make sure that submissions are valid or the system will be vulnerable to attacks. It's tempting to think that one might protect against this problem by making sure that money transfers are followed up with an 'are you sure' form before actually completing the transaction, but this may not solve the problem. Keep in mind that a clever attacker might use Javascript to construct a series of AJAX requests to exploit even multi-page forms.

EXPLOIT EXAMPLE 2
NOTE: the AJAX attack here would in most cases be blocked unless the server supports Cross-Origin Resource Sharing (CORS) but I figured I'd still show this example. I posted another thread to try and understand how CORS works.

CSRF attacks need not be "blind" in certain cases. AJAX might allow an attacker to generate a series of page requests from VictimUser and inspect the results to generate a malicious request or relay this information to some remote site. Imagine one an attacker tricks VictimUser visiting AttackerDomain.example.com where they encounter this Javascript:

$(function() {
	$.ajax({
		xhrFields: {
			withCredentials: true
		},
		cache: false,
		crossDomain: true,
		type: "GET",
		async : true,
		dataType: "text",
		url: "http://sendmoney.example.com/my-secret-account-information",
		complete : function(jqXHR, str, str2) {
			console.log('response:' + jqXHR.responseText);
			// attacker puts code here to parse responseText which contains secret information of VictimUser
		}
	});
});

The idea in this example is that the attacker has written malicious code which creates an AJAX request from VictimUser! which uses VictimUser's cookies and credentials to retrieve VictimUser's secret account information and forward it to some site controller by attacker. This tactic might be used to defeat multi-page forms and, unless I'm mistaken, some of the tactics most often recommended to defeat CSRF attempts.

These examples should make it clear that it's important to defend against CSRF.

According to Wikipedia:

Wikipedia wrote:
Several things have to happen for cross-site request forgery to succeed:
1) The attacker must target either a site that doesn't check the referrer header or a victim with a browser or plugin that allows referer spoofing.
2) The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
3) The attacker must determine the right values for all the forms or URL inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will most likely fail (unless the attacker is extremely lucky in their guess).
4) The attacker must lure the victim to a Web page with malicious code while the victim is logged into the target site.

HOW TO PREVENT?
Once again Wikipedia:

CSRF prevention techniques work by embedding additional authentication data into requests that allows the web application to detect requests from unauthorized locations.

Next post will examine the recommended tactics for prevening CSRF exploits.

sneakyimp

CSRF EXPLOIT PREVENTION
Most of the prevention tactics involve requiring extra information with requests that deal with sensitive data. This extra information is usually a random token passed with the form submission or via cookie. When your web application handles these requests, it must take care to validate the token and reject any requests that fail to provide a valid token.

NOTE: Most of these defense tactics involve displaying a token in a form and then validating it in the form handler. One might naturally ask what prevents an attacker from simply creating some fancy Javascript that can create numerous page requests via AJAX such that the token can be fetched and then utilized in a subsequent exploit request (see Example 2 in prior post). The answer, as far as I can tell is the same-origin policy which is supposed to be enforced by web browsers. Briefly summarized, the same-origin policy makes it very hard for a script on one domain to formulate requests for another which provide all the authentication cookies. However, it is possible to configure one's server to permit such requests. It seems to be fairly complicated, however, and further research is recommended.

PREVENTION BY SYNCHRONIZER TOKEN
The Synchronizer Token Pattern involves generating a cryptographically secure token to supply with one's request. (See OWASP and Wikipedia descriptions and examples of this pattern and the requirements for the token. The token is typically added to a form as hidden input, appended to a url, etc. and then validated by the web application's handling script to make sure it's valid before proceeding with the sensitive data request. This is usually accomplished by checking any submitted token against an individual user's session.

OWASP offers some suggested PHP code to prevent CSRF. Personally, I wonder if this code, which looks like a shim for existing code is especially helpful. Issues:
the tokens are merely displayed in the form and should persist as long as the session does. A CSRF attack that was able to form multiple AJAX requests could read this form, extract CSRFName and CSRFToken, and then submit another request using these values. This would probably trigger a CORS warning as it seesm to in firefox, but the method does not seem especially secure to me
it does not use a cryptographically secure token generation method.
As with most synchronizer token approaches, a user clicking 'back' on their browser after a form submission might end up submitting the same token twice which would be rejected by the server.
Note that synchronizer token can complicate AJAX implementations. One would need to implement a method to supply a new synchronizer token via AJAX request. These tokens must be unique for a given session or this approach will not work. I.e., if AttackerUser can request a token that will also work for VictimUser, then this approach will not work at all.

The pros:
* tokens are unique to a given session, the method uses a different CSRFName every time a form is displayed, and each CSRFName can be submitted only once before being invalidated and wiped from session

PREVENTION BY REFERER OR ORIGIN CHECK
Which to check and what to check?

If we are the devs of SendMoney.example.com it we should probably check to make sure every request for sensitive data access or edits should have SendMoney.example.com (or some other trusted domain) in the REFERER or ORIGIN. On the other hand, if we want to explose an API, then excluding other domains could limit the accessibility of our API endpoints unless we concoct some other authentication scheme.

NOTE that HTTP_REFERER's value is supplied by the client software and might be spoofed if the client has been compromised. An example of a malicious HTTP_REFERER value in the exploit examples above might be:
http://attackerdomain.example.com/path/file.php

Or, try checking HTTP_ORIGIN -- although I'm not sure if we can depend on this value being set in older browsers? An example value from the exploits above would be:
http://attackerdomain.example.com

PREVENTION BY COOKIE-TO-HEADER TOKEN or DOUBLE-SUBMIT COOKIES
Wikipedia describes cookie-to-header token and OWASP describes double-submit cookies.
Basic idea is that when a user logs in (or possibly when a user session is established for non-authenticated users) , the server generates a token and sets it in a cookie on the client. This token will remain the same for the duration of the session (but may possibly change under certain circumstances. e.g., if fraud is detected). Then, any AJAX or javascript operations that deal with sensitive data will send a custom header with any subsequent requests. E.g.:

X-Csrf-Token: {token-goes-here}

Then the server will take care to check for this token whenever some sensitive data operation is performed. As the wikipedia page says:

Security of this technique is based on the assumption that only JavaScript running within the same origin will be able to read the cookie's value. JavaScript running from a rogue file or email will not be able to read it and copy into the custom header.

Pros:
Should make AJAX implementation easier as a single token exists for all operations
Cons:
What if an attacker can set this token's value? If browers permit third-party cookies, this may be possible?

PREVENTION BY ENCRYPTED TOKEN PATTERN
OWASP describes this pattern wherein the token is not a random token but rather an encrypted value that can only be decrypted by the server. The encrypted value may contain a timestamp, userid, or other information to constrain and/or verify the conditions under which the token is valid. Because the server alone has the encryption key, these values cannot be spoofed by a third party as long as the key is kept secret and not cracked. The contents of the token must be specific to a user session, however, such that tokens valid for one user are NOT valid for any other user. This approach also breaks down if any attacker can generate multiple authenticated requests originating from a victim -- but this situation should prevented with proper same-origin policy enforcement.

Derokorian was kind enough to share some CSRF prevention code in this thread. I believe it falls under the encrypted token pattern approach.

NogDog

One protection technique is to require re-authorization (i.e. their password) when a user tries to do anything potentially "dangerous". Of course, then you need to balance annoyance versus security. It could be moderated somewhat by keeping a "last login" time, and if any non-idempotent request is made X minutes since that time, require them to login.

sneakyimp

Can anyone tell me if HTTP_REFERER will always have protocol://domain/path ? I want to try and use parse_url to extract the host and, unfortunately, parse_url doesn't work all that well if the protocol is missing. This:

var_dump(parse_url("foo.com/bar.html"));

outputs this:

array(1) {
  ["path"]=>
  string(16) "foo.com/bar.html"
}

which is not especially useful for getting a host.

The documentation on $_SERVER doesn't provide much detail about what one might find in HTTP_REFERER.

sneakyimp

NogDog;11054677 wrote:
One protection technique is to require re-authorization (i.e. their password) when a user tries to do anything potentially "dangerous". Of course, then you need to balance annoyance versus security. It could be moderated somewhat by keeping a "last login" time, and if any non-idempotent request is made X minutes since that time, require them to login.

Thanks for pointing this out. I get behavior a bit like this on Ubuntu or when using sudo on any linux host. If I've recently entered my password, it doesn't bother prompting me.

However, this approach is also vulnerable to CSRF. Imagine, for instance, that I just completed some operation which prompted me for a password and then immediately check my email or something where a CSRF attack is waiting for me. Since I would have just supplied my password, the web application would currently be in the heightened state of authentication and therefore vulnerable to CSRF. Granted, prompting for a password periodically does reduce the window, but it doesn't really solve the problem of CSRF.

dalecosp

sneakyimp;11054699 wrote:
Can anyone tell me if HTTP_REFERER will always have protocol://domain/path ? I want to try and use parse_url to extract the host and, unfortunately, parse_url doesn't work all that well if the protocol is missing. This:
var_dump(parse_url("foo.com/bar.html"));
outputs this:
array(1) {
  ["path"]=>
  string(16) "foo.com/bar.html"
}
which is not especially useful for getting a host.

The documentation on $_SERVER doesn't provide much detail about what one might find in HTTP_REFERER.

It's generally not reliable. [thread=10324100]Here's a good discussion[/thread].

sneakyimp

dalecosp;11054709 wrote:
It's generally not reliable. [thread=10324100]Here's a good discussion[/thread].

I'm aware that HTTP_REFERER is "unreliable" because it may or may not be supplied by the client software. My interest in this case is not so much in screening out bad guys who might spoof this data for their own requests -- I'll be sure to validate any submissions as best I can in other ways -- but rather preventing bad guys from tricking some VictimUser into making a well-formed request that is not in their own best interest. I think it's extremely unlikely that bad guys will be able to display a malicious form on my site, but quite likely they could display one on SomeOtherDomain.example.com or in an email message. Assuming VictimUser is using a well-behaved browser that has not been compromised, the HTTP_REFERER value should actually represent the referring page -- and it would therefore be of some use to check this value and exclude any sensitive request where HTTP_REFERER doesn't at least contain my domain name. Something like this:

define("MY_DOMAIN", "MyDomain.example.com");
$referer_domain = parse_url($_SERVER["HTTP_REFERER",  PHP_URL_HOST);
if (strncasecmp(MY_DOMAIN, $referer_domain) !== 0) {
  die("Exploit attempt! Bad referer");
}

I can see this code causing a problem for any first-entry page on my site, but it seems like a good idea for any POST operations. It would make sure that the POST operation was at least referred by my site. I realize it would not deter AttackerUser who is trying to game my system, but for any well-intentioned user of my site, it should not present any problems, right?

NogDog

sneakyimp;11054701 wrote:
Thanks for pointing this out. I get behavior a bit like this on Ubuntu or when using sudo on any linux host. If I've recently entered my password, it doesn't bother prompting me.

However, this approach is also vulnerable to CSRF. Imagine, for instance, that I just completed some operation which prompted me for a password and then immediately check my email or something where a CSRF attack is waiting for me. Since I would have just supplied my password, the web application would currently be in the heightened state of authentication and therefore vulnerable to CSRF. Granted, prompting for a password periodically does reduce the window, but it doesn't really solve the problem of CSRF.

Yeah, but it's all about layers. If you combine that along with other techniques, even if none by itself is a guarantee of security, the sum total reduces the odds of an attack getting past all of those defenses.

Derokorian

You could do something like this (actual line of code from a project I have):

$parsed = parse_url((substr($_SERVER['HTTP_REFERER'], 0, 4) == 'http' ? '' : (empty($_SERVER['HTTPS']) ? 'https://' : 'http://')) . $_SERVER['HTTP_REFERER']);