Scenari di attacco di esempio sui download di file su HTTP

Question

Scenari di attacco di esempio sui download di file su HTTP

#1 da (1 voti)

0

I siti web che servono file su https, possono essere considerati overkill? o è una buona pratica che tutti devono seguire?

Lo svantaggio di servire i file su HTTPS è che perderai il caching per quanto ho letto. Ma a parte questo, lo scenario di attacco che ho in mente è qualcuno che accede al server e manipola il file che HTTPS non aiuta molto a prevenire, o qualcuno che sostituisce il file con uno malevolo over-the-air in uno scenario MITM quale HTTPS può mitigare.

Quanto è probabile che ci sia uno scenario MITM in cui il client esegue il download di un eseguibile specifico?

Ci sono altri attacchi che HTTPS può impedire?

Un'altra soluzione adottata da alcuni siti Web è che inserisce il checksum dell'eseguibile sul sito Web, ma la maggior parte degli utenti non si preoccuperà di controllarlo o non saprà nemmeno come farlo.

Quindi, per riassumere, c'è molto guadagno nel servire i file su HTTPS (se un checksum viene messo sul sito insieme al file o meno) e può servire file su HTTP essere considerato un enorme difetto di sicurezza?

(Lo scenario esatto nella mia mente è che una banca sta permettendo ai clienti di scaricare la sua app di mobile banking tramite il suo sito web tramite http)

tls man-in-the-middle integrity

posta Silverfox 30.01.2016 - 06:23

fonte

1 risposta

Leggi altre domande sui tag tls man-in-the-middle integrity

Gli archivi di comunità / universo di Linux sono significativamente meno sicuri dei repository principali? samdump2 Errore nella lettura di ControlSet: _RegOpenKey

score 1 · Answer 1

Dipende molto dal tipo di dati che offri per il download e dal tipo di rapporto di fiducia tra l'utente e il tuo sito. Dai un'occhiata più da vicino a cosa offre HTTPS e cosa no:

Offre una sorta di privacy tramite crittografia. Se i dati sono già crittografati con altri mezzi, non è necessario un altro livello di crittografia. Se i dati sono destinati al consumo pubblico, non è necessario nascondere i dati utilizzando la crittografia.
Offre resistenza alla manomissione. Se i dati sono firmati in qualche modo e la firma viene definitivamente verificata, non è necessario aggiungere un altro livello per la resistenza alla manomissione. Spesso gli aggiornamenti firmware o software sono già protetti in questo modo.
Offre una sorta di autenticazione del sito che protegge contro gli attacchi dell'uomo nel mezzo. Ma non offre alcuna protezione se l'utente prende l'URL sbagliato, come un URL simile o attendibile durante un attacco di phishing.
Offre una sorta di privacy per nascondere quale file viene scaricato. Ma non nasconde l'accesso al sito stesso, ma nasconde solo l'URL specifico visitato su questo sito. Ed è spesso possibile scoprire quale file è stato caricato dal sito a causa dei metadati come la quantità di byte trasferiti.

Ciò significa che, a seconda del caso d'uso, HTTPS può essere d'aiuto, ma in ogni caso non offre più protezione. E offre meno protezione si potrebbe presumere. Soprattutto è ancora possibile scaricare malware utilizzando HTTPS perché su entrambi è stato utilizzato l'URL sbagliato (phishing) o il server stesso è stato compromesso e serve il malware.

A parte questo, di solito non fa male aggiungere HTTPS se hai le risorse, non importa se il tuo caso d'uso ne trae davvero profitto. La maggior parte degli utenti non capisce davvero la complessità di ciò che offre HTTPS e cosa no, ma si sentono più sicuri con https. Quindi potresti semplicemente dare loro un'illusione di sicurezza, cioè il teatro della sicurezza.