Caso d'uso della difesa CSRF
Si dispone di un dispositivo integrato che supporta l'interfaccia utente Web basata su HTTP su un indirizzo IP privato.
Ha senso implementare la difesa CSRF su HTTP (non HTTPS)?
Risposte
Se una richiesta HTTP è in grado di cambiare stato, potrebbe essere necessaria la protezione CSRF. Il fatto che la richiesta sia crittografata o meno a livello di trasporto ha poca o nessuna relazione con questo.
Senza la protezione CSRF, un utente malintenzionato che ti convince a visitare il suo sito Web o anche una singola risorsa potrebbe essere in grado di inviare richieste al tuo dispositivo integrato e assumerne il controllo, se il browser della vittima è correttamente autorizzato o se l'autenticazione è insufficiente o non funzionante. Ciò accade indipendentemente dal fatto che vengano utilizzati HTTP o HTTPS.
Sì, idealmente tutto sarebbe su HTTPS. Tuttavia, l'opzione "migliore" per la maggior parte dei fornitori in questo momento è quella di fornire dispositivi incorporati con certificati autofirmati che, oltre ad essere utili per la fiducia al primo utilizzo e contrastare lo sniffing passivo, non sono molto meglio del semplice HTTP in molti scenari. Spesso, l'utente riceve comunque un avviso di certificato e fa clic su di esso. Fino a quando questo problema non sarà risolto, le prospettive HTTPS sui dispositivi embedded sono ancora pessime.
(Risolvendo le tue modifiche ora cancellate) In effetti, XSS ignora le mitigazioni CSRF. Tuttavia, il modello di minaccia sembra un po' diverso qui, dal momento che è molto meno probabile che un avversario sia in grado di sfruttare un XSS nel tuo dispositivo integrato rispetto a un problema CSRF, dal momento che dovrebbe raggiungere il dispositivo nel primo caso.
Senza la difesa CSRF, un utente malintenzionato potrebbe falsificare un'e-mail (magari con un indirizzo contraffatto decentemente mirato) con un avviso di monitoraggio, che ti dice di controllare perché c'è un problema critico. All'interno dell'e-mail potrebbe esserci un collegamento a http://yourswitch/factory_reset.
I vettori di attacco possono variare.
A meno che tu non utilizzi un FQDN o un indirizzo IP predefinito (ad esempio, l'onnipresente 192.168.1.1) per quel dispositivo, questo specifico tipo di attacco sarebbe piuttosto mirato. Un utente malintenzionato dovrebbe creare una richiesta allo switch che in realtà fa qualcosa di "interessante" (questo richiede la conoscenza di FQDN/IP e fornitore/modello per ottenere un percorso utile) e inviarti questo collegamento in un modo che non aumenti troppo le tue sopracciglia (l'e-mail da Internet sarebbe strana. Forse qualcosa che falsifica un'e-mail di monitoraggio senza risposta che usi?).
Come al solito, si tratta di comprendere il modello di minaccia e il rapporto costo/beneficio delle contromisure.
Sì.
Nel caso di uno switch di rete o di un router, gli attacchi tipici che potrebbe subire sarebbero la riconfigurazione del dispositivo (come l'inoltro di una porta interna verso l'esterno), la modifica dei DNS che fornisce a quelli dannosi, ecc. Queste azioni dovrebbero richiedere autenticazione, ma dovresti tener conto del fatto che potrebbe utilizzare anche una password predefinita invariata.
(e sì, questo genere di cose accadono in natura)
Il fatto che sia basato su un indirizzo privatohttp://192.168.1.1non fornisce alcuna protezione, in quanto l'attacco verrebbe da una pagina web malevola, inviando attraverso il browser di un utente all'interno della rete una richiesta malevola che -accettata per mancanza di protezione CSRF- configurerebbe male lo switch.
Mozilla Firefox ha aperto il bug 354493 per 14 anni, il che eviterebbe attacchi da indirizzi non RFC-1918 a indirizzi RFC 1918, ma finora non è stato implementato.