Welcome to the Patchstack Weekly Security Update, Episode 46! This update is for week 44 of 2022.
This week I was surprised to find I have not yet talked about the most prevalent security bug found in web applications in these weekly episodes. It has been talked about ad nauseam by security professionals, warning the world about the risk for decades. Yet it still prevails to this day as the most common security bug reported in web applications. So, today’s weekly knowledge share is about the always-relevant security bug called Cross-Site Scripting – or XSS for short.
I will then cover a handful of vulnerabilities in this week’s vulnerability roundup.
Cross-Site Scripting (XSS) is a serious risk for web applications, and there is no slowing down the number of XSS reports the Patchstack Alliance receives for findings open source components every month. Really, it is not slowing down: I just checked the numbers and we are adding on average 50 valid reports of XSS in WordPress components every month to the Patchstack Database.
In this week’s knowledge share, let’s talk about this problem. I will share what XSS is, what types of XSS there can be, and how to secure your WordPress code against XSS.
What is Cross-Site Scripting (XSS)?
OWASP defines Cross-Site Scripting (XSS) as an injection style of attack specific to websites. To clarify this further, XSS is an attack that allows user-controlled data to be injected into a website’s HTML, thus changing how the browser renders or interacts with a page.
A code example may help show the issue XSS can cause:
Given the code:
echo “<input type=’text’ value=’” . $_GET[‘user_input’] . ”’>”We would expect the output to look like this:
<input type=’text’ value=’*user input here*’However, since the value of $_GET['user_input'] is controlled by the browser and was not sanitized, this could lead to output that looks more like:
<input type=’text’ value=’0’> <script> alert(/XSS/); </script>’>In this example, unsanitized user input leads to the user (or an attacker) being able to add their own javascript to the page which in turn gets rendered by the browser.
Javascript alert boxes are the most common way to report XSS, but do not assume the attack is limited to an alert, attackers can pretty much do anything they would like in javascript.
Types of XSS
The above example would be considered reflected XSS. The data I used in the example was the GET variable sent with that one request. It is however just as common that the GET variable could be stored unsanitized in the database first, then later echoed back to the browser and that would result in what is more specifically called a stored XSS security bug.
Stored or reflected are the two primary types, but there is also a DOM-based XSS which is an XSS bug that exists in the javascript itself. You can learn more about DOM-based XSS in an interview I did with Rotem Bar a few months ago.
How to protect against XSS in WordPress?
The good news is, WordPress provides all of the tools you need as a developer to protect your code from XSS security bugs.
All you need to remember is the security golden rule or “never trust user input.” If your code is accepting a value from the browser, before you store it anywhere you should sanitize the value first using one of the many sanitization functions WordPress has, and before you output it as HTML be sure you escape the value using once again, one of the many escaping functions WordPress provides.
Which function to use depends on the value you are expecting, but they are easy to understand. If you are storing an email address, then use sanitize_email() , if you are expecting a name of a file, then use sanitize_file_name(), the most commonly used function would be sanitize_text_field() which is used for … you guessed it, text fields.
You can review all of the sanitization and escape functions in the WordPress documentation for Data Sanitization and Escaping in WordPress
One final function I should mention is wp_kses() which will filter out a string and can be given a list of allowed HTML elements and attributes. This will come in handy if you have a situation where you want to allow some HTML tags in the user-supplied values, but still, protect against XSS.
Vulnerability roundup
easy-digital-downloads unauthenticated CSV Injection
The developers of the popular Easy Digital Downloads plugin have addressed an unauthenticated CSV injection security bug in their plugin’s code.
CSV injection is not an immediate risk for websites, it targets users who use applications like Excel to open a CSV file the plugin exported. So, you can take practical precautions (such as not exporting CSV files until you patch your installation of Easy Digital Downloads). I have talked about the risks of CSV injection and how to patch it in Patchstack Weekly episode #30 What is CSV injection?
api2cart-bridge-connector patches two critical security bugs
The API2Cart Bridge Connector plugin is only 6 months old, but the developer is already taking security seriously and has patched two critical severity bugs in the plugin. Both bugs were found and reported through the Patchstack alliance. The first bug could have led to arbitrary code execution and the second bug could have led to arbitrary file uploads.
zoho-crm-forms unpatched arbitrary options update
The developers of the Zoho CRM Lead Magnet plugin, with the plugin slug “zoho-crm-forms” are actively working to address this arbitrary options update security bug. I noticed they released a new version this week, however, reviewing this new release they are not yet addressing this arbitrary options update bug.
They only added a check for a nonce, however, they should be checking the user’s capabilities as I explained back in Patchstack Weekly #27 How to Update wp_options securely
This bug is still technically unpatched at this time, but the developers are very close to addressing the issue.
Thanks and appreciation
This week’s thanks goes out to the developers of Easy Digital Downloads, API2Cart Bridge, and Zoho CRM forms. Great job addressing or working toward securing your code. Some of these developers are new to the game with few installs, some have tens of thousands of sites they secured with their patch. All of these developers are doing the right thing, securing their user’s websites and becoming better developers in the process.
A special thank you is once again earned by the members of the Patchstack Alliance. October’s bounty deadline is coming up soon and we have received a grand number of reports this month, every security bug reported gets forwarded to the developers of the affected open source component. Resulting in more projects receiving patches, more developers gaining experience handling security bugs, and the open source ecosystem becoming more secure as well. Great job alliance members.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!
