In this article, we will explain what CSV injection is and how can CSV files be exploited. We will also shed some light on how to secure against CSV injection vulnerabilities and protect your site even further.
We will also highlight a plugin affected by a CSV Injection vulnerability that at the time of writing this article did not have a patched update available (but of course, Patchstack paid users were protected by a virtual patch).
What is CSV injection?
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.
How can CSV files be exploited?
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 the compromise of the user’s computer, or possibly exfiltration of data or data being held for 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 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.
How to secure against CSV injection?
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.
- Equals sign “=”
- Plus “+”
- Minus “-“
- At symbol “@””
- A tab
- Carriage return
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, 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 you would rather not use spreadsheet software at all.
Request a Quote – CSV Injection
If you are running the Request a Quote plugin, you need to know more about CSV Injection and what risks it poses.
A security researcher named Benachi discovered and reported this CSV Injection vulnerability in WordPress Request a Quote Plugin.
This vulnerability could allow a malicious actor to craft malicious formulas to then exploit vulnerabilities in the spreadsheet software or to execute commands to gain access to the victim’s PC.
This vulnerability in the Request a Quote plugin has been fixed in version 2.3.9.
If you have a plugin with a vulnerability that is not fixed (you can check it from the database) you may want to look for a new plugin to replace it. If a plugin has been abandoned you should abandon it as well – delete it and find a new one.
How do I know if a plugin has been abandoned?
The simplest way to check is by logging in to the WordPress admin panel and opening the Plugins dashboard. From there, check if any of your plugins have updates available. If you are there already – update the ones you can. The ones that have no updates available should be checked.
By clicking on the ‘Visit plugin site’, you can check if the plugin is still available to download and ‘open’ – not closed by the WordPress security team.
Read more here: How To Spot Potentially Abandoned Plugins in Your WordPress Site?
Protect your WordPress site against CSV injection
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.
You can learn how to protect your WordPress site with Patchstack here.
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.
And a special thank you to all of the developers out there handling CSV data the right way, every time, input or output.
Want to listen to this blog post? Check Patchstack Weekly on Spotify!
