"Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request." (1)
If that didn't make sense to you, that's ok. It's a lot of technical speak.
So basically, it is the ability for an attacker to leverage a website, or application, that you are already logged into. It does this by tricking your device into running some code that gets executed as you because your browser automatically adds in the cookies from your alive session that identifies you. This happens because the website cannot distinguish between the fake or legitimate request sent by a victim.
In the first case I found this is what caught my attention. The URL had the User Token right in it. Seemed odd to me to have it right there in the open in and being treated as non-sensitive data.
This specific one can be difficult to spot even though it's right in front you and understanding what this simple token can do without really seeing it is the hardest for new people to grasp (or maybe just me). I didn't understand what I was looking at at first and it's taken some playing with to get it to exploit. However, once it does it all makes sense. Let's look further.
In my case, I found the attack point because it was as simple as a token in the URL of an page. (see above image)
From here I was able to take that token from the URL and watch in the browser how the network was handling it. Surprise surprise, it was putting the token it into some form values (with some other information) to perform an action (change password, change user settings, etc).
Now, because I wanted something tangible to prove this point, I used the form to change my password for my account. First I needed to watch the network and how it was handling the request. Below you can see the network request when I update my password manually with gibberish in it.
Now lets build a small HTML page that has a form for the token to sit in and the other fields needed to change my password.
As you can see above, the form isn't much. It is a simple form with a few input fields. Below is what the simple HTML page looks like in the browser. Nothing much right? But successful.
NOTE:: This part does need to be done semi quickly as cookies do expire (eventually).
Once the page is set up I was able to log into my account, take the token from the URL and put it into the HTML page, open the HTML page and poof! password successfully changed just by having the token from the URL in a different HTML page.
"Account information saved."
Having the token in the URL like is bad because it is exposing this sensitive data to the world (and all their ad partners to see).
But really, why is this bad??
URLs are not treated as sensitive data and this user identifying sensitive data is being given away in browsing history, shared systems, web logs, and referer headers to name a few.
The underlining issues is that they have an information disclosure issue that is leaking the CSRF token, that is supposed to protection against CSRF attack.
If there is a malicious ad running on the page or malicious script hidden in the page that can run automatically then that token is being given away to an attacker to take advantage of.
NOTE:: Realistically, getting the password changed is probably pretty difficult because you have to know their current password BUT if there was real malicious intent then some social engineering could be done to acquire it, lock the user out of their account, sell the account data, or worse depending on the type of account.
As a user the best way to avoid this is by
-Logging out of sites after using. CSRF attacks rely on the victim having a valid session so when you log out, you invalidate the session on that site, leaving no sessions for the attacker to exploit. (The cookies stored in your browser will no longer work.)
-Use a different browser for sensitive sites such as Duck Duck Go or Firefox. Because CSRF attacks also rely on the victim’s browser storing the credentials of the vulnerable website, by using separate browsers for sensitive activities, in general, you can make sure that if you do stumble upon a CSRF exploit page or email during casual browsing, the browser that you are using will not have the credentials to sensitive sites.
As a developer the best way to avoid this is by
-Not storing sensitive data in areas that are considered not-sensitive, such as URLs.
-If able to have an external file for them, do. They should be treated as sensitive as user passwords.
-Encrypt them in a hidden field if they really need to be in the site. This will prevent a site from getting them as the page will only contain the information as specific times.
-Use the 'HttpOnly' flag. If a token needs to be stored in a cookie then using "this flag tells the browser that the cookie in question shall only be accessible from the server specified. Any attempts made by client-side scripts would be forbidden by this flag, therefore helping to protect against most cross-site scripting (XSS) attacks."