[
https://issues.apache.org/jira/browse/CSV-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554909#comment-15554909
]
Phil Varner commented on CSV-199:
---------------------------------
I'm primarily thinking about the CSVPrinter output use case, rather than the
input case. I don't have any evidence, but I would expect that a good
percentage of the usage of CSVPrinter is for data that will be consumed by an
end user using a spreadsheet rather than processed by a non-spreadsheet
application.
None of those other predefined formats would be necessary, as exporting to
MySQL format wouldn't be a vector for this as MySQL wouldn't execute the
formulas. Likewise with default, as that should be the generic case where the
use of the csv isn't anticipated to be Excel import.
I'm also not sure as to whether commons-csv should be responsible for this, but
from my own experience (which lead me to commons-csv), I was fixing an old bug
a webapp where the CSV was constructed using string concatenation, so values
weren't escaped at all, so the output CSV could easily be broken by a
user-generated input starting with '",'. After converting this to use
commons-csv, I was surprised that the formulas still weren't escaped, and I had
to do that manually in my code. I think it would be nice to both make it
apparent to users that this is something that can happen, and have a flag to
set defense against it.
> CSVFormat option to defend against CSV Excel Macro Injection (CEMI) attacks
> ---------------------------------------------------------------------------
>
> Key: CSV-199
> URL: https://issues.apache.org/jira/browse/CSV-199
> Project: Commons CSV
> Issue Type: New Feature
> Components: Printer
> Affects Versions: 1.4
> Reporter: Phil Varner
>
> A common use for Commons CSV is to export user-generated data for analysis in
> spreadsheet software like Excel. One attack against this usage is for a user
> to create data that appears as a formula to Excel, such that excel executes
> it. For example, a simple non-malicious example of this is a u CSV file like:
> {code}
> Name,Email,Favorite Color
> Aaron Aaronson,[email protected],=1+1
> {code}
> When opened, Excel will execute the macro and display "2". A malicious
> example could, for example, use "=cmd|' /C calc'!A0", causing a command
> prompt to be opened.
> This can be exploited with values starting with =, +, -, or .
> This feature would add a flag to CSVFormat called "escapeFormulas" that would
> defend against creating vulnerable CSV files like this by prepending a
> single-quote to any CSV column value starting with the four aforementioned
> characters. Also added would be a predefined format EXCEL_WITHOUT_FORMULAS
> that could be used for safely exporting data that was not intended to contain
> formulas.
> I believe it is important to add this as a feature to CSVFormat rather than
> relying on users to manually escape formulas because many users do not know
> about this security vulnerability, but would prefer to defend against it if
> aware.
> More information:
> https://www.owasp.org/index.php/CSV_Excel_Macro_Injection
> https://hackerone.com/reports/72785
> http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
