Common Attacks on WordPress Sites 101: Cross-Site Scripting (XSS)
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, 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
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 “<”. 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:
- Whether the malicious script (from users’ inputs) is stored-
- If the malicious script is stored on the website or browser’s database, the attack is categorised as a Stored (or Persistent) XSS attack.
- If it’s reflected to other visitors instead, it’s called a Reflected XSS (or Non-persistent) attack.
- There is also another kind of XSS attacks, called the DOM (Document Object Model)-based XSS attack that we’ll explain later some time.
- Which side accepts unvalidated user-inputs (this categorization overlaps the Stored and Reflected categorisation)-
- Server-side XSS attacks
- 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:
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:
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.
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.
Akshat is the Founder and CEO of BlogVault, MalCare, and WP Remote. These WordPress plugins, designed for complete website management, allows 100,000+ customers to build and manage high-performance websites with ease.