Data Table - CSV export formulas warning

[kobelb]

When exporting a CSV using the Data Table visualization, we should warn users when the CSV contains characters which some spreadsheet applications interpret as formulas. Any cells, including the header, which start with the following characters can be interpreted as a formula: =, +, -, @.

Reporting implemented a similar protection in #37930, where the following modal is displayed after a report completes processing which contains formulas, and the user much click on "Download" after confirmation:

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[arisonl]

In a recent customer call, the customer asked for the ability to escape these characters, cc: @AlonaNadler

[AlonaNadler]

Adding @alexfrancoeur as he is responsible for reporting. I see Kibana behavior similar to most solutions in the market in this case

[alexfrancoeur]

@AlonaNadler when you say Kibana behavior, are you referring to what Kibana's behavior is today with no warning? Or what's being proposed here?

@arisonl when you say escape, do you mean escaping them like this\=? Or actually excluding these types of symbols with the export.

[arisonl]

@alexfrancoeur my understanding is excluding them, but I can reach out to clarify

[AlonaNadler]

Most products in the market don't support this request, they go ahead and export the CSV even if there are special characters. I don't see us reviewing all data and removing these, seem to like a rare request.

[arisonl]

Agreed but if we detect them like what this issue describes, how much extra effort is it to exclude them? It could be small (depending on the details of course). I think that if we implement the warning that this issue describes, we can consider exclusion in a subsequent iteration as an option for the user provided that it is a small incremental step.

[joshbressers]

CSV data is meant to be escaped by adding a single quote to the start of the field.

So for example

=cmd|' /C calc'!A0

Becomes

'=cmd|' /C calc'!A0

You can find more details about this problem here
https://owasp.org/www-community/attacks/CSV_Injection

It is fundamentally a spreadsheet and policy problem. Spreadsheets launching executables is ridiculous.

[alexfrancoeur]

I agree that generally, this is a spreadsheet problem, but we're also seeing members of our community putting ownership back on the stack as well. It feels like there is some middle ground here. As Alona suggested, for the majority of our users and competing products in the analytics space, this is not common practice. That being said, more and more the stack is being deployed into financial, government and health organizations in which the primary consumer of Kibana are end users that may not fully understand the technical implications of CSV export.

I propose we consider a Kibana config setting that would enable escaping characters at the beginning of a cell that could be interpreted as formulas ( =, +, -, @). This makes more sense over an advanced setting as it's applied across Kibana, likely the level of control an administrator of Kibana would want.

@elastic/kibana-reporting-services what would the level of effort be to introduce this type of functionality? I don't believe we manipulate data exported anywhere at the moment.

[alexfrancoeur]

Linking to @joelgriffith's PR: #63645

[legrego]

@joelgriffith's PR solved this for Reporting's CSV generation, but this the Data Table CSV export is something else altogether. Data Table's CSV is actually located here, and does not benefit from the work that Joel did in #37930 or #63645

[legrego]

@elastic/kibana-app how much effort do you think it would take to replicate Reporting's functionality for Data Table export?