‫Quindi, tutto ciò che abbiamo fatto finora in questa
‫sezione è stato quello di proteggere tutte
‫le applicazioni e i dati dei nostri utenti nel miglior modo possibile.
‫E ho parlato di molte cose che
‫possiamo fare per raggiungere questo obiettivo.
‫Ma tutte queste informazioni
‫erano sparpagliate in tutte queste conferenze.
‫Quindi ho deciso di creare questo
‫breve riepilogo con molte best practice che abbiamo già
‫implementato e che implementeremo ancora nel
‫resto di questa sezione.
‫Perché la sicurezza è estremamente importante,
‫ma sfortunatamente molti corsi non la affrontano abbastanza.
‫Ora, non sto
‫nemmeno trasformando questo Node. js in un corso di sicurezza.
‫Ci sono corsi ed esperti migliori per questo.
‫Ma ti mostrerò un paio di
‫cose che puoi fare per proteggere adeguatamente le tue applicazioni e i tuoi dati.
‫E esaminerò un paio di attacchi
‫comuni e darò alcuni suggerimenti per prevenirli.
‫E per prima cosa, abbiamo l'evento di un database compromesso,
‫il che significa che un utente malintenzionato ha ottenuto l'accesso al nostro database.
‫Certo, questo è un problema estremamente grave, ma
‫per prevenire problemi ancora più grandi,
‫dobbiamo sempre crittografare le password e i token di reimpostazione della password
‫proprio come abbiamo fatto nei video in questa sezione.
‫In questo modo, l'attaccante non
‫può almeno rubare le password dei nostri utenti e nemmeno reimpostarle.
‫Ora, per quanto riguarda la prevenzione
‫degli attacchi, parliamo dell'attacco di forza
‫bruta in cui l'attaccante cerca sostanzialmente di indovinare
‫una password provando milioni e milioni di password casuali
‫finché non trovano quella giusta.
‫E quello che possiamo fare è rendere la richiesta di accesso molto lenta.
‫E il pacchetto bcrypt che
‫stiamo usando in realtà fa proprio questo.
‫Un'altra strategia consiste nell'implementare la limitazione della velocità,
‫che limita il numero di
‫richieste provenienti da un singolo IP.
‫E questo lo
‫implementeremo in uno dei prossimi video.
‫Inoltre, una buona strategia consiste nell'implementare effettivamente
‫un numero massimo di tentativi di accesso per ciascun utente.
‫Ad esempio, potremmo fare
‫in modo che dopo 10 tentativi falliti,
‫l'utente debba attendere un'ora prima di poter riprovare.
‫Ora, non implementerò questa
‫funzionalità in questa sezione, ma
‫sentiti libero di sperimentarla da solo.
‫Probabilmente è un'esperienza di apprendimento davvero interessante codificare
‫da soli, e in realtà
‫non è così difficile.
‫Va bene.
‫Successivamente, c'è l'attacco di scripting tra siti, in
‫cui l'attaccante cerca
‫di iniettare script nella nostra pagina per eseguire il suo codice dannoso.
‫Dal lato dei client, questo è particolarmente
‫pericoloso perché consente all'attaccante di leggere l'archiviazione locale,
‫motivo per cui
‫non dovremmo mai archiviare il token Web JSON nell'archiviazione locale.
‫Invece, dovrebbe essere memorizzato in un cookie solo HTTP che fa
‫in modo che il browser
‫possa solo ricevere e inviare il
‫cookie ma non possa accedervi o modificarlo in alcun modo.
‫E quindi, ciò rende impossibile per qualsiasi
‫utente malintenzionato rubare il token Web JSON memorizzato nel cookie.
‫Ancora una volta, lo stiamo implementando in un secondo.
‫Ora, dal lato del backend, per prevenire attacchi XSS, dovremmo disinfettare
‫i dati di input dell'utente
‫e impostare alcune intestazioni HTTP speciali
‫che rendono un po' più difficile l'esecuzione di questi attacchi.
‫Ed Express non viene fornito con queste best
‫practice pronte all'uso, quindi utilizzeremo il middleware per
‫impostare tutte queste intestazioni speciali.
‫Successivamente, abbiamo attacchi di negazione del servizio.
‫E forse ne hai sentito parlare.
‫Succede quando l'attaccante
‫invia così tante richieste a un server che
‫si guasta e l'applicazione diventa non disponibile.
‫Anche in questo caso, l'implementazione della
‫limitazione della velocità è una buona soluzione.
‫Inoltre, dovremmo limitare la quantità di dati che
‫possono essere inviati in un corpo in un post o in una richiesta di patch.
‫Inoltre, dovremmo evitare di usare le
‫cosiddette espressioni regolari malvagie per essere presenti nel nostro codice.
‫E queste sono solo espressioni
‫regolari che impiegano un tempo esponenziale per essere eseguite per
‫input non corrispondenti e possono essere sfruttate per abbattere l'intera applicazione.
‫Ok, il prossimo passo è l'attacco di iniezione di query NoSQL.
‫E l'iniezione di query si verifica quando
‫un utente malintenzionato, invece di inserire dati validi, inserisce alcune
‫query per creare espressioni di
‫query che si tradurranno in true.
‫Ad esempio, per essere loggato anche
‫senza fornire un nome utente o una password validi.
‫È un po' complesso
‫e dovresti assolutamente cercarlo su Google per saperne di più.
‫Ma quello che devi sapere è che l'uso
‫di Mongoose è in realtà
‫una strategia abbastanza buona per prevenire questo tipo
‫di attacchi perché un buon schema forza ogni valore
‫ad avere una scheda dati ben definita.
‫Il che rende poi
‫effettivamente questo tipo di attacco molto difficile da eseguire.
‫Tuttavia, è sempre una buona idea
‫disinfettare ancora i dati di input, solo per essere sicuri.
‫E di questo ci occuperemo un po' più tardi.
‫Bene, e ora per
‫finire, ho solo un paio di best practice
‫e suggerimenti su come migliorare
‫i meccanismi di autenticazione e autorizzazione che abbiamo implementato.
‫Quindi, la prima cosa
‫che devo ripetere più e
‫più volte è che in un'applicazione
‫di produzione, tutte le comunicazioni tra server
‫e client devono avvenire tramite HTTPS.
‫Altrimenti, chiunque può ascoltare la conversazione e rubare
‫il nostro token web JSON.
‫Quindi, crea sempre token di password casuali.
‫Non generato da date o qualcosa del genere.
‫Poiché sono effettivamente password,
‫dovrebbero essere trattate come tali.
‫Inoltre, dai loro sempre le date di
‫scadenza, proprio come l'abbiamo implementato.
‫Va bene?
‫E abbiamo anche implementato che un determinato token Web
‫JSON non è più valido dopo che l'utente ha cambiato la sua password.
‫Quindi, in pratica revochiamo il
‫token non appena l'utente cambia la password.
‫Il che ha molto senso, ma ancora
‫una volta, molti tutorial là fuori semplicemente non lo fanno.
‫Un'altra cosa importante è non eseguire mai il commit
‫di un file di configurazione, come per le variabili di ambiente, su
‫un controllo di versione come Git.
‫In effetti, non caricarlo da nessuna
‫parte perché questo
‫file contiene i dati più sensibili dell'intera applicazione.
‫Ad esempio, se qualcuno ottiene l'accesso
‫al tuo segreto
‫token web JSON, l'intero processo di autenticazione viene compromesso.
‫Ok, e ora solo un piccolo dettaglio è che ogni volta
‫che si verifica
‫un errore, non inviare l'intero errore al client.
‫Quindi, cose come la traccia dello stack potrebbero fornire
‫all'attaccante alcune preziose informazioni sul tuo sistema
‫e quindi, ovviamente, non lo vogliamo.
‫Successivamente, possiamo utilizzare il pacchetto csurf per
‫combattere un tipo di attacco chiamato Cross-Site Request Forgery, che è
‫un attacco che costringe un utente
‫a eseguire azioni indesiderate su un'applicazione Web in cui
‫è attualmente connesso.
‫Tuttavia, non lo faremo in questa sezione.
‫Ma volevo ancora menzionarlo qui.
‫Successivamente, potremmo richiedere all'utente
‫di riautenticarsi prima di eseguire un'azione di alto valore.
‫Ad esempio, effettuare un pagamento o eliminare qualcosa.
‫Ancora una volta, questo è solo un suggerimento
‫che puoi provare tu stesso.
‫Un'altra caratteristica interessante che puoi implementare
‫è una lista nera di token non attendibili.
‫Quindi, sappiamo già che
‫non esiste davvero un modo per disconnettere gli
‫utenti dall'applicazione se mostrano attività dannose.
‫Ma quello che possiamo fare è creare un elenco di token non
‫attendibili che vengono poi convalidati ad ogni richiesta.
‫E poi, una funzione che avremmo potuto implementare è quella
‫di confermare l'indirizzo e-mail dopo la prima creazione di un account.
‫Quindi, in pratica, inviando un collegamento all'e-mail dell'utente,
‫come fanno in realtà molte app reali.
‫Ma volevo solo mantenere le cose semplici qui,
‫motivo per cui non l'ho fatto qui.
‫Ma sentiti libero di implementarlo da solo
‫se ne hai voglia.
‫Ora, una grande caratteristica di molte
‫app è il concetto di token di aggiornamento.
‫Che sono fondamentalmente per ricordare gli utenti.
‫Quindi, per tenerli connessi per
‫sempre o finché non decidono di disconnettersi.
‫La nostra attuale implementazione fa in
‫modo che l'utente debba sostanzialmente accedere di nuovo
‫dopo la scadenza del token Web JSON.
‫Ma, con i token di aggiornamento, non è più necessario.
‫Ed è un po' complesso da implementare e quindi
‫è una funzionalità per un'altra volta.
‫E infine, l'ultimo
‫che avremmo potuto implementare è l'autenticazione a due fattori,
‫che sono sicuro ti sia familiare.
‫Fondamentalmente, con l'autenticazione a due fattori,
‫dopo aver effettuato l'accesso all'applicazione, l'utente
‫deve eseguire
‫una seconda azione per essere realmente autenticato.
‫E in genere, è quello di inserire un
‫codice inviato tramite messaggio di testo a un telefono cellulare.
‫Quindi, queste sono molte funzionalità che
‫la nostra autenticazione potrebbe avere.
‫E se vuoi che ne implementi qualcuno,
‫per favore fammelo sapere nella sezione Domande e risposte.
‫E, se c'è molta richiesta per uno di
‫loro, allora ti mostrerò come funziona.
‫Ok, ma ancora una volta, non volevo trasformare
‫questo Node. js in
‫un intero corso di sicurezza e autenticazione.
‫E solo per finire, qualcosa che implementeremo nel
‫resto della sezione
‫è prevenire l'inquinamento dei parametri.
‫Ad esempio, prova a inserire solo due parametri di campo nella
‫stringa di query che cerca tutti i tour.
‫E se lo fai, scoprirai che ci
‫sarà un errore perché
‫la nostra applicazione non è preparata per questo.
‫E così, gli aggressori cercano di usare questo tipo di punti deboli per
‫mandare in crash le applicazioni, il che, ovviamente, non va bene.
‫E quindi, dobbiamo risolverlo.
‫Ok, quindi questo si è rivelato molto più lungo di quanto mi aspettassi.
‫E ci sono interi corsi sulla sicurezza se
‫sei veramente interessato alla sicurezza.
‫Va bene, ma lascio le cose
‫a questo, quindi ora passiamo a quello successivo.