Scribd
Upload
22 views5 pages

Cross Site Request Forgery

Cross-Site Request Forgery (CSRF) is a web security vulnerability that allows attackers to make users perform unintended actions, potentially leading to unauthorized actions, data theft, and reputational damage. CSRF attacks require specific conditions, including cookie-based session handling and predictable request parameters, and can be tested using custom HTML scripts or tools like Burp Suite. Mitigation strategies include using CSRF tokens, implementing Same-Site cookie attributes, and avoiding GET requests for state-changing operations.

Uploaded by

hipawi9310
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
22 views5 pages

Cross Site Request Forgery

Cross-Site Request Forgery (CSRF) is a web security vulnerability that allows attackers to make users perform unintended actions, potentially leading to unauthorized actions, data theft, and reputational damage. CSRF attacks require specific conditions, including cookie-based session handling and predictable request parameters, and can be tested using custom HTML scripts or tools like Burp Suite. Mitigation strategies include using CSRF tokens, implementing Same-Site cookie attributes, and avoiding GET requests for state-changing operations.

Uploaded by

hipawi9310
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

CROSS SITE REQUEST FORGERY (CSRF)

Cross-Site Request Forgery (CSRF) is a web security vulnerability that allows an


attacker to make a user perform unintended actions that have serious
consequences like changing email and password, banking payments etc. It is a
way of partly-circumventing the Same-Origin policy which is intended to
prevent different sites from interfering with each other.

How does CSRF work?

There are 3 important conditions to be in place for a CSRF attack to be possible:

1. A relevant action: There is an action that an attacker tries to induce the victim to
perform. Generally, there are sensitive actions that change the data or user-specific
actions
2. Cookie-based session handling: There needs to a cookie-based session handling, as
the actions performed are user specific to identify who has made the request. There
should be no other tracking or session validating mechanisms
3. No unpredictable request parameters: There should not be any parameters that an
attacker cannot predict to perform an action or submit a form. For example, when a
user tries to change their password, if there is a parameter to specify the current
password which is unpredictable by the attacker, then a CSRF attack is not possible

How do you test for a CSRF vulnerability?

There are several methods that can be used for testing a CSRF vulnerability. The above-
mentioned conditions are must to be present to perform a CSRF attack.

We can prepare a custom HTML script that hides the input values of a form except for the
submit button, which performs a sensitive user specific action. We could also append a script
that automatically submits the page on loading. Based on the cookies present, the HTTP
request sent by the attacker generated page determines that the request was sent from the
victim and performs the actions on the victim’s account.

The Burp Suite CSRF PoC Generator can be used to automatically generate a HTML form page
that induces the desired action.

An example of the CSRF PoC is:

The above HTML form page sends an email change request to a vulnerable site with the email
parameter hidden to the victim but the value is prefilled by the attacker and the JavaScript
submits the form once the page is loaded and since the victim opens the page, the cookies of
the victim tell the vulnerable site that the victim is the one requesting the action.

The delivery mechanism of the CSRF PoC is the same as that of a reflected XSS. Typically, the
attacker puts the HTML code in the website they control and induce the victim into opening
the site. This might be done by feeding the user a link to the website, via an email or social
media messages, or if the attack is placed in a popular web site, the link may be placed in the
comment section and the attacker waits for the victim’s interaction.

Note that a simple CSRF attack uses a GET request method and can be fully-contained in a
single URL on the vulnerable web site. It does not even need a fully crafted external webpage
to employ the attacking mechanism and can directly feed the victim a malicious URL on the
vulnerable domain.

Impacts of CSRF attack:

There are several consequences of a CSRF attack. Few of them are as follows:

1. Unauthorized actions: Attackers can use CSRF attacks to perform unauthorized


actions on behalf of the victim, such as changing passwords, transferring funds, or
making purchases.

2. Data theft: Attackers can use CSRF attacks to steal sensitive data, such as login
credentials, personal information, or financial data.

3. Reputation damage: A successful CSRF attack can damage the reputation of the
targeted website or application, leading to a loss of trust from users and customers.

4. Legal consequences: If a CSRF attack results in the theft of sensitive data or


financial loss, the targeted website or application may face legal consequences.
Methods of mitigation of CSRF vulnerability:

Some of the popular methods of mitigation of CSRF vulnerability are:

1. Check if your framework has built-in CSRF protection and use it. If not, then add CSRF
tokens to all state changing requests (requests that cause actions on the site) and
validate them on the backend
2. For stateful software use the synchronizer token pattern.
3. For stateless software use double submit cookies.
4. Use of Same-Site header attributes for session cookies, which can only be sent if the
request is being made from the origin related to the cookies and not cross-domain
5. Do not use GET requests for state-changing operations
6. Implement identifying source origin via Origin/Referer header
7. One-time token should be implemented for the defense of User Interaction based
CSRF
8. Secure against any XSS (Cross-Site Scripting) attacks, as any XSS can be used to defeat
all CSRF mitigation techniques.
References:

https://portswigger.net/web-security/csrf

https://cheatsheetseries.owasp.org/cheatsheets/Cross-
Site_Request_Forgery_Prevention_Cheat_Sheet.html

You might also like