TL; DR
Salviamo il carico utile della richiesta e l'intestazione Content-Type in un database. Dovrebbe essere JSON o CSV ma potrebbe non essere corretto. Supporta gli utenti a scaricare il carico utile della richiesta come file nei loro browser utilizzando Content-Disposition: attachment . Tentiamo di aggiungere un'estensione di file di .json o, l'impostazione predefinita, ".csv".
In che modo gli utenti dell'assistenza possono scaricare questo file in modo sicuro quando può contenere assolutamente qualcosa? Sono meno preoccupato per gli attacchi con tipo di bomba ZIP ma più spyware, ransomware, ecc. Ecc.
Sfondo
Abbiamo un'API REST che supporta sia i tipi di contenuti JSON e CSV.
L'API è protetta con un certificato client univoco per ciascun utente.
Per ragioni di arbitrato, dobbiamo tenere un registro di controllo del contenuto esatto inviato al servizio, lo facciamo memorizzando i byte direttamente nel database insieme all'intestazione del tipo di contenuto e ad altri campi dall'URL e dal certificato del cliente. Tutto ciò, ad eccezione del certificato, è la pre-convalida poiché è necessario registrare anche invii non validi.
Abbiamo un team di supporto molto attivo per loro è aiutare gli utenti che non sono in grado di inviare i loro documenti a causa di un contenuto malformato o b) il contenuto viola alcune regole aziendali.
Ora è arrivato il requisito di consentire al nostro team di supporto di scaricare le informazioni di controllo in modo che possano provare a riprodurre il problema degli utenti inviandolo a un sistema di test o semplicemente guardando il contenuto per individuare errori.
Forniremo un link al file con estensione .csv o .json se possiamo rilevare il tipo di contenuto.
Il problema
Ovviamente questo è ampiamente aperto a XSS dal punto dei campi non convalidati, ma questo è mitigato abbastanza facilmente codificandolo correttamente per la visualizzazione, ma non vedo come questo sia possibile per il file scaricato.
Ad esempio, invio un foglio di lavoro Excel con Content-Type: text/csv , un utente di supporto scarica il file e apre in Excel per visualizzare il CSV e viene avvisato "l'estensione del file non corrisponde al contenuto, vogliono comunque aprirsi ?" a cui fanno clic su "sì" perché stanno cercando di capire perché è malformato e il mio foglio di calcolo dannoso è aperto.
Anche se rimuoviamo il requisito dell'estensione del file, un utente di supporto potrebbe provare ad aprirlo in Excel comunque, visto che il contenuto dovrebbe essere un CSV.
Soluzioni
Non riesco a pensare a soluzioni solide;
- Allenare gli utenti del supporto per aprire prima in editor di testo semplice, ma gli utenti sono fallibili)
- Previene il download di contenuti che non sono dati di carattere, ma i dati di carattere possono ancora essere un vettore di attacco, ovvero un file
.bate non soddisfano i requisiti - Codifica il contenuto e visualizza sullo schermo copia / incolla assicurandoti che sia solo testo, i file potrebbero essere grandi e attualmente utilizzano lo streaming dal DB allo stream di output per mantenere basso il sovraccarico della memoria.
- Fidati dei nostri utenti e mantengono i loro certificati client al sicuro
È solo che i requisiti saranno sempre in disaccordo con la sicurezza e non c'è modo di scaricare i file inviati dall'utente in sicurezza?