Cross-Site Scripting is one of the most common security vulnerabilities found in WordPress plugins over the years. In 2023, XSS ranked #1 as the most common vulnerability in the WordPress ecosystem, with over 53% of all vulnerabilities being categorized as XSS.
Cross-Site Scripting has historically been one of the most commonly exploited vulnerabilities in the WordPress ecosystem. To understand why, let’s look into what causes it and what can happen if your website becomes vulnerable to cross-site scripting.
What causes a Cross-Site Scripting (XSS) vulnerability?
Cross-Site Scripting (XSS) is a security vulnerability that allows a hacker to insert malicious scripts into websites or applications. It occurs when user input variables are not properly escaped (output) and sanitized (input).
Cross-Site Scripting is commonly categorized into two variants: Reflected and Stored XSS. There’s also DOM-based XSS, which is similar to reflected XSS, but the code is executed in the client (browser) itself and nothing is passed to the server.
The difference between stored and reflected XSS is often also called persistent and non-persistent XSS. Stored XSS means that the injected code will be stored on the website in some way (e.g., injected into comments that are loaded on the page), while reflected XSS is non-persistent and only reflected back to the user who injected the code.
For example, when user input is not properly sanitized in comment forms, an attacker can add a comment to the website that includes JavaScript code to redirect the website. This JavaScript is now stored in the database and loaded together with all the other comments. Your browser thinks that this code is part of the website and will redirect you to wherever the script sends you.
What can happen if your WordPress website has an XSS vulnerability?
The severity of reflected and stored XSS can be quite different. Stored XSS can be considered more severe since the injection will be persistent on the website and will affect all users who visit the page where the injected code is present.
Reflected/dom-based XSS usually requires some form of social-engineering and tricking the user into clicking on a link that contains the malicious payload which would then be executed in the victims browser
XSS has commonly been used for phishing, stealing authentication cookies, defacing web pages, and redirecting traffic. XSS is also very easy to exploit and automate; therefore, hackers are often able to weaponize this faster than users can update or patch the vulnerable software.
A great example is an XSS vulnerability found back in 2019 in the Social Warfare plugin. That vulnerability allowed hackers to inject JavaScript code that was loaded together with the Social Warfare share buttons. Hackers mass-exploited this vulnerability and redirected traffic on all sites that were loading these buttons. You can read more about this here: Social Warfare XSS RCE Vulnerabilities Attack Data.
What can WordPress developers do to avoid XSS vulnerabilities?
WordPress provides a long list of different escape functions that developers can use to escape user input variables. Depending on where you output the user-provided values, you might need to use different functions.
If your plugin or theme accepts custom HTML provided by a user, you should use the wp_kses function, as it allows you to define a whitelist of allowed HTML tags and attributes. However, that gives no guarantee that XSS is not possible.
We also often see cross-site scripting vulnerabilities in plugins that make a shortcode available. Since contributors can also use shortcodes, it may introduce a contributor+ cross-site scripting vulnerability.
Since a Cross-Site Scripting vulnerability is very easy to exploit and is often weaponized rather quickly, it’s important to react as quickly as possible. Firewalls can be quite good at blocking XSS attacks, but since XSS payloads can be easily crafted to evade detection, vulnerability-specific measures like vPatching have significantly lower chances of causing false positives while being much harder to bypass.
Website owners can also use security hearders to mitigate some risks from cross-site scripting vulnerabilities. Content Security Policy (CSP) allows you to block inline scripts and block scripts from untrusted sources. X-XSS-Protection provides basic filtering to block the rendering of the page if XSS attack is detected.
Conclusion
Cross-Site Scripting (XSS) remains a significant threat within the WordPress ecosystem due to its prevalence and ease of exploitation. Whether through stored or reflected variants, XSS vulnerabilities can have severe consequences for both website owners and users, leading to data theft, unauthorized access, and redirection to malicious sites.
It is crucial for WordPress plugin and theme developers to understand these risks and implement proper sanitization and escaping techniques to safeguard their users sites. Regularly updating plugins, using security measures like vPatching, security headers, and being vigilant about potential vulnerabilities can help protect your WordPress sites from XSS attacks.
Join the Conversation!
There's a dedicated thread on this post inside of The Admin Bar community. Join in on the conversation, ask questions, and learn more!
Group Thread
Oliver Sild
Oliver Sild is the CEO and Co-founder of Patchstack. He is an entrepreneur and cyber security expert with a strong focus on community building. He has been organising hacking competitions (& local CTF community) in Estonia since 2016, has kickstarted a startup community in his hometown and has nearly 10 years of experience with WordPress security.
