Cross-Site Request Forgery (CSRF) is an attack targeting vulnerabilities in computer security, posing significant risks to user information and accounts. It manipulates the web browser to perform unwanted actions within an application, harming the user logged into the system. A successful attack can lead to unauthorized money transfers, data theft, password changes, and damage to customer relations.

Cross-Site Scripting

Cross-site scripting (XSS) is a Web security vulnerability that allows an attacker to compromise user interactions with an application by exploiting separate web sites. To avoid detection by the attacker, one should not rely solely on the same-origin policy.

Work Algorithm of CSRF

The CSRF (Cross-Site Request Forgery) attack exploits the trust that a web application has in a user’s browser. The aim is to deceive the browser into executing unwanted actions on a website where the user is currently authenticated. This section will break down how CSRF attacks are typically carried out in a step-by-step algorithm.

Step 1: Identifying the Target Application

The attacker first identifies a target web application that is vulnerable to CSRF. This typically involves an application that handles user requests without sufficient validation of their origin or authenticity.

Step 2: Crafting the Malicious Request

Once a vulnerable target is identified, the attacker crafts a malicious request that can perform an unwanted action on the application. This could be anything from changing user settings, transferring funds, posting data, or any action that the user is authorized to perform on the application. The request is designed to look like a legitimate request from the authenticated user.

Step 3: Delivering the Malicious Request

The crafted request is embedded in a place where the victim is likely to trigger it. Common methods include:

• Embedding the request in an image or script on a web page that the user is likely to visit.
• Sending the malicious link via email or social media where the user might click on it unknowingly.

Step 4: Executing the Request

When the user interacts with the malicious content (e.g., by visiting a malicious website, clicking on a deceptive link, or loading a compromised image), the malicious request is sent to the target application. Since the browser automatically includes credentials like session cookies with every request to the site, the application might process the request as legitimate.

Step 5: Action Performed

If the attack is successful, the application performs the action without the user’s conscious approval. The action is executed under the guise of the user’s authenticated session, leading to potentially damaging outcomes depending on what the malicious request was designed to do.

Step 6: Attack Detection and Response

Detection of CSRF attacks can be challenging as they originate from the trusted user’s authenticated environment. However, preventive measures such as implementing CSRF tokens, same-site cookies, or double submit cookies can effectively mitigate such attacks.

Cross-Site Request Forgery (CSRF)

CSRF attacks often rely on social engineering to succeed. The app cannot differentiate between legitimate requests and fraudulent ones since the user remains authenticated during the attack. For the attack to succeed, the attacker leverages three main keys, which we detail below:

• Relevant action: Any action that involves user data.
• Cookie-based session handling: This key involves sending one or more HTTP requests where the application identifies the user solely through cookies.
• No unpredictable request parameters: To prevent an attacker from discovering or guessing the value of a query, the query includes no parameters.

CSRF Example

Imagine a popular online forum where users can update their profile information, including their bio. The form to update the bio might look like this in normal use:

POST /updateProfile HTTP/1.1
Host: community-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Cookie: session=3e5e4f3a8
bio=I+love+networking+and+cybersecurity!


This action is vulnerable to CSRF for several reasons:

• The action of updating a bio doesn’t require any secondary validation, making it a prime target for attackers looking to alter user data subtly.
• The application relies solely on session cookies to authenticate requests, with no CSRF tokens or other anti-CSRF mechanisms in place.
• Form data for this action is simple and predictable, allowing an attacker to easily forge a request.

An attacker could exploit this vulnerability by crafting a malicious webpage that includes an auto-submitting form, as follows:

<form action="https://community-sample-website.com/updateProfile" method="POST">
<input type="hidden" name="bio" value="Hacked by evil-user!" />
<input type="submit" value="Update" />
</form>
<script>
document.forms[0].submit();
</script>


Here’s what happens when a victim, who is logged into the forum, visits this malicious webpage:

1. The hidden form on the attacker’s page automatically submits a POST request to the forum’s server.
2. Since the victim is logged in, their browser includes their session cookie automatically with the request.
3. The forum processes the request as if it were a legitimate action initiated by the victim, thus changing the victim’s bio to “Hacked by evil-user!” without their consent.

This example highlights the importance of employing CSRF tokens or other verification methods that verify the user’s intent on sensitive actions within web applications. Without these protective measures, users are at risk of having their data altered or hijacked by attackers.

Cross-site scripting (XSS)

To execute this attack, the attacker proceeds in two stages:

• The attacker first looks for a way to insert malicious code into the web page that the user visits, before launching the malicious code into the victim’s browser.
• If the attacker targets a specific victim with malicious code, he does it through phishing or social engineering. Once he embeds the malicious code in the web browser, the victim must visit this infected website.

What is the Difference Between XSS and CSRF?

Now that we understand what XSS and CSRF entail and how they operate, let’s explore the differences between them:

Can CSRF tokens prevent XSS attacks?

Effective CSRF tokens can prevent XSS attacks. Assuming the server still validates the CSRF token correctly, the token can block an XSS vulnerability. Considering the term “intersite scripting”, we notice a hint that the intersite query can appear in reflected form. The application blocks the trivial use of an XSS vulnerability, thereby preventing an attacker from faking an intersite request. However, there are important caveats:

1. There may still be an exposed, tokenless XSS vulnerability within a function that can be exploited in the usual way.
2. Actions protected by a CSRF token can still be executed by the user, but if there is an XSS vulnerability elsewhere, it could be exploited. In such cases, an attacker’s script may request the corresponding page to obtain a valid token, which he can then use to perform any protected action.
3. If XSS vulnerabilities are already present, CSRF tokens cannot protect them. You can only use pages that are output points for the stored XSS vulnerability, protected by the CSRF token. When the user visits the page, the XSS payload will execute.

The post CSRF (Cross-Site Request Forgery) vs XSS appeared first on Gridinsoft Blog.

Unfortunately, the picture turned out to be depressing, for example, it turned out that 29% of critical errors in WordPress plugins did not receive patches at all. In addition, the number of reported vulnerabilities has increased by 150% over the past year.

The researchers write that all this is alarming, since WordPress is the most popular CMS in the world, which is used by 43.2% of all sites in the world.

Of all the bugs that experts reported in 2021, only 0.58% were related to the WordPress core, and the rest were related to different themes and plugins for the platform from different developers. At the same time, 91.38% of vulnerabilities were found in free plugins, while paid solutions for WordPress accounted for only 8.62% of the total number of problems, and this says a lot about the procedures for checking and testing code.

Patchstack experts have identified five critical vulnerabilities affecting 55 WordPress themes, with the most serious of these vulnerabilities related to file upload abuse.

As for plugins, 35 critical vulnerabilities were found in them, two of which affected 4,000,000 sites. Although plugin developers mostly fixed these vulnerabilities, nine plugins never received patches and were eventually removed from marketplaces altogether.

PatchStack also notes that XSS vulnerabilities top the list of the most common flaws in WordPress in 2021, followed by “mixed” vulnerabilities, CSRF, SQL injection and arbitrary file uploads.

Overall, in 2021, about 42% of WordPress sites, on average, contained at least one vulnerable component out of 18 installed. Although this number is less than the 23 plugins installed on average on websites in 2020, the problem is now complicated by the fact that 6 out of 18 are already out of date.

The most vulnerable outdated plugins in 2021 are OptinMonster, PublishPress Capabilities, Booster for WooCommerce, and Image Hover Effects Ultimate.

Let me remind you that we also wrote that Hackers create scam e-commerce sites over hacked WordPress sites, and also that KashmirBlack botnet is behind attacks on popular CMS including WordPress, Joomla and Drupal.

The post About 30% of critical vulnerabilities in WordPress plugins remain unpatched appeared first on Gridinsoft Blog.