WordPress today is the most popular website building platform. It has over 60 million users. This type of popularity draws both good and bad attention. While more and more websites are being built on WordPress each day, there are a large number of hack attempts made on WordPress websites too. In fact, over 90,000 hack attempts are made on WordPress site every single minute of the day. While there are various methods that hackers employ to break into a website, one very well-known hack attempts made on WordPress website is cross site scripting (XSS).
In this type of attack, after breaking into a WordPress website, the hacker not only exploits the WordPress website and it’s server but also utilizes the web browser of the user.
Cross site scripting vulnerabilities have a long history that goes back to the 90s. It has affected some of the biggest websites in the world like Facebook and Google. This type of attack can lead to the successful execution of a number of malicious activities like user session hijacking, malicious script execution, data theft, phishing scams, etc. In this post, we’ll learn about preventing XSS attacks but first, let’s learn how they work.
How Cross Site Scripting Attack Works?
It’s a type of injection attack and starts out as most injection attacks do: by exploiting user inputs. Hackers inject malicious scripts into a WordPress website through a part of the site that accepts information from the users like the comment section.
What are the Different Types of Cross Site Scripting Attacks?
There are different types of cross site scripting attacks. These attacks can be categorised based on the following criteria:
- Whether the malicious script codes are stored in the website,
- And which side (server-side or client-side) accepts unvalidated user-inputs (more on this below)
If the malicious script codes are stored in the website, then we can categorize the attack in three parts:
- Stored (or Persistent) XSS attack
- Reflected XSS (or Non-persistent) attack
- DOM (Document Object Model)-based XSS attack
There are two types of cross-site scripting attacks based on which side accepts unvalidated user-inputs (this one overlaps with Stored and Reflected category that we mentioned above):
- Server-side XSS attacks
- Client-side XSS attacks
Stored (or persistent) XSS Attack:
In this type of attack, user inputs are stored in the database. Whenever a user visits the vulnerable page, the malicious script runs on the browser. This can affect every visitor on your site and can lead to a massive web security compromise. The code infects the browser of visitors and extracts sensitive information like the login credentials for practically any website the visitor is using the browser to visit. A typical Stored (or Persistent) XSS attack looks like this:
A good example of this attack is when Samy Kamkar hacked MySpace in 2005 and introduced an XSS worm that took over 1 million profiles in the span of just 6 hours.
Reflected (or non-persistent) XSS Attack:
Reflected XSS is the more well-known sort of XSS attack and they are a very different type of attacks. It can be used to launch DDoS attack or it can be used to scan websites/browsers/profiles of visitors of your site. They look for vulnerabilities which they can later exploit. This is how a reflected XSS attack could work: Say, your site has a search tab and the attacker provides a phrase and some malicious HTML special characters to the site’s search engine (example – <b> xxx <b>). The search string is displayed on the result page as “Sorry, couldn’t find <b> xxx <b>”. So far so good.
But if the site search engine can’t differentiate between code and text entered by the user, it can unwittingly run a malicious code entered by a hacker. If the code runs, a hacker can get full access to the site and run havoc. They could make the page refresh frequently which may bring down the database server.
Now that we how what these attacks are and how they are carried out, let’s look at some of the methods to prevent them.
Cross Site Scripting Prevention Methods –
To prevent a successful cross site scripting attack on your website, you need to:
Make sure the web browser is using the same origin policy –
The web browser works with a set of rules in which one web page can access data in another web page only if both pages have the same origin. When the browser fails to check the origin of web pages, your website is left vulnerable. Because taking advantage of this type of vulnerability, hackers may inject a malicious script into your WordPress website.
When this script is executed, the hacker could gain access to your site and cause irreversible damages. Hence, it’s important to use browsers that follow the same origin policy. But it’s impossible to make sure that all your site users are using browsers with same origin policy. In that case, having good website security measures in place is a good idea.
The website should differentiate between markup tags and content –
It may happen that a developer forgot to implement rules that’ll help differentiate between a malicious code and normal text. If the website is unable to tell the difference between the two, then it’ll end up executing a malicious code. One can avoid this by making sure that the standards of accepting users’ inputs are proper everywhere on the website. For instance, if you are using a plugin to collect phone numbers, make sure accepts only numerical and not malicious scripts.
Although cross site scripting attacks have been around for a long time, it wasn’t until the MYSpace worm that people started taking this threat seriously. If one report is to be believed, then almost 50% of websites are vulnerable to this type of attack. Since the attack relies heavily on vulnerabilities in contact forms, comment boxes and such type of user input areas, it’s important that you choose plugins and themes that enables these areas carefully. Moreover, keeping themes and plugins updated can significantly reduce the chances of an attack. But far too many website owners are in the habit of ignoring updates.
One big reason is that regularly updating websites become a headache if you are maintaining many WordPress websites. WordPress security plugins like MalCare offer features that enable you to update all your WordPress websites from the dashboard itself. This means you don’t have to log in to each one of your websites to monitor and update plugins, themes or WordPress core that are outdated. You can invest this saved time in growing your business while your site remains secure.