Add Excel export option in GridFields (and avoid CSV injection)

[chillu]

Overview

GridField allows export of data to CSV. While this format is simple, universal and easy to generate, it increases the security surface (see "Context" below), and is hard to get right (see the long discussion about encoding issues).

I propose that we push more strongly to make an Excel export option available to more users. There are a few ways to achieve this:

• Option A: Make export a multi-choice flow (UX changes), and add Excel support
• Option B: Make Excel support via a third party module more common (e.g. adding it to a default recipe like Bambusa, or make it clearer in our docs)
• Option C: Replace CSV as the default format in core (configurable). There's various Excel export addons doing this already
• Option D: Remove CSV export from core, and force devs to choose their own adventure
• Option E: Add more warning labels about using CSV in the UI ("Don't execute macros if you're opening this file in Excel")
• Option F: Do nothing, keep status quo.

Note that Excel export requires third party libraries to create it (e.g. https://github.com/PHPOffice/PhpSpreadsheet). It's a complex format which is easy to get wrong. I'm sceptical if this needs to be in the core framework.

Context

SilverStripe data can be exported to CSV. CSV can be read by spreadsheet apps like Excel. Those apps allow "dynamic" cell content (macros) with complex signatures which are hard to sanitise. Before executing this dynamic content, spreadsheet apps usually warn the user. As SilverStripe content, these macros are harmless, but when users ignore the warnings within their app (outside of SilverStripe), it can become dangerous.

We've previously added baseline security measures through SS-2017-007 (see https://github.com/silverstripe-security/security-issues/issues/4), but this hasn't been a comprehensive fix. See https://www.owasp.org/index.php/CSV_Injection for potentially malicious payloads.

After much discussion on the private security issue (https://github.com/silverstripe-security/security-issues/issues/53), we have decided not to treat this as a security issue in our product (rated as CVSS 0.0).

/cc @silverstripe/core-team

[chillu]

Quoting OWASP:

This attack is difficult to mitigate, and explicitly disallowed from quite a few bug bounty programs. To remediate it, ensure that no cells begin with any of the following characters:

This substantiates our position in my opinion, and we've already implemented the baseline protections they mention there years ago.

[sminnee]

As a core add-on, I would support the idea of making a pluggable interface for export formats (so that a module could provide an implementation of that) but not adding excel to export to core.

I'd probably treat this as a "patches welcome" kind of ticket too – if someone is keen to add this feature, happy to help design it, rather than pre-emptively building it.

[maxime-rainville]

Back in the glorious SS3 days, I did an Export to Excel module using phpoffice/phpexcel.

It was relatively easy to implement. Could serve as a general starting point.

[lekoala]

I have this module that works just fine https://github.com/lekoala/silverstripe-excel-import-export

I'm not sure it belongs to the core

what would be nice though is to have a common interface to set "exportable" fields somehow so that all modules could benefit from it

i would also love to see a solution to exporting large lists (like, a 20k members list) : due to heavy usage of the orm, it tends to be very difficult (in one of my project, I add to set some kind of raw export that was getting data from a direct database query instead)

importing data can also be tricky for some customers since they don't know exactly what to put in there, in my module i added a "sample file" which is really helpful

[ScopeyNZ]

what would be nice though is to have a common interface to set "exportable" fields somehow so that all modules could benefit from it

Another use case for silverstripe/silverstripe-cms#2454 ? That would be only if you wanted to export what you arbitrarily define as "content". What defines "exportable" for you?

i would also love to see a solution to exporting large lists (like, a 20k members list) : due to heavy usage of the orm, it tends to be very difficult (in one of my project, I add to set some kind of raw export that was getting data from a direct database query instead)

DataList does have a getGenerator function. The support on the adapter level is patchy though I think - at least until SS5 where the adapters are a lot more memory efficient.

For this issue my vote is option F by the way. I'm going to add RFC labels here.