What is XSS and can it be dangerous for my wordpress website?
This article was written as part of the university course Venture Design. In this course, we deal with the small start-up and their platform in a team of 4 people. Customers can find foodtrucks near them and choose a pickup time and pre-order. The food truck can better schedule goods and the cash payments are eliminated, that is saving a lot of time. The customer has no longer to endure annoying waiting times and can easily pick up his goods.
But back to the original topic. We were dealing with security and I was dealing with the issue of cross-site scripting (called XSS). As a basic technique, the start-up uses Wordpress, so I wanted to find out what XSS is and if it is dangerous for the start-ups Wordpress website. In the following article, I will explain Cross-Site-Scripting, show some known cases, and find out if the site of the start-up or other Wordpress sites is at risk from Cross-Site-Scripting.
XSS is part of the OWASP Top-10, meaning it’s recognized as a common vulnerability. Currently, Cross-Site-scripting is in 7th place of the most frequently recognized vulnerabilities.
What is Cross-Site-Scripting?
Cross-site-Scripting, usually referred to as XSS, occurs when people execute JavaScript in the victim’s browser, which can be malicious. With Javascript, the attacker is able to do significant damage. Unlike the server-side language like PHP, Javascript code inside the browser cannot affect the website for other visitors. Although Javascript is client-side and does not run on the server, Javascript can communicate with the server and execute requests. These requests, which may add unwanted content or in the worst case take down the website, are executed by such attacks.
Cross-Site-Scripting can be used for variant things by the attacker. The hacker could impersonate or pretend to be the victim’s user. He can do many things that the normal user can do, i.e. perform the user’s actions, read his data, access the data. He can also read the user’s credentials. It becomes dangerous for the website because he can inject Trojans into the website.
There are different ways of using Cross-Site-Scripting. Let’s dive a little deeper now and take a closer look at each type. (Only the most common XSS types are listed)
Stored XSS (also known as persistent or second-order XSS): The attacker can trick the website to store the XSS. This is done, for example, by posting a comment or chat message on Twitch. The message is then sent to every new user who accesses the page. This method needs an initial action from the hacker and can attack many users afterward. It is the most dangerous and widely used type of Cross-Site-Scripting. A Stored Cross-Site-Scripting Attack is shown in the following graphic. In this case, the stored XSS will steal the user’s cookies.
Reflected XSS: On some websites, links can be created and be shared afterward. For example, via a Google search or a contact form. Attackers then usually send their victims custom links that redirect users to another page. From this page, further actions can be performed. Such as malware behind a link, so that the attackers gain control over the victim’s device. The following graphic also shows that the attacker has placed a manipulated link on the website or sent it to the user, which gives the attacker access to the user’s private data.
DOM-based XSS: DOM-based cross-site scripting attacks occur when the JavaScript on the page is vulnerable to XSS instead of the server itself. Thus, Javascript itself reads out the attack, unlike reflected XSS, the server did not directly trigger the problem. In the following graphic the DOM-Based XSS is graphically illustrated.
Where do you need security features to avoid XSS?
Most Cross-Site-Scripting attacks are carried out through input fields. These should be secured. Generally, the vulnerabilities are mostly found through search. Often the weak point is search fields, comment functions, or similar things.
Known cases
There are many different cases of Cross-Site-Scripting. I will now list a few examples.
From Myspace and Facebook to Paypal. Many companies have had problems with Cross-Site-Scripting attacks. In 2002, there was a Cross-Site-Scripting attack that caused a million users to add a single user as a friend within 20 hours. This seemed harmless, however, MySpace had to take the site offline because of this attack. (MySpace Article)
In 2013, PayPal was also vulnerable to XSS. It was possible to create a link that would make a payment if you clicked on it without any further interaction. (Paypal Article)
In 2019, Fortnite was hit by an attack that resulted in a data breach. The problem was an unsecured website with a cross-site scripting vulnerability that allowed attackers to gain unlimited access to 200 million users’ data. (Fornite Article) The following graphic shows the attack on the Fornite accounts.
These were just a few examples of many Cross-Site-Scripting attacks. Companies like Facebook, Tumblr, and Steam pay for finding XSS vulnerabilities. In 2020, Facebook paid $20,000 to find an XSS vulnerability. So there doesn’t have to be a bad intention behind dealing with XSS or trying to find security holes.
Are wordpress pages protected from XSS?
There are many Wordpress sites on the Internet. Almost every 3rd page is powered by Wordpress. Therefore, it is important to ask yourself if Wordpress sites are protected against Cross-Site-Scripting attacks. To answer the question briefly: Wordpress pages are not principally protected against Cross-Site-Scripting attacks.
I have selected some Wordpress pages for testing, which I will not link here. (Because of you, you little evil hacker!).
The security holes were mostly in input fields like search or comment functions. I mostly tested the gaps by inserting simple javascript code.
Mostly: <script>alert(‘hello’)</script>. This will output an alert box and it is likely that there are security holes then. These pages were not small unvisited websites, some of them were websites that hundreds of users visit every day.
How to avoid XSS?
Hackers use many different methods to find out vulnerabilities on your website. Unfortunately, there is no single strategy to minimize the risk of an attack. If the user input is properly sanitized, Cross-Site-Scripting attacks are almost impossible. There are several ways to protect your website from Cross-Site-Scripting attacks.
Don’t trust any user input
Restricting input data is a very important point to avoid Cross-Site-Scripting. The user input that is received should be filtered as strictly as possible and an allowlist should be created to block unwanted input. One possibility is a dropdown menu, where an attack via Restricting input data is a very important point to avoid Cross-Site-Scripting is almost impossible. If custom input is required, then the rules mentioned above should be included.
Sanitize Values
If the content is used by the user for a page, make sure that it does not become HTML content by replacing unsafe characters with appropriate entities. Entities have the same structure as a normal character but are not usable for generating HTML. Use trusted and verified libraries to sanitize values like HTML. There you could use SantizeHelper for Ruby on Rails.
Set the HttpOnly flag
With the HttpOnly flag, it is hard for attackers to steal the sessions.
The HttpOnly flag is set for cookies, thereby the Restricting input data is a very important point to avoid Cross-Site-Scripting vulnerability is mitigated and such cookies are no longer accessible via client-side JavaScript.
Update system and plugins
Especially with Wordpress, it is extremely important that the themes and plugins are constantly updated. Major updates to wordpress are of tremendous importance. For self-written plugins, the linkability to renewed versions to Wordpress should be given, otherwise, new security vulnerabilities could arise.
Web application firewall
Use a web application firewall to virtually intercept attacks against the website. This can intercept attacks such as XSS, SQLi, and RCE. A web application firewall also protects against large-scale attacks such as DDOS.
What should be started with?
In order to provide your website with the greatest protection, all of the above measures should be implemented. But which solutions bring the most promising advantage?
The biggest factor that played a role in my testing was the blind trust in user input. In 6 out of 10 Wordpress pages, no checks were made on input fields. On 3 out of 10 sites I was able to apply XSS, probably because of an old version of the theme or wordpress. The experience I had during testing was confirmed when searching for the best methods to avoid XSS. Almost every website on this topic talks about the urgency of validating user input fields.
According to wpscan.org, 11% of vulnerabilities come from themes, while 37% of vulnerabilities come from WordPress core development. The remaining 52% come from plugins. Thus, the constant updating of plugins and themes is very important, because this gives the chance to reduce the 63% vulnerability.
So what should be done on a typical wordpress site to validate the input fields? Validation is about making sure that a value matches your expectation. Typically, you allow the user to resubmit the request if the validation fails.
The first option for validation is the PHP filter_var; function. This often looks like filter_var ($ _GET [‘email’], FILTER_VALIDATE_EMAIL). These functions even work outside of wordpress. You can look up all validation filters on PHP.net. If the function outputs an error, it is clear that the data is invalid.
Here are some examples of frequently used functions for validation:
- isset()/empty(): check if the variable exists or not.
- is_email(): check if the given data is in email format or not.
- is_serialized(): check if the value is a string or not.
There are also specific wordpress functions to prevent XSS attacks. But these are more on the topic of sanitizing the data. However, some of them are well useful for validation. An example is is_email this does the same as the filter_var- call from the paragraph above.
Updating plugins and themes regularly could also minimize a security vulnerability. With Wordpress, there is the possibility to update the plugins automatically, which has the advantage that this will not happen manually. The disadvantage is that when the site is live, large plugin updates prevented users from accessing the site. We have decided to update weekly at a certain time when we know that there are hardly any active users on the website. These two steps should provide greater security against a Cross-Site-Scripting attack.
Another point is to sanitize Data. For specific Wordpress source code, there are some options to sanitize incoming Data. One way might be to code third-party data so that HTML and CSS in the string are processed as a simple string instead of markup and script.
So it would consist of this code:
var app = document.querySelector(‘#app’);
app.innerHTML = ‘<img src=”x” onerror=”alert(1)”>’;After encoding, the source code would look like this:
app.innerHTML = ‘<img src="x"
onerror="alert(1)">’;When entered into the UI, it displays the text
<img src=”x” onerror=”alert(1)”> instead of an actual image.
This works when third-party content is not allowed to contain markup. If markup is allowed, you must instead create a list of allowed elements and properties and remove anything that is not in that list.
var sanitizeHTML = function(str){
return str.replace(/[^\w. ]/gi, function (c ){
return ‘&#’ + c.charCodeAt(0) + ‘;’;
});
};You use it like this:
app.innerHTML = sanitizeHTML(‘<img src=”x” onerror=”alert(1)”>’);This also encodes the requests and sanitizes them. There is also a 3rd option that creates a list that filters forbidden elements. In the end, the programmer must decide which option to choose. All of them have their advantages and disadvantages, and as with the other security measures, it’s more about doing something better than doing nothing.
There are also plugins that protect you from possible hacker attacks. For example: Prevent XSS Vulnerability By Sami Ahmed Siddiqui.
This plugin helps to curtail the malicious links that hackers would leave in comment sections. For example, symbols such as exclamation marks, opening rune brackets, etc. cannot be used. The plugin thus assists in fighting Cross-Site-Scripting attacks on your WordPress website, however, this plugin gives limited protection and the other measures should be enforced as well.
To be on the safe side, a backup is always a good thing too. There are many plugins for this in Wordpress. So even though you should be safer now create a backup just in case.
Conclusion
The damage that can be caused by Cross-Site-Scripting attacks is enormous. XSS is not an issue of the past. Almost 50% of attacks on WordPress sites are carried out with Cross-Site-Scripting.
It has been shown that WordPress sites are still vulnerable to Cross-Site-Scripting attacks. However, if you know the hackers’ tricks, the protective measures can be easily implemented. It has been found that user input needs to be controlled and secured. According to my research, this is also confirmed by other articles. These inputs can be controlled by filters within the PHP code. There are also other features in wordpress that modify user input in a way that minimizes the chances of a Cross-Site-Scripting attack. The plugin and theme updates are quite easy to implement. These should take place regularly and especially for self-made plugins the compatibility to the theme should be ensured after each update. About sanitize data, several methods were shown how data becomes more secure for the website.
Don’t forget all the steps like setting up the web application firewall. Because as often mentioned, the greatest security is achieved by following all the suggested steps.
So the start-up and other wordpress sites can rest, once they have completed the steps, they should not have any issues with Cross-Site-Scripting attacks soon. But don’t forget the hacker community is usually faster than the security community.
If you have any questions or additions, feel free to write a comment.
