Cross-Site Request Forgery (CSRF) is an attack aimed at vulnerability in computer security, which is one of the biggest problems for user information and accounts because it all makes so that the web browser performs undesirable actions in the application and thereby harms the user who has already logged in to the system. A successful attack can result in unauthorized money transfers, data theft, change of passwords, and damage to customer relations.

Cross-site scripting (XSS) is a Web security vulnerability through which an attacker separates Web sites, thereby jeopardizing user interaction with the application. But to avoid being seen by the attacker, one should avoid the same policies of origin.

Work Algorithm of CSRF and XSS

Cross-Site Request Forgery (CSRF)

CSRF attacks often use social engineering to make a successful attack. Unfortunately, the app cannot distinguish between a legitimate request and a fake one, as the user is already authenticated during the attack. For the attack to be successful, the attacker uses three main keys, which we present below:

Cross-site scripting (XSS)

To make this attack, the attacker uses two stages:

What is the Difference Between XSS and CSRF?

If we already know the meaning and how XSS and CSRF work, then let’s consider the difference between them:

1. XSS – allows an attacker to perform any actions in the user’s browser he wants to attack. CSRF – in this case, the attacker takes all the ways to make the user himself perform actions that he did not intend to do.
2. XSS – a successful exploit of this vulnerability can do everything to ensure that the user performs any action, regardless of the vulnerability’s functionality. CSRF – often applies only to those actions that the user can perform.
3. XSS is a two-way vulnerability. This means that a script that an attacker has implemented can read answers, exfiltrate data into an external domain, and issue arbitrary queries. CSRF – but this vulnerability is called one-sided because the attacker can do everything to make the user execute the HTTP request, but he cannot get an answer to it.

Can CSRF tokens prevent XSS attacks?

If you use effective CSRF tokens, you can prevent XSS attacks.Assume that the server still validates the CSRF token correctly, in which case the token may prevent an XSS vulnerability. If we think carefully about the name “intersite scripting”, we can understand that it hides a hint that we can see the intersite query in the reflected form. The application prevents the trivial use of an XSS vulnerability, thereby preventing an attacker from faking an intersite request. Here are some important caveats:

1. The existence of an assumed mirrored, tokenless XSS vulnerability, somewhere within a function, can be used in the usual way.
2. If a CSRF token protects actions, they can still be performed by the user, with an XSS vulnerability somewhere there that could be exploited. In such a case, the attacker’s script may request the corresponding page to obtain a valid token. He can then use the token to perform any protected action.
3. If XSS vulnerabilities are already stored, CSRF tokens cannot protect them. You can only use the page that is the output point of the stored XSS vulnerability protected by the CSRF token. At the same time, the XSS payload will be performed when the user visits the page.

The post CSRF vs. XSS: What are Their Similarity and Differences 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.