What is Cross-Site Request Forgery (CSRF) with full information?
What is CSRF Vulnerability:
Cross-Site Request Forgery (CSRF) attacks are a type of web security vulnerability that allows an attac`ker to execute unauthorized actions on behalf of a victim user. These attacks typically exploit the fact that many web applications do not sufficiently validate the origin of requests made to the server, allowing an attacker to trick a victim into unwittingly executing an action on the attacker’s behalf.
A rogue web page with a form or script that sends a request to a web application that is vulnerable is what the attacker often does in a Cross-Site Request Forgery (CSRF) attack.
Without the victim’s knowledge or consent, their browser automatically submits the form or runs the script after the victim is deceived into accessing the malicious web page.
This may lead to the victim’s password being changed, money being transferred from their account, or data being deleted.
How CSRF Works:
To understand how Cross-Site Request Forgery (CSRF) attacks work, it’s important to understand the basics of how web applications handle requests. When a user submits a form or makes a request to a web application, the browser includes a “cookie” that identifies the user’s session with the application. The web application uses this cookie to verify that the request is legitimate and authorized by the user.
However, if a user is tricked into visiting a malicious web page that contains a form or script, the browser will still include the user’s cookie in the request to the vulnerable web application. This means that the web application will see the request as legitimate and authorized, even though the user did not intend to execute the action.
Types of Cross-Site Request Forgery & Exploit:
Let’s take a look over three common types of Cross Site Scripting:
URL-based CSRF: It can be easily exploited, because the attacker needs only to craft a specific URL, and waits for the victim to click it. This affects only requests that accept GET HTTP Method.
For example, let’s suppose we have an administrator portal located at the following URL:
https://securiumsolutions.com/wp-content/uploads/2023/03/link-images-01-min-scaled.jpg
This portal can be accessed only with a password, which can be generated by a system administrator already authenticated into the administration portal, by accessing the following link:
It will send the new password to the email parsed into the “email_to” URL parameter value. We already know that this is vulnerable to CSRF, so we can craft the below link, send it to the system administrator (through a LinkedIn message for example), wait for her/him to click it, and we will get the new password to our email ([email protected]), resulting in a full admin panel compromise.
Form-based CSRF: For this type of CSRF, we must struggle a little more, because the goal is to force the end user to submit data through a malicious form. It can be used against requests that accept POST HTTP Method.
For example, let’s say that web developers fixed the issue described above (URL-based CSRF), and now, application accepts only POST request to the endpoint, under the following syntax:
POST /admin.php Host: corneacristian.medium.comPOST Data: action=reset_admin_pass&[email protected]
We have to create a form on a website that we own, and introduce the following form:
And we have to trick our victim into clicking the submit button on our form.
Embedded CSRF: This method will not work against modern browsers until the Access-Control-Allow-Origin is set to “*”. It works for almost all requests vulnerable to CSRF, regardless of their allowed methods.
For example, the following script will be executed, and the CSRF will be exploited once the victim enters the website containing it:
<script> function CSRF() { var x = new XMLHttpRequest(); x.open(“PUT”,”https://corneacristian.medium.com/admin.php”,true); x.setRequestHeader(“Content-Type”, “application/json”); x.send(JSON.stringify({“action”:”reset_admin_pass”, “email_to”:[email protected]})); } </script>
<body onload=”CSRF()”>
How to prevent Cross-site Request Forgery / Cross Site Scripting:
Web applications should include a number of security precautions to stop CSRF attacks. One typical practise is to include a “CSRF token”—a randomly generated number that is included in the request and confirmed by the server—in each form or request. If the token is not provided or is wrong, the server will reject the request as unauthorised.
Using “same-site cookies,” which limit cookies to only being delivered to the same domain as the web application, is another option. By doing so, an attacker may be prevented from stealing a user’s cookie and using it to carry out unauthorised operations on a web application that is vulnerable.