Rischi per la sicurezza dei sistemi di upload-download di file

Question

Rischi per la sicurezza dei sistemi di upload-download di file

#1 da (2 voti)
#2 da (2 voti)

3

So che ci sono molti post su questi argomenti. Ma questi post di solito parlano di limitare i tipi di file e le dimensioni su così via. Quindi non serve ai miei bisogni in quanto il mio sistema non ha vincoli.

Diciamo che abbiamo un'applicazione web, che accetta i caricamenti dagli utenti che hanno effettuato l'accesso. Questi utenti sono autenticati tramite Active Directory. Gli utenti anonimi non sono ammessi.

Gli utenti possono caricare qualsiasi tipo di file nel sistema. Quindi gli utenti possono visualizzare in anteprima i file caricati tramite il nostro visualizzatore multiuso. Al momento supportiamo alcuni tipi di file di base, come immagini, musica, video, file PDF e file di Office. Decido per i tipi visualizzabili controllando un dizionario per i tipi visualizzabili e, se il tipo non esiste, non verrà visualizzato in anteprima ma scaricato direttamente.

Sono curioso dei rischi per la sicurezza che ho, quindi cercherò di elaborare il mio sistema.

Ho due sistemi diversi in termini di procedura di conservazione dei file:

Un'applicazione Internet in cui lo spazio di archiviazione è un file system strutturato in cui i nomi dei file vengono modificati con i GUID
Un'applicazione intranet in cui lo spazio di archiviazione è un file system non strutturato in cui i file si trovano direttamente sull'unità di rete mentre l'utente li carica e gli utenti possono accedere ai file anche tramite l'unità di rete

Per entrambe le applicazioni la strategia di anteprima è la stessa.

Tutti i file sono forniti da un metodo di azione a cui è possibile accedere solo se autenticati. E l'attraversamento del percorso logico per i file caricati è consentito .

I file non di ufficio vengono restituiti al client e visualizzati in img , video e embed tag html.

D'altro canto, i file di Office vengono prima eseguiti tramite librerie di interoperabilità di Microsoft Office, convertiti in PDF, quindi restituiti al client e visualizzati di nuovo come un normale pdf.

Mi chiedo, attraverso questi processi sto compromettendo qualsiasi sicurezza qui sul lato server? So che l'utente può caricare file dannosi, ma c'è un modo in cui l'utente può danneggiare il mio sistema durante la scrittura o la lettura dei file?

asp.net-mvc file-upload

posta Tolga Evcimen 23.01.2017 - 06:40

fonte

2 risposte

Leggi altre domande sui tag asp.net-mvc file-upload

Le server farm Anti DDoS sono davvero efficaci? Ci sono state proposte per l'automazione della concessione e del rinnovo del certificato EV?

score 2 · Answer 1

Dal punto di vista del server, stai permettendo ad altri di mettere le cose direttamente nel file system senza (molta) validazione. L'archiviazione del database è relativamente più sicura, poiché i dati binari non sono direttamente eseguibili. Tuttavia, la memorizzazione diretta dei file utilizzando il file system del sistema operativo ha prestazioni migliori.

Se i file sono archiviati su una memoria di file, un attacco mirato potrebbe essere quello di caricare un file appositamente predisposto sul server, quindi in qualche modo attivare il server per elaborarlo (sia esso un xml, zip, exe ecc.).

Per lo meno, è necessario modificare le autorizzazioni della cartella contenente i file caricati dall'utente in modo che non siano eseguibili. Farei un ulteriore passo avanti e sostituire a livello di codice tutte le estensioni di file con qualcosa come .exe_ , .pdf_ . Dopotutto, non è necessario archiviare i file nel modo in cui vengono caricati, è sufficiente per presentare i dati nella logica dell'applicazione. Se si modifica l'estensione del file, si spera che si rompano qualsiasi associazione di tipi di file o meccanismi di auto-trigger.

score 2 · Answer 2

In genere, il percorso regolare sul web hacking potrebbe essere riassunto in modo rapido come:

Trova una vulnerabilità (scansione, impronte digitali, ecc.)
sfruttare la vulnerabilità
Scrivi una specie di payload / shell malvagio o qualsiasi altra cosa
Accedi / esegui quella roba malvagia
Sempre più domande non importanti per questa domanda dopo questo.

Sul tuo sistema, il terzo punto è gratuito !. Non sto dicendo che sarai hackerato. Ma con un sistema come questo stai mettendo le cose un po 'più facilmente se i passaggi precedenti sono stati completati, questo è tutto.

Ricorda che solo un punto debole e tutto è possibile. Ovviamente il più pericoloso è l'iniezione diretta di comandi. Se non è presente ok, ma forse dopo aver sfruttato altre vulnerabilità potrebbe essere possibile avviare qualche tipo di comando nel sistema, ad esempio tramite SQL injection. A seconda dei sistemi, dei database e delle versioni, potrebbe essere possibile eseguire comandi di sistema dal database.

Quindi, attenzione a TUTTI! Iniezione XSS, iniezione SQL, iniezione comandi, CSRF, RFI, ecc.

E, naturalmente, controlla la versione di TUTTI i tuoi componenti (server web, kernel, sistema operativo, ecc.). Se utilizzi un componente con vulnerabilità note potresti essere hackerato anche con un buon sviluppo nel lato app.