Cross-Site Request Forgery (CSRF) is one of the oldest ways of exploiting a website's vulnerabilities. It targets server-side web switches that usually require authentications like logging in. During a CSRF attack, an attacker aims to force its victim into making an unauthorized, malicious web request on their behalf.
Weak or poor website security practices and carelessness on the user's path are some of the common causes of a successful CSRF attack.
Let's look at what a CSRF attack is and the possible ways you can prevent yourself from it as a developer or as a user.
How Do CSRF Attacks Affect You?
A CSRF is an attack used to implement unauthorized requests during web actions that require user login or authentication. CSRF attacks can take advantage of session IDs, cookies, as well as other server-based vulnerabilities to steal a user's credentials.
For example, enabling anti-CSRF procedures prevents cross-domain malicious interactions.
Once that barrier breaks, an attacker can quickly take advantage of the user's session ID via the cookies created by the user's browser and embed a script tag into the vulnerable website.
By manipulating an ID, the attacker can also redirect visitors to another webpage or exploit social engineering methods like email to send links, encouraging the victim to download malicious software.
Once the victim performs such actions, it sends an HTTP request to the user's service page and authorizes the request action in favor of the attacker. That can be devastating to an unsuspecting user.
A successful CSRF attack can make authorized users lose their access credentials to an attacker, especially during server-based actions like password or username change requests. In worse scenarios, the attacker takes over the entire session and acts on users' behalf.
CSRF has been used to hijack over-the-web fund transactions as well as changing usernames and passwords, which leads to users losing access to the affected service.
How Attackers Hijack Your Sessions With CSRF: Examples
The main targets for CSRF attacks are web actions involving a user's authentication. To be successful, it needs unintentional actions from the victim.
During a CSRF attack, GET, DELETE, and PUT actions, as well as vulnerable POST requests are the main targets of an attacker.
Let's look at the meaning of those terms:
- GET: A request to collect a result from the database; for example, Google search.
- POST: Typically for submitting requests via web forms. A POST request is common during a user's registration or login, otherwise known as authentication.
- DELETE: To remove a resource from the database. You do this whenever you delete your account from a particular web service.
- PUT: A PUT request modifies or updates an existing resource. An example is changing your Facebook name.
In practice, attackers use session hijacking to back-up a CSRF attack. When using this combination, the attacker can use a hijack to change the victim's IP address.
The change in IP address then logs the victim into a new website where the attacker has inserted a deceitful link that submits a replicated form or modified server request they created via CSRF.
An unsuspecting user then thinks the redirect comes from the service provider and clicks the link on the attacker's webpage. Once they've done this, hackers submit a form on page load without their knowledge.
Example of a GET Request CSRF Attack
Imagine trying to make an online payment via an unsecured e-commerce platform. The platform owners use the GET request to process your transaction. That GET query might look like this:
https://websiteurl/pay?amount=$10&company=[company ABC's account]
A hijacker can steal your transaction easily by changing the parameters of the GET request. To do this, all they need do is to swap your name for theirs, and worse, change the amount you intend to pay. They then tweak the original query to something like this:
https://websiteurl/pay?amount=$20000&company=[attacker's account]
Once you clicksa link to that modified GET request, you end up making an unintentional transfer to the attacker's account.
Transacting through GET requests is bad practice, and makes activities vulnerable to attacks.
Example of a POST Request CSRF Attack
However, many developers believe that using POST request is more secure for making web transactions. While that's true, unfortunately, a POST request is susceptible to CSRF attacks as well.
To successfully hijack a POST request, all an attacker needs are your current session ID, some replicated invisible forms, and sometimes, a little social engineering.
For example, a POST request form might look like this:
<form action="Company ABC's account" method="POST">
<input type="text" name="name" placeholder="name">
<input type="number" name="amount">
<input type="submit" name="submit">
</form>
However, an attacker can swap your credential by making a new page and modifying the form above into this:
<body onload="document.getElementById('payment-form').submit();">
<form action="Attacker's account" id="payment-form" method="POST">
<input type="text" hidden name="name" placeholder="name">
<input type="number" hidden value=30000 name="amount">
<input type="submit" hidden name="submit">
</form>
</body>
In the manipulated form, the attacker sets the value of the amount field to "30000", swaps the recipient's account number to theirs, submits the form on page load, and also hides the form fields from the user.
Once they hijack that current session, your transaction page initiates a redirect to the attacker's page, which prompts you to click a link they know you're most likely to visit.
Clicking this loads the submission of the replicated form, which transfers your funds into the attacker's account. That means you don't need to click buttons like "send" for the transaction to take place, as JavaScript automatically does this upon loading the next webpage.
Alternatively, an attacker can also draft an HTML-embedded email that prompts you to click a link to perform the same page-load form submission.
Another action that's vulnerable to a CSRF attack is a username or a password change, an example of a PUT request. An attacker replicates your request form and replaces your email address with theirs.
Then they steal your session and either redirect you to a page or send you an email that prompts you to click an appealing link.
That then submits a manipulated form that sends the password reset link to the hacker's email address instead of yours. That way, the hacker changes your password and logs you out of your account.
How to Prevent CSRF Attacks as a Developer
One of the best methods to prevent a CSRF is to use frequently changing tokens instead of depending on session cookies for running a state change on the server.
Many modern backend frameworks offer security against CSRF. So if you want to avoid the technicalities of beefing-up against CSRF yourself, you can tackle it easily by using server-side frameworks that come with built-in anti-CSRF tokens.
When you use an anti-CSRF token, server-based requests generate random strings instead of the more static vulnerable session cookies. That way, you get to protect your session from being guessed by the hijacker.
Implementing a two-factor authentication (2FA) system for running transactions on your web app also reduces the chances of a CSRF.
It's possible to initiate a CSRF via cross-site scripting (XSS), which involves script injection into user fields like comment forms. To prevent this, it's good practice to enable HTML auto-escape in all user form fields across your website. That action prevents form fields from interpreting HTML elements.
How to Prevent CSRF Attacks as a User
As a user of a web service that involves authentication, you have a part to play in preventing attackers from stealing your credentials and sessions via CSRF as well.
Ensure you're using trusted web services during activities that involve fund transfer.
In addition to this, use secure web browsers that protect users from session exposure, as well as secure search engines that protect against search data leakages.
As a user, you can also depend on third-party authenticators like Google Authenticator or its alternatives for verifying your identity over the web.
Although you might feel helpless to stop an attacker from hijacking your session, you can still help prevent this by ensuring that your browser doesn't store information like passwords and other login details.
Beef up Your Web Security
Developers need to regularly test web apps for security breaches during development and deployment.
However, it's common to introduce other vulnerabilities while trying to prevent others. So be careful to ensure that you've not breached other security parameters while trying to block a CSRF.