Una funzione di upload sicura dipende da più controlli applicati insieme, e la OWASP File Upload Cheat Sheet li elenca. Questo articolo ripercorre tale elenco, segnala i punti che si tende a trascurare e lo trasforma in test che è possibile eseguire su ogni endpoint di upload.
Da cosa ci si difende
La cheat sheet raggruppa le minacce sotto la categoria "file dannosi". La prima è un attacco al software che gestisce il file. Un attaccante consegna un file che sfrutta una vulnerabilità nel parser o nel modulo di elaborazione; la cheat sheet cita come esempi l'exploit ImageTrick e XXE.
La seconda è il phishing. La cheat sheet porta come esempio un modulo per le candidature di lavoro: l'upload diventa così un modo per far arrivare un file ostile davanti alle persone che lo aprono.
La terza è la disponibilità. ZIP bomb, XML bomb (il billion laughs attack) e semplicemente file enormi possono riempire lo storage del server e comprometterne la disponibilità.
Validare prima di accettare
La cheat sheet stabilisce una sequenza: applicare la input validation prima di validare l'estensione, e poi lavorare con una allowlist.
- Elencare le estensioni consentite. Permettere solo quelle sicure che la funzione di business richiede. Un modulo per la foto del profilo non ha motivo di accettare altro che pochi tipi di immagine.
- Validare il tipo di file. Non fare affidamento sul
Content-Typedichiarato, perché può essere falsificato. Validare il tipo di file e la signature prima di accettare l'upload. - Impostare un limite alla lunghezza del nome del file e, se possibile, limitare i caratteri ammessi.
- Impostare un limite alla dimensione del file.
Se un file non supera uno qualsiasi di questi controlli, va rifiutato.
Prestare attenzione a nome e posizione
La cheat sheet indica di sostituire il nome del file fornito dall'utente con uno generato dall'applicazione. Questo va fatto per ogni upload, qualunque sia il tipo di file.
Il luogo in cui il file viene salvato conta quanto il file stesso. Se possibile, conservare gli upload su un server diverso. Se non è possibile, conservarli fuori dalla webroot.
Quando i file devono essere raggiungibili pubblicamente, utilizzare un handler interno all'applicazione che associ un identificativo a un file (someid a file.ext), invece di esporre il percorso di archiviazione.
Altri due punti dell'elenco si dimenticano facilmente:
- Solo gli utenti autorizzati devono poter caricare file.
- Proteggere l'upload dagli attacchi CSRF.
Analizzare ed elaborare ciò che si conserva
La validazione verifica che un file abbia l'aspetto corretto. La cheat sheet aggiunge un ulteriore passaggio: far passare il file attraverso un motore antivirus o una sandbox, se disponibili, per verificare che non contenga dati dannosi.
Per i tipi di documento a cui si applica, come PDF e DOCX, si valuti l'impiego di CDR (Content Disarm & Reconstruct) come ulteriore fase di elaborazione.
La cheat sheet afferma inoltre che tutte le librerie utilizzate devono essere configurate in modo sicuro e mantenute aggiornate. Poiché le vulnerabilità dei parser rientrano tra le minacce citate, questo è il punto da assegnare a una persona precisa, con una data di revisione.
Testare ogni endpoint
La cheat sheet elenca controlli, non casi di test. Ogni riga della tabella seguente è una nostra derivazione dalla sua checklist, e la terza colonna indica da quale punto proviene. Eseguire i test su ogni endpoint di upload, inclusi gli strumenti di amministrazione e quelli aggiunti per un singolo cliente.
| Test | Esito positivo | Base |
|---|---|---|
| Caricare un file di script rinominato con un'estensione consentita | Rifiutato dopo la validazione del tipo di file | Derivato: validare il tipo di file |
Inviare un file non consentito con un Content-Type consentito | Rifiutato comunque | Derivato: non fidarsi dell'header Content-Type |
| Inviare un nome di file molto lungo | Rifiutato, oppure sostituito da un nome generato | Derivato: limite di lunghezza del nome, nomi di file generati |
| Caricare un file oltre il limite di dimensione | Rifiutato | Derivato: limite di dimensione del file |
| Richiedere il file salvato indovinandone il percorso | Non raggiungibile se non tramite l'handler | Derivato: posizione di archiviazione, handler con mappatura |
| Caricare un file senza sessione, o senza token CSRF | Rifiutato | Derivato: utenti autorizzati, protezione CSRF |
| Caricare una ZIP bomb o una XML bomb in un ambiente di test | Il servizio resta disponibile | Derivato: minaccia alla disponibilità |
Come riferimento più ampio, la OWASP Web Security Testing Guide si definisce la risorsa di riferimento per il testing di cybersecurity destinata agli sviluppatori di applicazioni web e ai professionisti della sicurezza. L'OWASP Application Security Verification Standard fornisce requisiti numerati rispetto ai quali effettuare la verifica. Se ne cita uno in un ticket o in un report, indichi anche la versione, ad esempio v5.0.0-1.2.5, perché gli identificativi possono cambiare tra una versione e l'altra dello standard.
Da dove iniziare
- Elencare ogni endpoint che accetta un file, inclusi strumenti di amministrazione, funzioni di import e plugin obsoleti.
- Per ciascuno, definire le estensioni consentite, la dimensione massima del file e la lunghezza massima del nome, e applicare la input validation prima del controllo dell'estensione.
- Sostituire i nomi di file forniti dall'utente con nomi generati. Spostare l'archiviazione su un server separato o fuori dalla webroot e servire i file pubblici tramite un handler che associ gli ID ai nomi dei file.
- Aggiungere la validazione del tipo di file e della signature, un passaggio con antivirus o sandbox e CDR per i tipi di documento accettati. Verificare che le librerie di parsing siano aggiornate e configurate in modo sicuro.
- Trasformare la tabella dei test in verifiche automatizzate ed eseguirle prima di ogni rilascio. Se desidera una revisione esterna del risultato, il nostro servizio di penetration test può testare gli endpoint, e il nostro supporto allo sviluppo software sicuro può esserle utile se la funzione è ancora in fase di progettazione. La guida OWASP sull'upload di file funge in entrambi i casi da checklist di revisione.
