Now that we've talked about forms a bit, I want to talk a little bit about security in forms. I want to talk about a security issue called Cross-Site Request Forgery or CSRF. So the idea of a CSRF attack is that a rogue site, it has to do with cookies and how cookies get sent to sites. So let's say you're logged into my site and a rogue site generates a page that's going to POST. And on every form, you can POST to a site other than the one it came from. And so if I can get data that I want to send to the legitimate server, the rogue site can set up a POST. And then the minute you hit the button, then it will grab the cookie and send it to the legitimate server that you're already logged into, and perhaps do something dangerous. And so the rogue server doesn't need to know the cookie. The rogue server just needs to convince you to click on a rogue form to send to the request server. So the defense for CSRF is to, it's not, don't be confused with session. It is going to use session. We're going to grab another large random number and we're going to call it the CSRF token and we're going to stick that in the session. And then what we do is every time we send a form out that's coming from our server, we add a little input hidden tag that has this CSRF token. And then when the POST comes in, we check the CSRF token that's coming in in the POST data, and then we check it against the one that's in the session. And then rejects it if it doesn't match. So here's a picture of how this works, right? So, we'll have a legitimate server, right? We're going to produce a page by the legitimate server and it's going to POST back to this same server. The action is the URL to send the POST data to. And we've got some key-value pairs and a submit button, right? So you hit the submit button and it's going to come back to the server. Now, one of the things that the browser is supposed to do is pull the cookies for that server and send it. So it sends it both a POST and the data, but it also sends the session ID cookie. And then what happens is that the Django gets its hands on it. It looks up the session ID, pulls it in, and notices that it's csev and I've been logged as an instructor. And then then I can actually change this grade and set the grade and it works, okay? Now, here is what happens when you get to a CSRF attack. So somehow a page gets sent to the server, right, sent from a rogue server and it just has this form, method equals post, action equals dj. It's not the action, it's going to a different place. And it puts sort of a new grade and then a submit. So what happens is this submit comes in and the browser dutifully appends the cookie to it and it sends it. Now, you had to be tricked into getting to this page and sometimes tricked into submitting the page. But, once the POST comes in, it has the legit cookie in it. The cookie is used to look up the session and reassociate it. And we can check in the session that the user is indeed logged in. And we'll let the thing set the grade to 1.0. So this would be a way, if you could convince a logged-in instructor to run a POST form that you created, you could basically change your grade. So that's how it works. That's how a CSRF attack. You have to be tricked twice first, but there's ways in JavaScript to make it so it's hardly noticeable that you get tricked. So if you do this with CSRF, the legit server basically adds another value, not the session ID but another value, in the session, which is a random large randomly chosen number. And then when a page comes out, it's a legit page and it uses a type hidden variable and puts the CSRF value in. Now you hit the submit button and the CSRF is coming in as POST data, the regular data, the grade data is coming in. And the browser dutifully appends the session. And so then using the session cookie, it reassociates the session, it says, yep, you're csev and you're the instructor. And the CSRF works, CSRF matches, so let's go ahead and let you set the grade. So we let them in. With the attack blocked, because the rogue server can generate a page but it doesn't know what the CSRF is. So it could, who knows what the CSRF is, so it generates it. Maybe you can put a CSRF, but it doesn't know it. So then the POST happens. And all the data gets gathered up, and so it sends the CSRF but it's not the right CSRF. The session ID is sent in. And so the session is pulled in. We know it's user csev, we know it's instructor, but we're going to check to see if the CSRF matches and then it blows up. And so then you just refuse the POST, probably log the user out, and then log some kind of a security error. So the idea is by having this little CSRF number in the session, we can then take care of that. So, like most things, Django comes out of the box with CSRF protection built in. Just like the session, we've got CSRF middleware just dropped in. And actually it works automatically. You don't even have to ask for it to work. Once you have a session, it starts putting out CSRF things. So up next, we'll talk about, now that we know the concept of CSRF, we'll talk about how we're going to use CSRF inside of forms to implement sort of CSRF protection. [MUSIC]
