Esportazioni CSV: verificare le formule prima di aprire i dati in un foglio di calcolo

Parliamo del tuo progetto →

Un file CSV sembra innocuo perché contiene testo, non un eseguibile. Il rischio nasce dopo l’esportazione, quando quel contenuto viene aperto in un foglio di calcolo che può interpretare alcune celle come formule. OWASP descrive questo problema come CSV injection, o formula injection, e avverte che il formato da solo non basta se i dati arrivano da fonti non affidabili. (OWASP)

Per chi sviluppa o esporta report da CRM, help desk, back office o applicazioni interne, la domanda utile non è se il CSV sia “pericoloso” in astratto. La domanda è: in quale programma verrà aperto e quali celle potrebbero essere lette come formule?

Dove nasce il rischio

OWASP indica che in Excel e LibreOffice Calc una cella che inizia con = può essere valutata come formula. La stessa fonte segnala anche altri prefissi da trattare con attenzione in alcuni contesti, tra cui +, -, @, tab, carriage return e line feed. Il punto non è il file in sé, ma il modo in cui il software destinatario interpreta il contenuto. (OWASP)

Questo rende importante controllare il flusso completo:

  • inserimento del dato;
  • memorizzazione;
  • esportazione;
  • apertura nel programma realmente usato dal destinatario.

Una correzione applicata solo all’interfaccia web o al backend può lasciare scoperto il file scaricato.

Cosa serve prima della verifica

Prima di testare un export CSV servono tre elementi:

  1. Un flusso reale di esportazione usato davvero nel lavoro quotidiano.
  2. Il software di apertura effettivo, per esempio Excel o LibreOffice Calc.
  3. Dati sintetici e innocui, mai file da distribuire a clienti o colleghi senza controllo.

Questa è una verifica difensiva: non sostituisce i test di compatibilità completi su tutti i possibili consumatori del CSV.

Procedura pratica

1) Mappa il percorso del dato

Prendi una colonna semplice, ad esempio nome_prodotto, ticket_subject o note. Chiediti:

  • chi la compila?
  • arriva da utenti esterni o da operatori interni?
  • viene esportata così com’è o trasformata prima dell’export?
  • il destinatario la apre in un foglio di calcolo?

Se la risposta all’ultima domanda è sì, il controllo va fatto sul file scaricato, non solo sull’interfaccia web.

2) Inserisci un caso di test innocuo

Usa un valore minimo e chiaramente riconoscibile come prova, per esempio:

  • =1+1
  • +1+1
  • @test

L’obiettivo non è eseguire un attacco, ma osservare se il programma tratta la cella come formula o come testo. La stessa verifica può essere ripetuta con separatori di campo, virgolette e celle vuote per capire se l’esportazione conserva il significato previsto.

3) Apri il CSV nel programma reale

Apri il file nello stesso software usato dai destinatari. Se il processo operativo prevede che il CSV venga salvato e riaperto, ripeti anche quel passaggio. OWASP segnala che alcune protezioni possono comportarsi in modo diverso dopo salvataggio e riapertura, quindi il test deve coprire il ciclo effettivo e non solo l’apertura iniziale. (OWASP)

Esempio didattico di verifica

Input simulato:

  • colonna: commento
  • valore: =1+1

Comportamento atteso in ambiente di test:

  • la cella resta testo visibile, non formula eseguita;
  • il significato del dato resta leggibile per il destinatario autorizzato;
  • l’export non introduce effetti collaterali nelle altre colonne.

Si tratta di un esempio didattico, non di un test di penetrazione eseguito qui.

Come interpretare il risultato

OWASP osserva che non esiste una sanitizzazione universale sicura per tutti i fogli di calcolo e per tutti i consumatori downstream. In pratica, la difesa va scelta in base al caso d’uso: un CSV pensato per la lettura umana può richiedere una protezione diversa rispetto a un file destinato a essere reimportato da un sistema. (OWASP)

Per Excel, la fonte segnala come approccio più resistente l’aggiunta di un tab alle celle che iniziano con caratteri che possono attivare una formula, tenendo però presente il compromesso: il tab resta nei dati. È quindi una misura da valutare con attenzione, soprattutto se il CSV alimenta anche altri sistemi. (OWASP)

Controlli di accettazione

Il controllo può dirsi utile quando:

  • il percorso di export è stato mappato dalla sorgente al file finale;
  • il test innocuo produce lo stesso comportamento nel software reale dei destinatari;
  • esiste una regola documentata per le colonne testuali a rischio;
  • la verifica viene ripetuta dopo ogni modifica all’export.

Responsabilità consigliate:

  • sviluppo/backend: implementare la regola di esportazione;
  • IT/security: validare il comportamento nel software destinatario;
  • redazione o operations: mantenere il caso di prova e la checklist aggiornati.

Cosa fare adesso

Se il tuo team esporta report CSV da applicazioni interne, vale la pena rivedere il percorso completo prima della pubblicazione. Un piccolo test sul flusso reale è più utile di una regola astratta sui caratteri “pericolosi”.

Se vuoi, puoi partire da una sola esportazione: quella più usata da amministrazione o assistenza. Da lì è possibile definire una verifica ripetibile e capire dove serve davvero una protezione specifica.

Fonti