What is cross-site scripting (XSS)?

Cross-site Scripting (XSS) is a type of security vulnerability found in some websites and web applications that accept user input. It is when malicious scripts are injected into web pages in the form of browser side script, to be sent to unsuspecting users. It occurs when the web application accepts user input without validating or encoding it. Unfortunately, the end user’s browser will not be able to recognize that the script has been tampered with and will assume that it has come from a trusted source.

Risk impact of XSS

The consequences of XSS are quite impactful, making it a very serious security vulnerability. Some of the risks associated with XSS include:

• User accounts being hijacked

• Credentials being compromised

• Sensitive information being stolen

• Access to client computers

• Content of HTML page being rewritten

• Any cookies and session tokens being accessed

Different types of XSS

There are three different categories of XSS vulnerabilities:

Reflected XSS (Non-Persistent or Type I)

Reflected XSS is when a malicious script is reflected off a web application to the target’s browser. In this case, the script is triggered through a link that sends a request to a website with the security vulnerability that allows for the execution of malicious scripts. While Reflected XSS is more common than the other types, it is not as dangerous as Stored XSS because the malicious scripts are not stored permanently in the database or server.

Stored XSS (Persistent or Type II)

Stored XSS is the most damaging type of XSS and occurs when malicious code is injected directly into a web application. In this case, the application permanently stores the injected input and when the targeted individual visits a webpage with this stored malicious input, their browser executes the code as part of its response.

DOM Based XSS (Type-0)

DOM (Document Object Model) Based XSS occurs when the security vulnerability exists in the client-side code instead of the server-side code. It takes place in the DOM of a website rather than in the HTML returned by the server. As a result, the client side code will run in an “unexpected” manner, executing pages differently due to the malicious changes in the DOM environment.

How XSS is possible on WordPress

An XSS attack is possible on WordPress when the website has a cross-site scripting vulnerability, such as not validating or checking external input. More often, the vulnerabilities are not within WordPress core—which are discovered and fixed quite fast, but within third party components, such as plugins and themes. Attackers then use these vulnerabilities found on WordPress websites to implement XSS attacks.

How to prevent XSS attacks?

There are a couple of ways to secure websites from the vulnerabilities that could lead to an XSS attack:

• In WordPress core, plugins, and themes, have all input strictly sanitized as it’s received.

• In WordPress core, plugins, and themes, escape all data on output to prevent it from being categorized as active content by applying combinations of HTML, JavaScript and CSS encoding.

• Through a site owner, developer, devops engineer or through a third party solution like WordFence or Sucuri, use a Content Security Policy (CSP), a browser security mechanism that can reduce the severity of XSS and other attacks by limiting the resources a page can load.
• Make sure your WordPress core, plugins and themes are up-to-date and do not contain vulnerabilities—use third party solutions and hosting security features (alerts and disabling vulnerable components).