How To Prevent CSV Injection

If you are not familiar with the concept of CSV Injection, we suggest that you review the article entitled “What is CSV Injection ?“.

If you are not familiar with how to detect CSV Injection, we suggest that you review the article entitled “How To Test for CSV Injection“.

Protecting your application and users from CSV Injection boils down to recognizing which of the following scenarios are relevant for you, and either filtering or neutralizing the spreadsheet meta-characters used to define formulas:

Your application produces CSV files that may contain untrusted input (e.g. user input)
Your application consumes CSV files that may contain untrusted input
Some other application produces CSV files that users within your organization process using spreadsheet software

We will examine each scenario separately and show how you can mitigate your risk and illustrate the technique using a simple perl and python scripts.

Your Application Produces CSV Files

Assuming that you have the ability to change the application, your developers must “whitelist validate” all untrusted inputs to ensure they meet your expectations. Whitelist validation alone may suffice to filter out all offending content and prevent CSV Injection, IF your requirements allow you to reject input values that start with: +, -, =, and @ (i.e. spreadsheet meta-characters).

If it is necessary, however, to accept these characters, the application must encode any cell values that might otherwise be interpreted as formulae. This is accomplished by preceding cell values that begin with the characters: +, -, =, or @ with a single quote. This is termed “escaping” or “neutralizing” the characters, and it will ensure that such cell values are interpreted as data and not as a formulas.

Your Application Consumes CSV Files

In the case that the CSV file is produced by an application not within your control, you will want to validate and/or encode the file content before allowing your application(s) to process it. To that end, you will want to encode all cells in the manner described above as an intermediate processing step before it gets to your application or users. The following examples illustrate how to inject a single quote in front of CSV fields that start with a formula meta-character. Each assumes no formulas should be allowed through and each cell should be interpreted strictly as data:

Code (Note: no claims of efficiency !)

Language

 perl -e "$_='=f1(),2,3,=f2(),99';s/^[+-@=]/'$1/;s/,([+-@=])/,'$1/g;print $_;"

Perl

import re

x = "+f1(),2,3,=f2(),99"
x = re.sub ("^([+\-@=])", "'\\1", x)
x = re.sub (",([+\-@=])", ",'\\1", x)

print x

Python

In both cases the input is: +f1(),2,3,=f2(),99

and the output is: ‘+f1(),2,3,’=f2(),99

Your Users Import CSV Files Into Spreadsheets

This scenario can be handled in a manner similar as the above, although it is not always as easy to automate the process when end-users are involved. The ultimate solution here will depend on your requirements and how/where you can best insert an encoding step similar to the above into the workflow.

For additional information about preventing and/or fixing this vulnerability within a web-application, please see the article entitled “How to Prevent CSV Injection”.

Preventing Tampering

It is also important to protect the content of files in the workflow. CSV files should exhibit file permissions that prevent uncontrolled editing. In other words, a Least Permissions approach should be enforced with respect to granting write permission to such files.

End-User Awareness

You may have noticed that both CSV attack vectors relied on the complicity of the unwitting user. (The user must either explicitly sanction program execution or click to follow a malicious link.) As with Social Engineering exploits, the likelihood of successful CSV Injection can be reduced through end-user education.

About Affinity IT Security

We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers.

Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.

Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.