Cross-Site Request Forgery or CSRF: How It Works and Prevention

Published on: July 25, 2024

.

12 min read

Cross-Site Request Forgery (CSRF) is a common web security vulnerability that lets attackers coerce users into performing undesired actions on an authenticated web application. CSRF attack results in modifying account settings or transactions without the user's permission.

A cross-site request forgery (CSRF) attack is deceiving the target to send a request to a web application where the victim is authenticated. Usually, to accomplish this, harmful code is embedded into an email, webpage, or other online material. The victim's browser automatically includes the user's session cookies in the request when interacting with this material. This is done while the user is signed into the vulnerable application. So it gives the impression that it is authentic.

For example, suppose a user is logged into their bank account. If they visit a malicious website that contains an HTML code piece. Upon loading the page, the form is submitted automatically and transfers money to the attacker's account without the user's knowledge.

The consequences of a successful CSRF attack can be severe, including unauthorized fund transfers, changing account email addresses or passwords, and taking actions that damage user account security.

CSRF is a significant security threat that takes unauthorized actions on behalf of users. This exploits the trust that a web application has in the user's browser. To protect the applications and users from these types of cyber attacks, it's important to understand how it works and its impacts. This is how it becomes possible to implement robust prevention measures.

The following topics are going to be covered in this article:

• What is CSRF?

• How do CSRF Attacks Work?

• What is the impact of a CSRF attack?

• How to Determine CSRF Vulnerabilities?

• How to Prevent CSRF Vulnerabilities?

• What are CSRF Preventive Measures that do not Work?

• What are Examples of CSRF Attacks?

• How to Create a CSRF Attack?

• How to Send a CSRF Exploit?

• What are Common defenses against CSRF?

• What are CSRF Related Attacks?

• What is the Difference between CSRF and RCE?

What is CSRF?

Cross-site request forgery (CSRF), is a cyber attack method that tricks a web browser to perform an undesired action on an application while the user is signed in. It is sometimes referred to as XSRF, Sea Surf, or Session Riding. A successful CSRF attack can be highly damaging to both the business and the user. Potential consequences include compromised client relationships, unauthorized fund transfers, changed passwords, and data theft, including the theft of session cookies. CSRF attacks often involve malicious social engineering techniques, such as emails or links that deceive the victim into sending a forged request to a server. Since the user is authenticated in the application at the time of the cyber attack, it is impossible to differentiate between a legitimate request and a forged one.

The main steps of a successful CSRF attack example are as follows:

1. The perpetrator spoofs a website request for a financial transfer.

2. The attacker sends the request to users who might be logged into the website by embedding it in a hyperlink.

3. When a visitor hits the link, the request is unintentionally sent to the website.

4. The website verifies requests and sends money to the attacker from the visitor's account.

How Do CSRF Attacks Work?

An attacker’s goal in a CSRF attack is to compel a user to make a state-changing request. These include submitting a transaction, deleting a record, ordering a product, changing authentication, or sending a message. Attackers often use social engineering platforms to initiate CSRF attacks. They deceive the victim into clicking a URL that contains an unauthorized request crafted for a specific web application. The user's browser then sends this malicious request to the targeted web application, including any relevant credentials like session cookies. If the user is logged into the targeted application, it processes the request as if it were legitimate. Consequently, the attacker exploits the web application's CSRF vulnerability.

CSRF attacks target web applications that cannot distinguish between legitimate requests and those forged by attackers. Attackers have various methods to exploit this vulnerability.

Meanwhile, it's not always easy to conduct CSRF attacks. There are some limitations of CSRF attacks. The success of a CSRF attack depends on the user being logged into the vulnerable application. The attack will only succeed if the user has an active session. The attacker must identify a valid URL to craft the malicious request. The URL must have a state-changing effect on the target application. The attacker must use the correct values for the URL parameters. If incorrect, the target application might reject the malicious request.

What is the Impact of a CSRF Attack?

A successful CSRF attack can have significant consequences for both users and web applications.

The severity of the impact depends on the attacker's goals and the specific functionalities of the targeted web application. Applications that handle confidential user information or financial transactions are especially vulnerable to CSRF attacks. Attackers might potentially do more harm by accessing a greater variety of system resources through compromised user accounts. Even seemingly harmless actions, like changing a profile picture, can be exploited by attackers through CSRF to gain a foothold in a user's account. CSRF attacks are a silent threat, users might not even be aware that their browser has been tricked into performing unauthorized actions.

What are the Impacts of CSRF Attack on Users?

The potential impacts of a CSRF attack on regular users are as follows:

• Attackers can exploit CSRF to initiate unauthorized financial transactions, such as transferring money out of a victim's bank account or making fraudulent purchases. The result would be a loss of money or assets.

• CSRF attacks can be used to steal sensitive user data. The attacker can access it through the manipulated action or even completely take over a user's account by changing their password or email address.

• Attackers might modify user settings or configurations. This may restrict access or compromise the usability of accounts. The impact is loss of control or functionality.

What are the Impacts of CSRF Attack on Web Applications?

The potential impacts of a CSRF attack on web applications are as follows:

• Security breaches due to CSRF vulnerabilities can damage user trust in the application's ability to protect their data and privacy.

• Public exposure of a CSRF vulnerability can negatively impact the application's reputation and deter users from using it.

• In some cases, attackers might leverage CSRF to launch Denial-of-Service (DoS) attacks by overwhelming the server with a flood of forged requests. This can disrupt service availability for legitimate users.

• CSRF vulnerabilities may lead to non-compliance with data security standards.

How to Determine CSRF Vulnerabilities?

Cross-Site Request Forgery (CSRF) vulnerabilities can lead to significant security issues in web applications. It lets attackers perform actions on behalf of authenticated users without their consent. Identifying these vulnerabilities involves being aware of common CSRF vulnerabilities, testing them, and code review. Common CSRF vulnerabilities often stem from flaws in the CSRF token verification process. The best practice for your CSRF implementation is to avoid the following issues:

• Tokens are useful, but they can be exposed in other ways, such as referrer headers when a protected site links to an external URL, browser history, HTTP log files, and network appliances that report the first line of an HTTP request. Tokens are not a completely foolproof solution because of these possible weak points.

• In some applications, the verification process is bypassed if the token is missing. Validation depends on token presence. This allows an attacker to simply locate and remove the token-related code, circumventing validation altogether.

• Some applications use a pool of tokens that are accepted as long as they belong to the pool. However, these tokens are not linked to specific user sessions. An attacker only needs one token from the pool to impersonate any user.

• In certain applications, using the GET method instead of POST can cause CSRF validation to fail. An attacker can switch the method from POST to GET to bypass the verification process easily.

• Some applications do not track used tokens. Instead, they copy the request parameters associated with each token into the user's cookie. A CSRF attack can be carried out by an attacker by creating a cookie that contains a token in the desired format and inserting it into the user's browser. The user's browser sends a request validated by the malicious cookie, thereby bypassing security.

How to Perform Code Testing To Determine CSRF?

Testing for CSRF vulnerabilities can be performed using both manual techniques and automated tools. The key code testing steps to detect CSRF vulnerabilities are as follows:

• Identify sensitive actions. Look for forms or actions in the web application that change the state, such as submitting data, transferring funds, or changing account settings. These are potential targets for CSRF attacks.

• Employ tools like OWASP ZAP or commercial products to simulate CSRF attacks. Intercepting requests and modifying the origin or parameters to see if the server accepts them without proper validation is included in this step. These tools can scan the application for CSRF vulnerabilities and can crawl the application and identify requests that lack CSRF protection.

• Verify if the application uses anti-CSRF tokens in forms. These tokens should be unique and validated on the server side. If they are missing, the application is likely vulnerable.

• Inspect cookie settings. Ensure that session cookies are set with the SameSite attribute. This restricts how cookies are sent with cross-origin requests.

• Manually test by creating a simple HTML form that submits a request to the target application. Host this form on a different domain and see if it successfully executes the action without additional checks.

How to Perform Code Review To Determine CSRF?

Code review is crucial for detecting possible Cross-Site Request Forgery (CSRF) vulnerabilities in web applications. The main procedures for code review to detect CSRF vulnerabilities are as follows:

• Examine session management. Check how the application manages user sessions. If it relies solely on cookies for authentication, it may be vulnerable to CSRF. Ensure that session management includes server-side validation.

• Review the code for the implementation of anti-CSRF tokens. Ensure that these tokens are generated for each user session and included in every state-changing request. Verify that the server validates these tokens correctly.

• Check form submissions. Analyze forms to ensure that they include CSRF tokens. If forms do not have tokens or if the tokens are predictable, this is a vulnerability.

• Review HTTP headers. Check if the application validates the Origin and Referer headers in incoming requests. This makes sure that requests come from trusted sources.

• Employ static analysis tools that can identify CSRF vulnerabilities in the codebase. These tools can help automate the detection of common patterns that indicate CSRF risks.

• Refer to security guidelines for best practices in implementing CSRF protections.

How to Prevent CSRF Vulnerabilities?

To effectively prevent Cross-Site Request Forgery (CSRF) vulnerabilities, various strategies can be implemented. A comprehensive list of recommended practices for web applications is given below;

1. Use Anti-CSRF Tokens(Synchronizer Token Pattern): This method is widely adopted in many web frameworks. Apply the following methods when using Anti-CSRF tokens.

   • Generate a unique, unpredictable token for each user session or request. This token should be included in all state-changing requests (e.g., form submissions).

   • The server must verify that the token sent with the request matches the one stored in the user's session. If the token is missing or incorrect, the request should be rejected.

   • Use of anti-CSRF libraries. Many web frameworks and libraries offer built-in CSRF protection mechanisms. Developers should leverage these tools rather than implementing custom solutions.

2. Set SameSite Cookie Attribute: This adds a layer of protection against CSRF attacks.Apply the following methods when setting SameSite cookie:

   • Use the SameSite attribute for cookies to restrict how cookies are sent with cross-origin requests.

   • Set the SameSite attribute to Strict if possible; otherwise, use Lax.

   • Double-submit cookies. This technique involves sending a CSRF token in both a cookie and a request parameter. The server checks that both values match before processing the request.

3. Require Re-authentication for Sensitive Actions: For critical operations like fund transfers, and account changes, require users to re-enter their password. Forcing multi-factor authentication (MFA) methods like one-time passwords (OTPs) or CAPTCHAs is another safety method.

4. Implement Custom Request Headers: Use custom headers (e.g., X-CSRF-Token) in AJAX requests to transmit the CSRF token. Browsers typically do not allow these headers to be sent cross-origin, adding a layer of protection. This method is particularly useful for REST APIs.

5. Validate the HTTP Referer Header: Validate the Referer header to ensure requests are coming from trusted sources. However, this method can be bypassed and should not be solely relied upon.

6. Use Secure Coding Practices: Utilize built-in CSRF protection mechanisms provided by web frameworks like Django, Ruby on Rails, etc., to avoid common pitfalls in implementation. Ensure that token validation is not skipped based on the presence of the token alone, and that tokens are tied to specific user sessions.

7. Regular Security Audits and Inform Users: Perform regular scans and security audits of your web applications to identify and remediate potential CSRF vulnerabilities. This includes reviewing code changes that may inadvertently introduce weaknesses. Informing users about the risks of clicking on unknown links and the importance of logging out of sensitive applications.

How Users Protect Themselves Against CSRF Attack?

CSRF attacks mainly target actions that modify the application state like changing settings and transferring funds. It is less likely to retrieve data like viewing account balances. CSRF attacks are often combined with social engineering techniques to trick users into clicking malicious links or forms. There are several efficient techniques for CSRF attack mitigation as well as prevention. From the user's point of view, prevention is about protecting login information and keeping unauthorized actors out of applications. Best CSRF attack prevention practices for users are listed below:

• Shutting down or logging off online apps when not used

• Safeguarding passwords and usernames

• Preventing password memory in browsers

• Steer clear of browsing concurrently while logged into an application.

What are CSRF Preventive Measures that do not Work?

Over time, several flawed methods have been developed to defend against CSRF attacks. Avoid the following flawed and outdated ineffective measures and implement more robust CSRF prevention techniques to ensure security;

• Limiting applications to only accept POST requests for business logic execution is a misconception. Attackers can still construct malicious forms with hidden values on their websites. These forms can be automatically submitted via JavaScript or trick users into thinking they serve a different purpose. POST Only Requests will not be the solution to prevent CSRF vulnerabilities.

• All cookies are submitted with every request. The hidden cookies are not the exception. Authentication tokens are sent regardless of whether the request was legitimate or tricked. Session identifiers simply associate requests with session objects and do not verify the user's intent. So, hidden cookie utilization will not be effective.

• Another idea is to employ HTTPS connections. HTTPS alone does not protect against CSRF. However, it should be considered a prerequisite for preventive measures.

• It may seem useful to rewrite the URL since the attacker cannot guess the session ID. The reality is not exactly this. URL rewriting exposes the session ID in the URL. This practice introduces another security vulnerability and is not recommended.

• Validating the Referrer Header is another ineffective approach. Attackers can easily spoof the referrer header when cyber security personnel employ this method. Privacy settings or policies may prevent the header from being sent, leading to false positives. Additionally, legitimate requests might lack a referrer header, resulting in mistaken CSRF attack flags.

• One last approach is to utilize multi-step transactions. Multi-step transactions do not adequately prevent CSRF. If an attacker can predict or deduce each step of the transaction, CSRF attacks remain possible.

What are Examples of CSRF Attacks?

In 2001, reports of the first CSRF vulnerabilities emerged. Because CSRF is executed from the attacker's IP address, website logs frequently contain no forensic proof of the attack. There are a few CSRF cases that are recorded, but the actual number of attacks is far higher. Here are some real-world examples of CSRF attacks;

• TikTok: In 2020, a vulnerability was discovered in TikTok that allowed attackers to send malware-containing messages to TikTok users. After deploying the malware, attackers could perform CSRF or cross-site scripting (XSS) attacks to cause other user accounts to submit requests to the TikTok application on their behalf.

• McAfee Network Security Manager: Researchers discovered a CSRF vulnerability in the User Management module of McAfee Network Security Manager in 2014. Malicious people were able to change other users' accounts owing to the attack. The vulnerability was patched in a later version.

• YouTube: In 2008, Princeton researchers found a CSRF vulnerability on YouTube that allowed attackers to perform nearly all actions on behalf of any user, including adding videos to favorites, modifying friend/family lists, sending messages to contacts, and flagging inappropriate content.

• ING Direct: ING Direct, a Dutch banking group, had a CSRF vulnerability in 2008 that allowed attackers to transfer money from users' accounts, even though users were authenticated with SSL. The website lacked any protection against CSRF attacks, and the process of transferring funds was easy for attackers to see and replicate.

How to Create a CSRF Attack?

A successful CSRF attack requires the following conditions to be satisfied;

• Cookies alone must be the basis for authentication. The application only uses cookies to authenticate the user, and one or more HTTP requests are required to initiate the attack.

• Every request parameter needs to be predictable. The requests include parameters, the values of which the attacker can estimate or deduce.

• For an attacker, the target application needs to have crucial or intriguing features. There are several scenarios that could occur: features associated with elevated privileges, activities affecting user-specified data, etc.

To understand how CSRF attacks are created, think of a customer who has an online banking account at a bank where he regularly conducts transactions with another person from his finance department. The customer is unaware that the bank web page is vulnerable to CSRF attacks. An attacker wants to transfer ten thousand dollars from his account by exploiting this vulnerability. To execute this attack, the attacker must create an exploit URL, trick the customer into clicking the exploit URL, and the customer must have an active session with the bank web page.

Assuming the online banking application uses the GET method for transfer requests, customers' legitimate request to transfer $10000 to a legitimate account might look like this:

GET https://bank.com/transactions/transfer?amount=10000&accountNumber=real_account HTTP

To meet the first requirement for a CSRF attack, the attacker crafts a malicious URL to transfer the money:

https://bank.com/transactions/transfer?amount=10000&accountNumber=attacker_account

Using various social engineering techniques, the attacker tricks customers into loading the malicious URL. This can be done in several ways, such as embedding malicious HTML image elements in forms, placing the URL on pages frequently accessed by logged-in users, or sending it via email.

Here is an example of a disguised URL:

<img src="https://banka.com/transactions/transfer?amount=10000&accountNumber=attacker_account" width="" height="">

In a scenario where this image tag is included in an email sent to a bank customer when a customer opens the email, his browser automatically loads the URL without his intervention. A malicious request is sent to the online banking application. If a customer is logged into the bank web page, the application treats this as an authorized transfer request from the customer and transfers the money to the attacker’s specified account.

In another approach, the hyperlink can be distributed via email to a vast number of clients. If one of them clicks on the link while logged into their bank account will unintentionally make the transfer. If the bank’s web page is employing POST-only requests, the attack could be achieved in a <form> tag with automatic execution of the embedded JavaScript. Here is an example;

<body onload="document.forms[0].submit()">

<form action="http://thebank.com/transfer.do" method="POST">

<input type="hidden" name="accaunt" value="fraudalent_person"/>

<input type="hidden" name="amount" value="amount_of_money"/>

<input type="submit" value="Check out my new video!"/>

</form>

</body>

How to Send a CSRF Exploit?

An attacker can craft and deliver a CSRF exploit, manipulating the target web application to perform unauthorized actions on behalf of the authenticated user with the following steps:

1. Find an action on the target web application that changes state (e.g., fund transfer, password change, posting content) and lacks proper CSRF protection. Online banking transfer forms or account settings updates are examples.

2. Create a request that will perform the desired action without requiring user confirmation or a CSRF token:

   <form action="https://example.com/transfer" method="POST" id="csrfForm">
   
   <input type="hidden" name="amount" value="1000">
   
   <input type="hidden" name="to_account" value="attacker_account">
   
   </form>
   
   <script>document.getElementById('csrfForm').submit();</script>

   Alternatively, using an image tag for GET requests:

   <img src="https://example.com/transfer?amount=1000&to_account=attacker_account" style="display:none;">

3. Embed the crafted request in an email, website, or social media post to ensure the victim triggers the action:

   <a href="#" onclick="document.getElementById('csrfForm').submit();">Click here for a surprise!</a>

   Or embed in an email:

   <img src="https://example.com/transfer?amount=1000&to_account=attacker_account" style="display:none;">

4. Use social engineering techniques to trick the victim into interacting with the malicious content. Methods include sending phishing emails, posting links on social media, or embedding content in a compromised website:

   <p>Hi, check out this amazing offer!</p>
   
   <a href="#" onclick="document.getElementById('csrfForm').submit();">Click here</a>
   
   <p>Hey. Check this funny picture out!</p>
   
   <a href="#" onclick="document.getElementById('csrfForm').submit();">Click here</a>

5. Once the victim interacts with the malicious content, the browser will send the crafted request to the server, executing the exploit. The victim clicks the link or image, and the hidden form submits the request to the target server. Or the server processes the request, believing it to be a legitimate action initiated by the authenticated user.

What are Common Defenses Against CSRF?

Security best practices and preventive measures for web applications are crucial for protecting against various threats like CSRF vulnerabilities. Implementing these measures ensures your application’s defenses are robust:

• Synchronizer Token Pattern (STP) is a common technique to prevent CSRF attacks. It involves including a unique, random token with each request made by the user. This token is stored on the server, ensuring the request is valid only if the token matches the server's token. The server generates a unique token linked to the user’s session. The token is included in forms, links, or JavaScript-generated requests requiring authentication. When the user submits a request, the token is sent along with it. The server checks if the token in the request matches the one stored in the user’s session. If they match, the request is valid; otherwise, it is rejected.

• Double submitting cookie pattern technique sets a cookie in the user's browser with a value matching a hidden form field. When a request is made, both the cookie and the form field are sent to the server, which compares the values to verify the request's authenticity. When the user submits a request, both the cookie and the form field are sent to the server. The values in the form field and the cookie are compared by the server. If they match, the request is valid.

• SameSite cookie attributes include Strict and Lax. Cookies are only transmitted in first-party (same-site) queries when using strict mode. In Lax mode, cookies are sent in cross-origin requests but only in safe navigation scenarios. GET requests are initiated by clicking links for instance.

• Origin-based validation validates the origin of incoming requests and accepts them only if they come from an expected and trusted source. This is done by comparing the request’s origin header with a list of trusted origins.

• Implement strong user authentication mechanisms requiring unique credentials for each user. Employ strong hashing algorithms to store passwords and make password complexity mandatory. Multi-factor authentication (MFA) adds an extra layer of security for sensitive accounts. Roles are assigned according to responsibilities along with access needs via Role-Based Access Control (RBAC). This makes sure users only interact with features and data relevant to their roles. The least privilege principle makes sure users and processes have only the minimum access necessary. Regularly review and audit permissions.

• Configure security headers like ‘Content Security Policy’ (CSP) and ‘X-Frame-Options’ to provide additional protection against various web vulnerabilities, including CSRF.

• Thoroughly validate and sanitize all user inputs to prevent injection attacks like SQL injection and Cross-Site Scripting (XSS). Always encode dynamic data when rendering web pages to prevent XSS attacks.

• Implement strong session handling practices, including generating random and secure session IDs, regenerating IDs upon authentication, setting session timeouts, and associating sessions with IP addresses or user agents to detect session hijacking attempts.

• Keep all components of your application, including libraries, frameworks, and server software, updated with the latest security patches and updates. Monitor security advisories and act promptly to address known vulnerabilities. Use automated vulnerability scanning tools to detect common security issues like CSRF or XSS vulnerabilities. Examine and keep an eye on the security of any third-party plugins, libraries, and services that your application uses.

• Use rate limiting to guard against resource abuse and stop brute-force attacks on your application. To prevent unwanted access to private functions or data, use access controls. Educate end-users about the risks of CSRF attacks and encourage cautious behavior when clicking on links or performing actions on websites, especially when authenticated. Advise users to log out of sensitive accounts when not in use.

What are CSRF Related Attacks?

Cross-Site Request Forgery attacks are a web security threat, but they can be used in conjunction with other vulnerabilities to create more complex attacks. Here's how CSRF relates to Cross-Site Scripting (XSS) and Cross-Site History Manipulation (XSHM);

• CSRF with XSS(Cross-Site Scripting): This combines two vulnerabilities, CSRF and XSS. Here's how it works basically:

  • An attacker injects a malicious script (XSS) into a website (Website A).

  • Victim visits Website A.

  • The malicious script executes in the victim's browser.

  • The script exploits a CSRF vulnerability in another website (Website B) where the victim is logged in.

  • The script initiates an unintended action on Website B using the victim's authenticated session, potentially stealing data or changing settings.

• CSRF and XSHM (Cross-Site History Manipulation): XSHM vulnerability allows attackers to manipulate the victim's browser history. It may redirect them to malicious websites. While XSHM isn't directly used in CSRF attacks, it could be used as part of a social engineering scheme to trick the victim into clicking a malicious link that initiates a CSRF attack. In summary;

CSRF attacks rely on social engineering to get the victim to interact with a malicious element. XSS injects malicious scripts that can be used to launch CSRF attacks or perform other malicious actions. XSHM doesn't directly cause CSRF attacks but can be used in social engineering tactics leading to them.

What is the Difference between CSRF and RCE?

Cross-Site Request Forgery (CSRF) and Remote Code Execution (RCE) are two distinct types of web security vulnerabilities. Each has different mechanisms, impacts, and exploitation methods. They target different things and have different consequences. CSRF attacks deceive users to do undesired actions on a web application on which they have been authenticated. They exploit the trust that the application has in the user's browser. In contrast, RCE is a vulnerability that allows an attacker to execute arbitrary commands on a target system. It often leads to complete control over the affected machine or application. The mechanism of the attack, the impact, and the exploitation techniques are aspects of analyzing the differences between CSRF attacks and RCE attacks. Here's a some details of the key differences;

CSRF' focus is to exploit a user's existing session to trick their browser into performing unintended actions on a trusted website. However, giving the attacker the ability to execute arbitrary code on the victim's server is the main goal of RCE. While the CSRF attacker's goal is to modify the victim's data (e.g., transfer money, change password) and to perform actions within the victim's account, the RCE attacker wants to seize total control of the system, install malware, and/or steal confidential information. A CSRF attack example is, an attacker tricks a bank customer into clicking a link that unknowingly transfers money out of their account. As an RCE attack illustration, suppose an attacker discovers a weakness in the content management system (CMS) of a website. This website enables them to upload malicious code. The entire system may potentially be compromised if this code is run on the server.

The following table highlights the key differences between CSRF and RCE attacks;

Feature	CSRF	RCE
Scope of Impact	Limited to user's permissions	Potentially full control of the system
User Involvement	Requires user interaction (social engineering)	No user interaction required
Nature of Attack	Targets web applications, uses user session	Targets any system with a vulnerability, executes code remotely
Prevention Techniques	Verifies request legitimacy, protects sessions	Secures software, prevents code execution
Focus	Exploiting existing session	Executing arbitrary code on server
Attacker's Goal	Modify victim's data or perform actions	Steal data, install malware, take control
Attacker Needs Credentials	No	May be required (depends on vulnerability)

Table 1. Key differences between CSRF and RCE attacks