<\/p>\n
Nelle ultime settimane abbiamo trattato sul blog diverse intestazioni HTTP relative alla sicurezza, ma la pi\u00f9 importante di tutte \u00e8 la Content-Security-Policy<\/a>(CSP). Il capo, sia per il livello di protezione che offre, ma purtroppo anche per la difficolt\u00e0 di implementarlo correttamente al primo colpo. Come tutte le regole di gestione del traffico di flightPATH di cui abbiamo parlato di recente, le utilizziamo noi stessi per proteggere il sito web edgeNEXUS e i suoi visitatori. <\/p>\n Abbiamo fatto il duro lavoro e provato il dolore per non costringerti a farlo, ma \u00e8 innegabile che sia necessaria una certa riflessione e pianificazione prima dell \u201cimplementazione. Ma ne vale la pena. Il concetto alla base di questa intestazione \u00e8 piuttosto semplice<\/a> e altrettanto potente. In poche parole, lo usi per specificare le origini consentite dei contenuti che possono essere caricati sul tuo sito web. In questo modo si ottiene una forte protezione contro una serie di attacchi di tipo code-injection diffusi nell\u201d Internet sempre pi\u00f9 dinamico di oggi, come il Cross Site Scripting (XSS) e il Clickjacking. <\/p>\n I tipi di contenuto che possono essere controllati includono: JavaScript, CSS (s\u00ec, i CSS possono essere pericolosi), frame HTML, font, immagini e oggetti incorporabili come le applet Java. \u00c8 bello avere cos\u00ec tante opzioni, ma \u00e8 qui che sorge la difficolt\u00e0. I siti web di oggi (compresi i nostri) contengono una moltitudine di questi tipi di contenuti provenienti da diverse fonti e identificarli e tenerne conto in un regolamento pu\u00f2 essere un’impresa ardua. <\/p>\n Prima di entrare nel merito, diamo un \u201cocchiata agli elementi del valore dell\u201d intestazione e all \u201caspetto di un criterio. Come vedrai, si tratta essenzialmente di un lungo elenco di tipi di contenuto (che in questo esempio terminano tutti con -src) e delle fonti consentite per ciascun tipo. L\u201d insieme di questi elementi \u00e8 noto come direttive di policy. <\/p>\n default-src \u201cself\u201d data:; script-src \u201cself\u201d \u201cunsafe-inline\u201d; connect-src \u201cself\u201d; img-src \u201cself\u201d data:; style-src \u201cself\u201d \u201cunsafe-inline\u201d data:; font-src \u201cself\u201d data:; child-src \u201cself\u201d<\/strong><\/p>\n Ci sono altri tipi di contenuti che possiamo prendere in considerazione, ma quelli mostrati sopra sono le direttive pi\u00f9 importanti (secondo noi, in base al rischio e alla diffusione). Ecco i dettagli sui contenuti a cui ciascuno di essi si riferisce; <\/p>\n Questi tipi di contenuto e i loro valori sono separati l \u201cuno dall\u201d altro (delimitati) con un punto e virgola. Ogni tipo pu\u00f2 avere uno o pi\u00f9 dei seguenti valori; <\/p>\n Per delimitare ogni valore viene utilizzato un semplice spazio. Gli apici singoli \u201csono obbligatori a meno che il valore non sia un nome di dominio. Si noti che le estensioni e i plugin del browser sono esenti, in quanto sono considerati sicuri in quanto ritenuti affidabili dall\u201d utente (che li ha installati). <\/p>\n Tutto ci\u00f2 sembra piuttosto tecnico e complesso, ma se lo affrontiamo un passo alla volta \u00e8 piuttosto veloce arrivare a una politica. Vediamo rapidamente due esempi. Innanzitutto, proviamo un semplice sito web interno servito via HTTP. Ecco cosa ci serve; <\/p>\n Il valore completo dell’intestazione \u00e8 ragionevolmente breve:<\/p>\n default-src \u201cself\u201d data:; script-src \u201cself\u201d \u201cunsafe-inline\u201d; connect-src \u201cself\u201d; img-src \u201cself\u201d data:; style-src \u201cself\u201d \u201cunsafe-inline\u201d data:; font-src \u201cself\u201d data:<\/strong><\/p>\n In secondo luogo, un sito web protetto da SSL\/TLS che utilizza Google Analytics (GA), CSS inline, font e immagini, CSS del tuo sito e immagini di altri siti web. Vediamo cosa ci serve pezzo per pezzo (non \u00e8 molto diverso); <\/p>\n Sommando il tutto si ottiene questa polizza leggermente pi\u00f9 lunga:<\/p>\n default-src \u201cself\u201d data: https:; script-src \u201cself\u201d \u201cunsafe-inline\u201d *.google-analytics.com https:; img-src \u201cself\u201d \u201cunsafe-inline\u201d * https:; style-src \u201cself\u201d \u201cunsafe-inline\u201d https:; font-src \u201cself\u201d \u201cunsafe-inline\u201d https:<\/strong><\/p>\n Direi che \u00e8 abbastanza facile. In passato Google non era cos\u00ec “amichevole” nei confronti del CSP (questo valore dell’intestazione era lungo almeno il doppio), ma fortunatamente negli ultimi tempi ha fatto passi da gigante. Noterai che non abbiamo dovuto aggiungere il dominio *.google-analytics.com allo script-src come valore del tipo di contenuto, poich\u00e9 il loro codice viene eseguito come script inline.<\/p>\n L’ideale sarebbe creare un criterio per ogni pagina del tuo sito web, dato che le risorse caricate variano senza dubbio da una pagina all’altra, ma questo \u00e8 piuttosto oneroso ed \u00e8 molto pi\u00f9 semplice, ma comunque efficace, creare un criterio che copra tutte le possibili fonti. La maggior parte degli esempi presenti sulla nostra pagina GitHub seguono questo approccio, ma ce n’\u00e8 anche uno che ti permette di fornire una maggiore protezione a pagine specifiche. <\/p>\n Per i test e la risoluzione dei problemi, ti consiglio di utilizzare gli Strumenti per sviluppatori di Google Chrome. Vai al sito in questione, premi F12, clicca su Rete, assicurati che sia spuntata la voce Disattiva cache e poi ricarica la pagina. Eventuali errori saranno evidenziati chiaramente. In fondo a questo blog c’\u00e8 una schermata di ci\u00f2 che potresti vedere se il tuo criterio blocca unsafe-inline<\/strong> e stai usando Google Analytics; i messaggi di errore sono molto utili. <\/p>\n Regola i tuoi criteri se necessario e ripeti l \u201coperazione. L\u201d ideale sarebbe utilizzare un servizio virtuale di prova dedicato con la regola flightPATH applicata, ma che serva lo stesso sito, solo attraverso un IP virtuale diverso, in modo da non influenzare i clienti reali durante i test. <\/p>\n Come sempre, l \u201cenorme vantaggio dell\u201d utilizzo di un bilanciatore di carico \u00e8 che dobbiamo effettuare queste operazioni in un unico punto centrale per proteggere tutti i nostri server (e siti). Non dobbiamo affidarci a sviluppatori o a riconfigurazioni del server web. Sul bilanciatore di carico edgeNEXUS dobbiamo semplicemente importare un modello di configurazione automatica jetPACK e assegnare una regola di traffico flightPATH a qualsiasi Servizio Virtuale che desideriamo proteggere (dopo le opportune modifiche). <\/p>\n La regola aggiunge l’intestazione solo se non esiste, quindi funzioner\u00e0 anche se i nostri server web la inseriscono gi\u00e0 o magari la inseriscono solo per pagine specifiche. Questa regola dovrebbe far parte della configurazione standard del tuo Servizio Virtuale: non hai nulla da perdere, qualunque sia il sito, anche se ovviamente \u00e8 sempre consigliabile fare delle prove. Puoi scaricare questo jetPACK e molti altri sul sito Github di edgeNEXUS<\/a>. <\/p>\n flightPATH \u00e8 un motore di regole dinamico e basato sugli eventi sviluppato da edgeNEXUS per manipolare e instradare in modo intelligente il traffico IP, HTTP e HTTPS in modo bilanciato. \u00c8 altamente configurabile e potente, ma molto facile da usare. <\/p>\n Se vuoi saperne di pi\u00f9, vale la pena di leggere questi link correlati;<\/p>\n http:\/\/www.html5rocks.com\/en\/tutorials\/security\/content-security-policy\/<\/a><\/p>\n https:\/\/developer.mozilla.org\/en\/docs\/Web\/Security\/CSP\/CSP_policy_directives<\/a><\/p>\n\n
\n
\n
\n