Watching dominoes fall is always fun. And why wouldn’t it be? It’s a harmless, yet mesmerizing display of organized chaos. But if it did represent something harmful, there would be much reason to worry. Cross-site scripting attacks, at their worst, are the dominoes of common website vulnerabilities.

Cross-Site Scripting is a website attack that can be compared to dominoes falling, because of the damage it causes.

Once dominoes start falling, there’s no stopping them.

Cross-site scripting, generally known as XSS, is a type of Injection attack. It works a little differently from most other attacks, because of it in addition to exploiting WordPress websites and their servers, the attack also utilizes web browsers.

How it works in general

Cross-Site Scripting starts out the way most injection attacks (such as SQL Injection) do: by accepting user inputs. An attacker injects malicious scripts into good WordPress sites through a part of the website that accepts users’ inputs (like a comment field). So if an attacker could use, say malicious JavaScript code within “<script>… </script>” tags in the comment section, the code would run on the browser. This would allow the attacker access to any information they can glean from the visitor’s browser, from cookies to saved or entered login credentials.

How to prevent Cross-Site Scripting

There are a few sure ways to prevent XSS attacks on your WordPress site. Some of them include making sure that your:

  • Web browser makes use of the same origin policy- Web browsers usually have a set of rules, by which one web page is allowed to access script on another only if they had the same origin. If a browser doesn’t check the origin of the script of web pages, it results in a vulnerability that can be used by attackers to inject malicious scripts.  This means that users’ browsers would execute the code. All of this is moot though, if one of your website’s visitors uses a browser that doesn’t have this policy… in which case stricter security measures on your site would help.
  • Website can tell the difference between markup tags and actual content on a page– Web sites are vulnerable to XSS attacks when they can’t make out the difference between markup code and content that has to load on its pages. This means that if there were a piece of text, like an equation having the ‘<’ sign, and executable code (containing the <script> tag, the browser would mess them both up. This could be because the developers forgot to implement rules that dictated that “<” signs in text on the web page would be represented as “&lt;”. When this happens, the website is vulnerable.
  • Website has input validation and sanitization- None of this would happen if the standards of accepting users’ inputs were very high.

Categories of XSS attacks

Cross-Site Scripting is a very complex attack especially because of how it can be categorized. It can be put in buckets, based on the following criteria:

  1. Whether the malicious script (from users’ inputs) is stored-
    1. If the malicious script is stored on the website or browser’s database, the attack is categorised as a Stored (or Persistent) XSS attack.
    2. If it’s reflected to other visitors instead, it’s called a Reflected XSS (or Non-persistent) attack.
    3. There is also another kind of XSS attacks, called the DOM (Document Object Model)-based XSS attack that we’ll explain later some time.
  2. Which side accepts unvalidated user-inputs (this categorization overlaps the Stored and Reflected categorisation)-
    1. Server-side XSS attacks
    2. Client-side XSS attacks

Stored (or persistent) XSS Attack

Stored XSS usually occurs when user inputs are taken and stored in a database. In this case, the user is affected because unsafe data is run on the browser. Any attacker could input malicious code on a vulnerable website just once, and it would get stored (persistently) on the server. When any other user accesses the website, they would get affected. The malicious code infects the user’s browser, and retrieves sensitive data, (such as usernames and passwords) for any site the user might use the browser to visit. Here is what a Stored (or Persistent) XSS attack looks like:

Stored XSS attacks can cause a lot of damage. This image shows how one works, in general.

Stored XSS attacks can cause a lot of damage. This image shows how one works, in general.

One of the most well-known, real-world examples of this attack, is that of the MySpace worm of 2005. The worm was scripted in JavaScript to be self-propagating. So instead of just affecting people who visited the point of origin of the worm, it affected visitors of the original victims, thus propagating exponentially. Here’s how it loosely worked:

Samy Kamkar hacked MySpace in 2005, and introduced an XSS worm that took over 1 million profiles in 6 hours. It was an example of the scope of a Stored XSS attack.

Samy Kamkar hacked MySpace in 2005, and introduced an XSS worm that took over 1 million profiles in 6 hours.

This attack is precisely why we compared XSS attacks to dominoes falling.

Reflected (or non-persistent) XSS attack

Reflected XSS attacks are a different thing altogether. They are the most well-known sort of XSS, and can pose a serious threat, if not prepared for. Here’s a general example, to explain how this attack could work:

Reflected XSS is the more well-known sort of XSS attack.

Reflected XSS is the more well-known sort of XSS attack.

This attack could be used to do anything from launching a DDoS attack (as seen in the above example), to scanning the websites/ profiles/ browsers of every visitor to your website, for vulnerabilities that could later be exploited.

Cross-Site Scripting could use information from any website/web service you use.

Cross-Site Scripting could use information from any website/web service you use.

The Cross-site Scripting attack is one that has existed for a long time. Unfortunately, until the MySpace worm was created, not many in the realm of internet security took it very seriously. However, according to a report by WhiteHat Security in 2015, even 10 years after the MySpace worm, 47% of all websites are still vulnerable to this kind of attack. This attack relies on user inputs not being validated or sanitised before being processed. So the best way to protect your WordPress website, is to make sure that it doesn’t take your subscribers’ inputs lightly. This obviously means you should make sure that the plugins and themes on your site accepting user inputs validate them first. But even otherwise, choosing an extra security feature can never cause harm. If you’d like to try out a website scanner that is 100% accurate, requires no technical assistance, and also helps you remove hacks, visit MalCare.

close

Download Now:
Top 11 Secrets of an Awesome WordPress Backup Plugin

Download the guide now