L'intestazione di Content Security Policy fornisce un falso senso di sicurezza se una pagina viene pubblicata su HTTP non crittografato?

Does it then give the developer a false sense of security ....

La comprensione del problema è corretta. Ma se questo fornisce allo sviluppatore un falso senso di sicurezza dipende dalla conoscenza dello sviluppatore.

Uno sviluppatore adeguatamente istruito dovrebbe sapere che con un attacco MITM riuscito tutto può essere cambiato nel traffico. Questo non è limitato solo alla modifica del CSP o all'iniezione di annunci pubblicitari, ma in realtà l'intero contenuto e il codice sulla pagina possono essere sostituiti con qualcosa di completamente diverso. Invece di bei gattini lanuginosi potrebbe servire qualche brutto malware.

La tua comprensione è corretta.

Tutto ciò che non è autenticato, crittografato e controllato per l'integrità non è sicuro. Punto. Puoi rendere l'aggressore un po 'più difficile per le cose, ma alla fine della giornata l'attaccante può entrare tra l'utente e il server, dopodiché tutte le puntate sono disattivate.

Qualcosa come l'iniezione di annunci richiede già di essere in una posizione MITM, quindi sì, possono semplicemente rimuovere le intestazioni CSP. Un attacco di massa che non è personalizzato potrebbe non essere abbastanza intelligente per farlo, ma non ci vorrà molto. La sicurezza end-to-end, come TLS, è l'unico modo per andare.

Per quel che vale, se devi assolutamente usare connessioni non protette e vuoi delle protezioni nella tua autenticazione (cioè resistente a qualsiasi cosa tranne un MITM), dai un'occhiata all'autore di digest. Non invia mai la password effettiva, o qualcosa di equivalente alla password, sul filo. Ha anche una certa resistenza per replicare gli attacchi. Potresti anche implementare qualcosa in JS, utilizzando la crittografia asimmetrica o SRP o simile. Ciò offre il vantaggio di essere in grado di trasmettere i dati crittografati, anche se sei ancora vulnerabile a un utente malintenzionato che ti ha appena iniettato JS che ruba i dati di solo testo non appena il tuo JS lo decripta.

Alla fine della giornata, però, è più difficile di TLS, per una sicurezza significativamente inferiore. Ci sono pochissime situazioni in cui non puoi assolutamente utilizzare TLS. Anche i certificati autofirmati possono essere importati in un browser o aggiungere un'eccezione per quel sito, e quindi l'utente sarà sicuro r che altrimenti, poiché l'autore dell'attentatore dovrebbe presentare il proprio cert ( che non ha ancora un'eccezione) e che attiverà un altro avviso nel browser.

Una buona domanda. CSP controlla il comportamento del browser DOPO il contenuto HTTP ha già raggiunto il browser. Ad esempio da quali immagini del dominio è possibile caricare. Fornisce protezione a livello di applicazione. Gli attacchi Man-in-the-middle (MiTM) d'altra parte si verificano a livello di trasporto, consentendo all'aggressore di modificare il contenuto, comprese le intestazioni HTTP PRIMA che raggiungono il browser.

Ciò significa che la protezione fornita dall'intestazione CSP può essere negata se il contenuto viene pubblicato su un semplice HTTP. Tuttavia gli attacchi MiTM richiedono un accesso speciale al percorso di comunicazione tra browser e server. Se questo accesso non esiste, ad esempio perché l'autore dell'attacco è remoto, elimina gli attacchi MiTM dall'equazione. Tuttavia, lascia l'applicazione aperta all'iniezione HTML, all'iniezione di annunci, all'iniezione di script, ecc. Tramite l'input di contenuto generato dall'utente nella pagina attraverso mezzi normali. Quindi CSP fornisce ancora un livello di protezione dagli autori di attacchi remoti.