Share
Grazie a HTML5, sempre più logiche di applicazioni vengono trasferite dal lato server al lato client. Ciò richiede agli sviluppatori front-end di concentrarsi maggiormente sulla sicurezza. In questo articolo ti mostrerò come rendere le tue app più sicure. Mi concentrerò su tecniche di cui forse non hai sentito parlare, invece di dirti semplicemente che devi sfuggire ai dati HTML inseriti dagli utenti.
Ovviamente non voglio che tu serva i tuoi contenuti con FTP o con il semplice TCP. Quello che voglio dire è che se vuoi che i tuoi utenti siano al sicuro quando usi il tuo sito web, devi usare SSL (HTTPS). E non solo per i siti di accesso o informazioni preziose. Per tutti i tuoi contenuti. Altrimenti, quando qualcuno accede alla tua app da una rete pubblica, ciò che vedono potrebbe essere malformato da qualche hacker all'interno di questa rete. Questo è chiamato un attacco principale nel mezzo:
Quando si utilizza SSL, tutti i dati vengono crittografati prima di essere inviati, quindi anche se l'autore dell'attacco lo ottiene, non sarebbe in grado di modificarlo o acquisirlo. Questo è di gran lunga il passo più importante per proteggere la tua app.
Questa intestazione HTTP può rivelarsi utile se desideri pubblicare i tuoi contenuti utilizzando solo SSL. Quando viene emesso dal server (o a tag, ma che permetterà ad almeno una richiesta di essere HTTP), nessun traffico insicuro verrà dal browser al tuo server. È usato così:
Strict-Transport-Security: max-age = 3600; includeSubDomains
Il includeSubDomains parte è facoltativa, ti consente di dichiarare che vuoi anche accedere a tutti i sottodomini utilizzando HTTPS. Il max-age opzione imposta per quanto tempo (in secondi) le pagine dovrebbero essere servite usando SSL. Purtroppo, solo Firefox, Chrome e Opera supportano Strict Transport Security.
Un altro modo per migliorare ulteriormente la sicurezza su HTTP e HTTPS sono questi due attributi dei cookie: Sicuro e HttpOnly. Il primo consente di inviare un cookie solo sulla connessione SLL. Il secondo può sembrare l'esatto opposto, ma non lo è. Indica al browser che è possibile accedere al cookie solo utilizzando il protocollo HTTP (S), quindi non può essere rubato utilizzando, ad esempio, JavaScript document.cookie.
La politica di sicurezza dei contenuti consente di definire l'origine di tutti gli script, le immagini, ecc. Sul tuo sito.
Se pensi che il tuo filtro XSS interromperà tutti i possibili attacchi XSS, controlla quanti modi ci sono per eseguire questi attacchi e ripensaci. Naturalmente proteggere la tua app per fermare tutti questi potrebbe essere un problema e potrebbe rallentarlo, ma c'è una soluzione.
Si chiama Content Security Policy. Ti permette di definire l'origine di tutti gli script, le immagini ecc. Sul tuo sito. Blocca anche tutti gli script e gli stili inline, quindi anche se qualcuno può iniettare un tag script in un commento o in un post, il codice non verrà eseguito. Il CSP è un'intestazione HTTP (che può anche essere impostata usando HTML tag), che assomiglia a questo:
Content-Security-Policy: policy
Dove politica è un insieme di direttive CSP. Ecco le opzioni possibili:
Se una direttiva non è impostata, il browser presume che tutte le origini siano consentite. Questo può essere cambiato impostando il default-src opzione. Ciò che imposti verrà applicato a tutte le direttive non impostate. C'è anche un sandbox opzione, che fa caricare la pagina web come un iframe con sandbox attributo. Un esempio di utilizzo dell'intestazione CSP sarebbe simile a questo:
Content-Security-Policy: default-src: 'self'; script-src: https://apis.google.com;
Consente a tutti gli asset di essere caricati solo dall'origine dell'applicazione (il file 'se stesso' attributo) e consente inoltre di caricare script dal server API di Google. C'è molta flessibilità nella definizione di CSP e, se usato correttamente, migliorerà notevolmente la sicurezza della tua pagina web.
La cosa da ricordare quando si utilizza CSP è che, per impostazione predefinita, tutto il codice JavaScript non in linea non verrà eseguito. Questo include anche:
Accentsconagua
javascript URL: piace Questo perché il browser non è in grado di distinguere il tuo codice inline dal codice inline dell'hacker. Dovrai sostituirli aggiungendo listener di eventi addEventListener o qualche equivalente di quadro. Questa non è una cosa negativa, in quanto ti costringe a separare la logica della tua applicazione dalla sua rappresentazione grafica che dovresti comunque fare. Anche CSP (di default) blocca tutto eval ()-codice ish, incluse le stringhe in setInterval/setTimeout e codice come nuova funzione ('return false').
CSP è disponibile nella maggior parte dei browser moderni. Firefox, Chrome e Opera (anche quelli mobili) usano lo standard Content-Security-politica intestazione. Safari (anche iOS) e Chrome per Android utilizzano il X-WebKit-CSP intestazione. IE10 (con supporto limitato solo a sandbox direttiva) utilizza X-Content-Security-politica. Quindi, grazie a Internet Explorer, non puoi usare solo CSP (a meno che non usi qualcosa come Google Chrome Frame), ma puoi ancora usarlo per migliorare la sicurezza sui browser reali e preparare la tua app per il futuro.
JSONP è attualmente la tecnica più utilizzata per ottenere risorse da altri server nonostante la politica della stessa origine. Di solito, si crea semplicemente la funzione di callback nel codice e si passa il nome di quella funzione all'URL da cui si desidera ottenere i dati, in questo modo:
function parseData (data) ...
Ma così facendo, stai creando un grosso rischio per la sicurezza. Se il server dal quale si ricevono i dati viene compromesso, un hacker può aggiungere il suo codice dannoso e, ad esempio, rubare i dati privati dell'utente, perché in realtà stai utilizzando JavaScript per questa richiesta e il browser eseguirà tutto il codice solo come con un normale file di script.
La soluzione qui è Cross Origin Resource Sharing. Consente al provider di dati di aggiungere un'intestazione speciale nelle risposte in modo da poter utilizzare XHR per recuperare tali dati, quindi analizzarli e verificarli. Ciò elimina il rischio di esecuzione di codice dannoso sul tuo sito.
L'implementazione richiede al provider solo di aggiungere la seguente intestazione speciale nelle risposte:
Access-Control-Allow-Origin: origini consentite
Possono essere solo alcune origini consentite separate da spazi o un carattere jolly: * lasciare che ogni origine richieda i dati.
Tutte le versioni attuali dei browser moderni supportano CORS, ad eccezione di Opera Mini.
Naturalmente, il problema più grande qui è che i service provider dovrebbero aggiungere il supporto CORS, quindi non è completamente dipendente dallo sviluppatore.
Un iframe con il
sandboxl'attributo non sarà in grado di navigare nella finestra, eseguire script, bloccare il puntatore, mostrare pop-up o inviare moduli.
Se si utilizzano iframe per caricare contenuti da siti esterni, si consiglia di proteggerli. Questo può essere fatto usando il sandbox attributo iframe. Un iframe con tale attributo vuoto (ma presente) non sarà autorizzato a navigare nella finestra, eseguire script, bloccare il puntatore, mostrare popup o inviare moduli. La cornice avrà anche un'origine unica, quindi non può essere utilizzata memoria locale o qualsiasi cosa relativa alla politica della stessa origine. Ovviamente puoi permetterne alcuni, se vuoi, aggiungendo uno o più di questi valori all'attributo:
Il sandbox l'attributo iframe è supportato in tutti i browser moderni, ad eccezione di Opera Mini.
Quindi è così. Spero che tu abbia imparato alcune nuove tecniche che puoi usare nei tuoi progetti futuri per proteggere le tue applicazioni. Grazie a HTML5, ora possiamo fare cose straordinarie con i nostri siti Web, ma dobbiamo pensare alla sicurezza dalla prima riga di codice se vogliamo che siano resistenti agli attacchi.
