Welcome back to the Patchstack Weekly Security Update! This update is for week 27 of 2022.
CSV Injection is an old vulnerability, but one I have not talked about before on the podcast, so that will be the topic of the weekly knowledge share.
This week’s vulnerability news will be brief – I will highlight 3 plugins with WordPress Options Update vulnerabilities (2 of which require no authentication). Each of these plugin’s authors have released a patch.
I will also highlight a plugin affected by a CSV Injection vulnerability that, unfortunately, has not yet been patched (but of course, Patchstack Pro and Business users are protected by a virtual patch).
CSV injection occurs when websites generate CSV files and include untrusted user input within them.
This can lead to code execution or data exfiltration if someone opens the now malicious CSV file.
It’s an attack that won’t affect the website directly but is still considered high risk.
This is because CSV Injection attacks (also known as Formula Injections) can be used by attackers to target the employees or users who open the malicious CSV files in common spreadsheet software.
Most of us know not to open files from untrusted sources. We know not to open a file emailed to us out of the blue, especially from someone we don’t know. But, what about files from our website? What if we regularly exported a CSV of sales numbers or customer data? We likely trust that file.
That file though would be a juicy target for attackers because it’s almost guaranteed the file will be opened.
You may have heard of Excel Macro attacks – Formula or CSV Injection attacks are very similar.
This category of attack targets the user who opens a malicious file which could cause the spreadsheet software to run code, pull data from remote sources, or allow data from the spreadsheet to be sent to the attacker.
These attacks are normally associated with spam/scan emails and could lead to ransomware infecting a system.
But websites with CSV Injection security bugs can also be used as the direct path to the user (instead of an e-mail with misspellings and bad grammar).
Suppose an attacker can get a user to open the malicious file. In that case, it will lead to compromise of the user’s computer, or possibly exfiltration of data or data being held in ransom.
Macros and Formulas are powerful tools for spreadsheet users, so they’re not going away any time soon. There are protections in the spreadsheet software too, but it is still very important that web applications that generate CSV files, files that are trusted by users. Do a little checking and sanitizing of the data before they pass it along.
Lucky for us, the explanation on how to secure code against CSV Injection security bugs is pretty easy for the basics and it should take an even beginner developer no more than a few hours to implement some defensive coding practices to secure a site against CSV injection bugs.
If your code generates a CSV file, and if any of the cells look like a formula, you must sanitize or remove it.
You can easily detect Formula cells because they always start with one of the following characters.
Sanitizing is easy to do – make sure the first character is not one of those I just listed.
You simply add another character to the start of the string, commonly the recommendation is to add a single quote ‘ character that will ensure the cell (when loaded in the spreadsheet) will not be considered a formula.
You could also consider rejecting the whole cell value, but if you do this, please report it as an error in some way. This could be important information that someone needed to record, or they need to be aware they are being targeted with CSV injection attacks.
One final note, you can also speed up this process by ignoring cells that do not include user supplied data, or that match the input type you expected for that data (such as numbers only, or letters only, or looks like an email).
This could backfire of course, if input values change later on down the line.
It could also come in handy if you need to allow formulas to be added to cells for some valid reason.
The answer here may lie with the people who are using the data you’re generating. You may need to have a discussion, see how they use the data, and inform them of the risks. From that conversation, you will be able to decide what is best. You might even find yourself replacing CSV entirely with another formatting standard if they would rather not use spreadsheet software at all.
In this week’s vulnerability news, here are three plugins that have patched a security bug that could allow modification of a WordPress website’s options table.
I spoke about this a few weeks ago in an episode about updating wp_options securely.
If you caught that episode, you know the risks already, so if you are running any of the following plugins, please update to the most recent release as soon as you can.
Luckily the developers for these three plugins are serious about patching their projects against security bugs. But, as I have mentioned before, this is not always true. This week, it was not true for the Request a Quote plugin, which is affected by a CSV Injection vulnerability and has not received a patch from it’s developer yet.
If you are running the Request a Quote plugin, you need to know more about CSV Injection and what risks it poses. You may want to look for a new plugin to replace this plugin (if it has been abandoned) or if you listened to this week’s knowledge share, you can make an informed decision on your own.
This week’s thanks goes out to the developers of the Shortcode Addons, Jquery Validation For Contact Form 7, and Accordions – Multiple Accordions or FAQs Builder plugins.
Thank you for supplying those security patches and securing your user’s websites.
A special thank is also due for all of the developers out there handling CSV data the right way, every time, input or output.
While spreadsheet software does its best (such as warning users before executing code and allowing users to disable macros altogether) you still sanitize the data for them, as an extra layer of defense.
Thank you if you go the extra mile too, if your application is accepting CSV files as input, you are sanitizing or escaping the values appropriately to avoid other security bugs, such as SQL injection (if the CSV values were added to the database) or Cross-Site Scripting (if they were displayed on a web page), you get the idea.
Thank you to every developer who knows, that CSV isn’t so simple – but that you can use it securely and safely if you know how to code defensively.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly Security Update!
