CSRF Tokens

[00:00:00]
>> Mike North: How do we know if we're vulnerable or not? You are vulnerable if your server looks to a cookie sent along with the request, or basic authentication credentials sent along with the request, in order to authenticate or authorize a user. Authenticate would be like this is who you are.

[00:00:18]
Authorize would be these are the privileges that you have. Like are you as a user able to view this resource? So the exception here would be a client side cookie. So if, for example, if you pluck something out of a cookie that then needs to be placed into a request header.

[00:00:41]
That is the kind of thing that is not susceptible to a Cross-Site Request Forgery. So here's why. In order to read that cookie, you need to be running code on a domain that can access that cookie. Web storage is partitioned on a per domain basis. So if you're using the cookie as a storage mechanism only.

[00:01:03]
And if the server, when it receives a request is not looking at that cookie as the means of identifying the user, then this method of attack doesn't work any more. This attack works because I can write code on my site that will make a request to someone else's site.

[00:01:18]
And although I can't read those cookies, I take advantage of the fact that the cookies are sent along for the ride. I actually can't see any communication between the user and that remote server, but I can basically trick them into mutating data into changing something. So as soon as the methodology of authenticating a user depends on something that only code running on that domain can perform, such as placing a value in a authorization header, you're in the clear here.

[00:01:56]
You are, I gotta be careful about saying you're in the clear in a security course, but you have mitigated the broadest form of this kind of attack. Local storage and session storage, these are accessible only on the client side. If you don't know the difference, session storage, that is when the user logs out, that's destroyed, right?

[00:02:19]
When they close the browser, that's destroyed. Sorry, it's not log out, it's close the browser. Local storage can live for much longer. Neither of these are passed along by default with each request as cookies are.
>> Mike North: So one typical mechanism for solving this is to create something called a CSRF token.

[00:02:42]
And this, like the cryptographic nonsense we talked about earlier, they are generated in an unpredictable way with each page load. So basically, the server knows that these are the keys that I've generated. It might be that if we think about a simplistic definition it could be, it generates numbers but they have to meet a certain condition, like they're divisible by 67, 5, 812, and 1,984.

[00:03:13]
Only if it meets that condition, we can generate many numbers that meet that condition, but we have some way of verifying that yes, that is a genuine one. And they are disposable, meaning you can only use them once and then that CSRF token value is not usable again.

[00:03:32]
So typically you want to have an iterative algorithm that generates new ones. And you can basically say that this is almost treated like a monotonically increasing value, where you go one, two, three, four, five. And you can basically read into the value of this token and say, nope, that's too old.

[00:03:51]
So sometimes it's like a salt. That is, it is a secure value generated for that server combined with a time stamp or a counter so that you can ensure these do not get reused over and over again. I like to think of this kind of like, it is like two factor authentication in that you have two pieces involved.

[00:04:16]
One proving that you are authenticated, right? That cookie was not something that anyone can fake. You get a cookie by logging in as a legitimate user. We could even encrypt the cookie, right? And say only the server can make sense of this thing. And then the second piece, it basically proves that you came from code running on that origin that is intended to make requests to the back end.

[00:04:44]
Something that only code running in on that domain could do, because it's reaching into local storage, or it's reading something from a meta tag. These are things that we talked about opaque requests earlier. These are things that you would not be able to see because an opaque request would not let the attacker's code see that kind of thing.