Table of Contents [TOC]
- WordPress CSRF Protection
- CSRF Scanner
- WordPress CSRF protection: How to prevent CSRF attacks?
- Avoid CSRF Attack With Nounces
- Nonce Functions To Prevent CSRF
- Protecting WordPress custom forms from CSRF attack
- Navigate with care and caution
- Check the terminal for malware
- Protection against CSRF with HTTP request
- Two-factor authentication
- Reference header
- Log out at the end
- WordPress CSRF Plugins
- Conclusion – WordPress CSRF Exploit
In simple words, Cross-site request forgery (CSRF) is an attack that tricks a user’s web browser into performing an unwanted action on a trusted site when the user is already authenticated. By social engineering (such as sending a link via email or chat), an attacker may trick a wordpress site user into executing actions of the attacker’s choosing. This leads to stealing of financial information, sensitive information and is used for forgery. In this, WordPress CSRF Exploit GUIDE, you will learn more about CSRF exploit, vulnerability and WordPress CSRF Plugins you need to secure your website. You will also find various WordPress CSRF protection tips in this article which are easy to implement.
A recently patched XSS vulnerability would have allowed an attacker to take control of a WordPress site, via a CSRF attack, and user comments.
A high-severity CSRF vulnerability in the popular WordPress plugin Code Snippets leaves over 200,000 websites vulnerable to site takeover.
Researchers, have provided more details about a recently patched vulnerability that would have allowed an attacker to take over a WordPress site using something as simple as a maliciously crafted comment.
Discovered by RIPS Technologies, this CSRF (cross-site request forgery) vulnerability exists on any WordPress site using version 5.1 or earlier, with default settings and comments enabled.
The WordPress CSRF vulnerability can be exploited by an unauthenticated attacker who doesn’t need to be logged in. The CSRF exploit abuses multiple logic flaws and sanitization errors that when combined lead to Remote Code Execution and a full site takeover.
The problem at the heart of this flaw comes from the way in which WordPress protects itself (or not) against CSRF-type takeovers at the comment level.
CSRF attacks occur when an attacker hijacks an authenticated user session so that the malicious instructions appear to originate from that user’s browser.
In the case of this last flaw, the attacker only has to lure a WordPress administrator to a malicious website containing an XSS (Cross-Site Scripting) payload.
Websites defend themselves against a CSRF attack in different ways, but the complexity of the task means that attackers will always be able to find a workaround. You need to perform a WordPress CSRF check in order to find and diagnose the exploit. These online wordpress security scanner tools would come handy for sure.
According to the report:
WordPress does not perform any CSRF validation when a user posts a new comment. This is because some WordPress features, such as trackbacks and pingbacks, would then be broken in the event of validation.
This means that an attacker can create comments to administrator-type usernames at a WordPress blog level via CSRF attacks.
The full sequence is somewhat convoluted but, if truly launched, that would be bad news.
You might be feeling intimidated with the terms used, Lets get brush up first with some hacking terminology.
WordPress CSRF Attack (Cross-Site Request Forgery)?
Cross-site request forgery, often abbreviated as CSRF or XSRF, is a type of attack that occurs when a website, blog, email, instant message, or a malicious web application. It causes a user’s web browser to perform unwanted operations on a trusted site where the user is currently authenticated.
The impact of a CSRF attack depends on the information exposed in the vulnerable application.
At their most basic level, CSRF attacks are used to coerce a target system into performing malicious operations through the target browser, without the knowledge of the target user.
The CSRF-type vulnerability can provide an attacker with the ability to coerce an authenticated, logged-in user into performing an important operation without their knowledge or consent.
It’s the digital equivalent of a scammer forging a victim’s signature on an important document. But the CSRF attack turns out to be even more effective since the attacker leaves no trace behind.
The object of the CSRF attack is to force users to execute one or more unwanted requests on a given site, forged by a malicious user. The chosen victim will have the necessary privileges to execute the request and even a session that is still active.
Why? Because the illegitimate request contains all the information and comes from the same IP address as a legitimate request made by the victim. In other words, any application that allows a user to send or update data is a potential target for an attacker.
The bottom line is that for a CSRF attack to work, the victim must be logged into the targeted site.
If this aspect may seem to complicate the task of the attacker, it is not: many websites allow the user to “Stay logged in”. This considerably increases the time during which the diversion can take place.
- OWASP Cross-Site Request Forgery (CSRF)
- PortSwigger Web Security Academy
- Mozilla Web Security Cheat Sheet
- The Cross-Site Request Forgery FAQ
Impact Of CSRF Attack
CSRF attacks can be perpetrated on all kinds of sites. If a site allows the user to modify data, the site becomes a potential target for a hacker. Using the techniques presented above, your site can significantly improve its level of security.
When carried out successfully, a CSRF attack can have a wide variety of repercussions, depending on the privileges of the victim. If the target is a standard user, their entire account is likely to be compromised, from their personal information to their privileges on the site.
And that’s nothing compared to the impact of a CSRF attack on an administrator’s account: it could cripple the entire site. Given the magnitude of a possible CSRF attack, it is essential that any web security package can protect against it.
Possible malicious uses of CSRF
The most common objective of a CSRF attack is theft – of data, identity, or money. Here are some of the most common uses of CSRF:
- Transfer money from one bank account to another. On your bank’s website, your online session is compromised. As a result, the site treats your transfer request as legitimate and transfers $1,000 from your account to the attacker’s account. There is every reason to believe that you carried out this transaction yourself from your connected browser.
- Use a content management system to add/remove content on a website. If the victim is the administrator of a website, then the attacker takes control of the entire site.
- Change a user’s password. If the victim is logged into their account, the attacker can simply fake a request to change their email. After that, he can fake a password reset request and take full control of the victim’s account.
- Add items to a user’s cart or change the delivery address of an order. Many websites have a “My Account” type page, which stores user information. This page often allows the user to modify his address or the contents of his basket. In the case of a CSRF attack, the attacker can modify this information. On the website, the victim appears as the author of these modifications.
WordPress CSRF Vulnerability in Your Site
Cross Site Request Forgery (CSRF) vulnerabilities can occur when a user, malicious or not, performs an action without their knowledge on your site. WordPress has built and continues to create nonce solutions to help mitigate CSRF attacks.
Our CSRF example revolves around online banking, as this case is particularly well suited to see the scope of the attack technique.
On a website that has user subscriptions, members, or logins, each user has privileged access to their own account on the site.
For example, an Amazon account, a Gmail account, or even an online banking account.
They offer its users login credentials – usernames and passwords.
This is done to authenticate the user. So when a user wants to log in, all they have to do is enter their username and password.
In this way, the website can establish a relationship of trust with the user and browser.
A user logs into their online banking account. The page has a specific form to make transfers. If the user fills in the form and hits the confirmation button, a specific HTTP request is sent to the server and the transfer is made.
The attacker knows the exact structure of the form and the HTTP request and is able to recreate both. As information, the data of the scammer’s account and an amount determined by it are entered.
The hacker can then set a web page (or send an email) of interest to the example user. The user is prompted to click on a seemingly harmless link, but it is this action that triggers the spoofed HTTP request.
This request is sent to the bank and the bank performs the action desired by the hacker. The session is still logged in and the request is successful.
The server has no reason not to execute the action and therefore the money is transferred. The user does not realize anything until he checks his balance.
Other attack scenarios:
- Social Networks: Comments or “likes” are posted on behalf of the logged-in user.
- Website Management – If a victim accesses the backend, new users can be created or the entire webpage can be deleted without their knowledge.
- Online purchases: the attacker makes purchases on the user’s account without their realizing it.
Also Read –
WP Hacked Help flawlessly identifies missing anti-CSRF tokens, but also finds advanced variations of CSRF vulnerabilities by testing for them with highly tuned heuristics. Additionally, WP Hacked Help scanner perform an initial scan for the often overlooked problems of Cross-site Scripting and SQL Injection, and will continue to work hard to find additional application level issues that the developer may have missed.
When scanning wordpress sites for CSRF vulnerability, it may be desirable to divide the scanning up into segments, or scopes. One example of this would be when different teams would be working on different parts of a large web application with different release cycles, and therefore different scanning schedules.
Here is an another CSRF Scanner you can try.
Also See – HUGE LIST OF 60 Online WordPress Security Scanner Tools To Scan For Vulnerabilities
WordPress CSRF protection: How to prevent CSRF attacks?
WordPress websites are vulnerable to CSRF attacks because plugins have security vulnerabilities that allow them to happen.
Many popular plugins had security issues that made websites vulnerable to CSRF attacks.
To prevent CSRF attack, plugin developers must implement certain measures to increase wordpress security.
Let’s briefly understand these measures and then explain prevention steps you as a WordPress site owner can do to stop CSRF attacks.
Avoid CSRF Attack With Nounces
The CSRF attacks can be avoided if we use some handy functionality built into WordPress. To prevent a request from being successfully “forged”, WordPress uses nonces (numbers used once) to validate the request was actually made by the current user.
To prevent code from being inserted into your site and making changes, you need to use CSRF nonces. And you do that by adding a random tag generated by WordPress to your forms. You don’t want hackers messing with your site, so you need to use nonces.
- A nonce is generated.
- That nonce is submitted with the form.
- On the back end, the nonce is checked for validity. If valid, the action continues. If invalid, everything halts – the request was probably forged!
Nonce Functions To Prevent CSRF
WordPress is full of convenience functions to make generating nonces (and preventing CSRF) easier. Here are a few you might find useful for different situations:
This Validates that the nonce value was legitimately generated by WordPress.
This Prints a hidden
<input> tag containing a nonce value.
Used when you’re building a
<form> that needs to be protected from CSRF (which is pretty much every
This Returns a URL with a nonce value attached.
Used when you’re building a URL that needs a nonce field appended as a query string parameter. Most useful when doing GET requests that need CSRF validation.
This Generates a nonce value.
Used when you need a nonce value that doesn’t fit one of the above convenience functions.
This Checks for a submitted nonce using
wp_verify_nonce, and if the validation fails, stops execution.
Protecting WordPress custom forms from CSRF attack
If you want to customize your site beyond what the form plugins can offer, you can create your own forms—for example via an [htmlinsert custom shortcode html here]. This can be a login form, a contact form, or even something more complex that allows users to enter their account details or make orders on your site.
A simple form without any CSRF protection, could be easily exploited by an attacker to trigger a POST request on a third-party malicious site to your site that changes your email to the attacker’s email. Fortunately, this is a pretty easy fix. One method is to add a WordPress nonce to your form, and then, on every page load, verify that the nonce has not been changed.
Add this line at the top of your form:
<form id="test-form" method="POST"> <input name="form_nonce" type="hidden" value="<?=wp_create_nonce('test-nonce')?>" /> ....
As a user, the watchword is a precaution, above all. If you do not browse pages of doubtful reliability or open suspicious emails, it is very difficult for you to become a victim of an attack of this type.
To protect yourself from CSRF you should also always log out of security-relevant portals before accessing any web page whose origin is unknown.
Check the terminal for malware
As a user, you must also make sure that your device (computer, laptop, smartphone, etc.) is free of malicious software.
If an app is running in the background and spying on you as a user, it is very difficult to bypass CSRF. Once the device or account is infected, it can be the victim of multiple other attacks.
Protection against CSRF with HTTP request
Website operators can also protect users. Attackers can only carry out cross-site request forgery attacks because they know the exact structure of the corresponding forms and HTTP requests.
If a random factor is introduced into the equation, the hacker is often out of the game. The web page can create a unique token (similar to a random sequence of characters) and make it part of the HTTP request.
Thus, if the server receives a request without a token or with a token that is (already) invalid, the request is automatically rejected.
As a general rule, electronic banking has a two-factor authentication; Before the user can make a transfer, they must enter a TAN code that cannot be provided through the website.
This technique not only serves as protection against CSRF but also against other attacks.
Even if the attacker manages to get hold of the access data, he would not be able to carry out the transfer until he had the second factor.
In theory, the referrer header already works as a protective element. This part of the HTTP request indicates where the request came from.
Thus, web pages can filter all external origins. However, the referrer header has proven to be highly unreliable over the past few years.
Any browser extensions, such as ad blockers, modify or remove the referrer header. In this case, users with such a configuration would no longer be able to use the offer on the website.
Log out at the end
One measure that may not offer definitive protection, but at least poses an obstacle for criminals, is not keeping unlimited sessions.
In this matter, the operators weigh the comfort of the users and the risk. Bank portals, for example, often log out after only a few minutes without user action.
On the other hand, other web pages (such as, for example, most social networks), which manage less sensitive data, can leave sessions open for several days.
As long as a user is not logged into the portal, any CSRF attack has no effect.
CSRF protection plugins gives you such protection and features to secure your wordpress sitre against number of attacks. Once you install any of these WordPress plugin, it will enable you to get rid of any CSRF attack. It will also get rid of WordPress malware a hacker might’ve added to your site during the hack.
Comments posted to your site without the commenter realizing it are being posted under the commenter\’s own credentials, thanks to this plugin. Secure tokens are added to your comment forms and validated before accepting comments, ensuring that form security is no longer an issue. This plugin adds a secure token to the comment form and validates it before accepting any comment. This makes your comment forms more secure than they were before!
The CSRF vulnerability is among the most famous web vulnerabilities. Many WordPress plugins—including popular ones, such as many plugins hosted in this repository—are vulnerable to it. To avoid getting hacked because of this, just install this plugin; there are no settings or technical skills required.
This plugin allows you to easily add HTTP headers to outbound HTTP responses in your site. In short, this plugin allows you to add below mentioned additional HTTP headers to any outbound HTTP response.
WP-Sentinel, is a plugin for the WordPress platform which will increase the security of your wordpress site against attacks
This plugin is able to block those kind of attacks :
- WordPress Cross Site Scriptings
- HTML Spam Injections
- Remote File Inclusions
- Remote Command Executions
- Local File Inclusions
- SQL Injections
- Integer & string overflows
- Cross Site Request Forgery
- Login bruteforcing
WP CSRF Protector is a plugin designed to protect the WordPress admin panel from Cross-Site Request Forgery (CSRF) attacks. The default CSRF protection in WordPress requires developers to call a method to attach a nonce to the HTML output, so if a developer (intentionally or unintentionally) leaves that part out, your admin panel is vulnerable to CSRF.
How to install
- Clone this repo
- Compress the directory
- Go to wordpress admin panel > plugins > add new > upload
- Upload this zipped file
CSRF (Cross-Site Request Forgery) flaw: WordPress 5.1.1 fixes a serious XSS vulnerability
A recently patched XSS vulnerability would have allowed an attacker to take control of a WordPress site, via a CSRF attack, and user comments.
The solution is to update WordPress to version 5.1.1, released on March 12 with a fix for this flaw. If automatic updating is not enabled, this is still the usual path: visit Dashboard > Updates and click Update.
A more extreme solution would be to completely disable comments while remembering to log out of the WordPress admin before visiting other websites.
Conclusion – WordPress CSRF Exploit
Regardless of business scale, WordPress users who use the WordPress malware scanners benefit significantly from maintaining online accounts and growing online businesses.
WordPress admins who rely only on default site settings to protect private information may experience more potential data threats that are dangerous to business operations.
For this reason, increased user attention to site settings, website plugins, and security protocols ensure that WordPress Websites perform their essential functions while securing private information.
If you need to fix CSRF (Cross-Site Request Forgery) flaw then use the WordPress malware scanners that automatically protect your website from CSRF attacks. It can also help you with thousands of other cyber threats, including those listed in the WP Hacked Help WordPress Hacking & Prevention Guide2022.
Questions about cross-site request forgery? Contact WP Hacked Help team now.