Tacos and Security

Learning Things: CSRF - Cross-Site Request Forgery

DanielxBlack -

I've heard the term multiple times, but I actually had no real idea what it was. Cross-Site Request Forgery, or CSRF (also somtimes pronounced as Sea-Surf). Well, I had the textbook definition that goes something like this: "it's a type of web attack that causes a user to execute unintended commands on a web application in which they are currently authenticated."

Sure, that's not wrong, but it's going to take a lot more than memorizing a definition to really be good at what I do. I have to dive in a bit, eh?

First, we must understand HTTP requests

There are quite a few request types, but for now, we are only concerned with the most common one: the GET request.

We can learn a bit here, but basically, the GET method "is used to request a resource from the server." Furthermore, the GET method should only be used to receive data from the server. Methods such as "PUT" and "POST" (as well as a few others) should be used to change data on the server – GET should definitely not include data.

So what happens if it can send data to the server?

According to Malcom McDonald's Web Security for Developers, GET requests are the only type of HTTP methods "that contain the entirety of the request's contents in a URL." Which, according to McDonald, makes them uniquely vulnerable to CSRF attacks.

Some things to know when crafting an attack

In order to craft such an attack, you have to understand how the web application uses GET to change data. That is, if it's allowing for this to happen. Let's pretend that in this case it is, and we know that the site is vulnerable. Let's say that it lets and authenticated user post a status update. Submitting a comment consists of a GET request that looks something like this:

  • http://derp.com/comment/update?saywhat=Hello

This posts a status update as the currently authenticated user. The update is nothing more than the the word "Hello." The session belongs to the user, because they are authenticated. The user could also, in this case, create an update that says, "I like tacos." by using the following:

  • http://derp.com/comment/update?saywhat=I%20like%20tacos.

Again, because the session belongs to the user sending the GET request, it creates the status update as the authenticated user. We also know how to craft the URL that will create the update to the user's status, as we can see above.

Making it work

The next step is to perhaps trick an unsuspecting user into clicking on the link, which would essentially force them to make a GET request (while authenticated) that will update the post. This is where the social engineering aspect can come into play. The attacker sends some sort of message that reads like, "Bruh, look at this embarrasing video I found of you!" Maybe you click it, and then you're hit. Before you know it, you've been hit with and CSRF attack and your account is sending your friends the, "Bruh, look at this embarrassing video I found of you!" Some of them also click it, and so on.

All-in-all

So ... yeah. That's kinda how I understand it. I'm still reading up, but that's something of a basic explanation of how it works based on what I've been reading so far. I will start reading deeper into how it works, so I can also start talking about how to test for it, and dive even deeper into the inner-workings of the CSRF.