Ora sappiamo come scoprire e sfruttare Sì le nostre vulnerabilità.
Parliamo di come proteggere i siti web da loro.
Quindi, se torniamo indietro a GVW 8 e abbiamo detto che la sicurezza è troppo alta, vedrete che hanno un modo molto semplice per
proteggervi, ma in questo modo funziona davvero.
E quello che fanno è che ti chiedono la password corrente.
Quindi, anche se otteniamo questo modulo e facciamo tutto il lavoro di forgiatura e tutte le cose che stavamo
facendo e poi lo abbiamo inviato alla persona di destinazione, non possiamo effettivamente nasconderlo e farlo inviare automaticamente perché
non conosciamo l'attuale parola d'ordine.
Quindi richiede la password corrente e quindi ti consente di aggiungere una nuova password.
Quindi questa è davvero una buona soluzione per questo caso.
Anche se perché cosa succede se il modulo in realtà non cambia la tua password.
E se mandassimo messaggi che fingono di essere quella persona.
Che cosa succede se pubblicheremo le cose sul muro di quella persona.
Che cosa succede se pubblicheremo le cose nel blog di quella persona.
Quindi, dal momento che Aref può essere sfruttato per fare molte cose.
Come ho detto nei video precedenti e questo metodo protegge solo contro la modifica della password.
Non si può davvero chiedere alla persona la propria password ogni volta che desidera pubblicare qualcosa o fare
qualcosa con il proprio profilo.
Ora le versioni più recenti dei DVD quando ne hai bisogno non sono dotate di protocollo di test per
avere un'opzione più sicura che implementerà il metodo di cui ti parlerò.
Ora in realtà è chiamato impossibile anziché alto, ma non importa non è comunque sfruttabile quindi
non abbiamo davvero bisogno di averlo installato.
Quindi parliamo di come potresti effettivamente impedire che queste vulnerabilità si verifichino senza
chiedere all'utente di reinserire le informazioni o di reinserire la password.
Se ci pensi come siamo riusciti a sfruttarlo, siamo stati in grado di copiare semplicemente il modulo che
il sito Web utilizza e inviarlo alla persona di destinazione e ottenere quella persona per eseguirlo o eseguire automaticamente sul computer
della persona di destinazione.
Quindi, una volta che la richiesta viene inviata al server o il server non sta facendo alcun tipo
di convalida per garantire che l'utente voglia effettivamente cambiare la sua password.
Quindi il modo migliore per prevenire s r f è assicurarsi che l'utente stia inviando i dati attraverso una
pagina che gli è stata fornita dall'applicazione web e non da nessun altro.
Un buon modo di implementare è usare i token di sincronizzazione.
Ora so che il nome sembra complicato ma l'idea è molto semplice.
Fondamentalmente vogliamo generare un token univoco e casuale sul lato server.
Quindi, quando la pagina viene caricata quando viene caricato il modulo, inseriremo questo token già
generato in quella pagina come forma nascosta.
Quindi, una volta inviato il modulo, ci assicureremo che il modulo sia stato inviato con quel
token che abbiamo inviato a quell'utente specifico.
Quindi in pratica diamo all'utente un token e quindi aspettiamo che invii il modulo con il token che gli
abbiamo dato.
In questo modo il token che l'hacker ottiene funzionerà solo per lui.
Quindi, anche se genera una pagina e la invia alla destinazione e il bersaglio getta
la pagina, il modulo verrà inviato ma verrà rifiutato dal server perché non ha dato quel
token a quell'utente che ha dato quel token all'hacker dicendo per esempio abbiamo questo utente qui e qui costa
Facebook dot com password BHB.
Va al server.
Il server genererà una risposta per quella richiesta.
Quindi restituirà la pagina di posta elettronica che rappresenta le password ph in quella pagina.
Includerà un token univoco.
Quindi, quando la pagina viene caricata sul lato client, avrà già il modulo che l'utente
sta cercando più un token univoco che è stato generato dal server.
Quindi, quando l'utente invia ciò che vuole inviare il server accetterà solo il modulo e lo farà o lo
farà sulla risposta a ciò che l'utente sta chiedendo.
Se l'utente restituisce lo stesso token.
Ora se questo non è implementato correttamente può ancora essere sfruttato.
Quindi se il token era prevedibile o se veniva utilizzato lo stesso token, l'hacker può scoprire che
cosa il token è incorporato nel codice HDMI e inviarlo all'utente.
Quindi il token deve avere determinate caratteristiche in modo che sia sicuro.
In pratica, la cosa principale è che vuoi tenere a mente che il token deve essere
imprevedibile e non può essere utilizzato a prescindere dal modo in cui lo implementerai.
Queste sono le due cose principali che vuoi tenere a mente perché se fosse prevedibile,
l'hacker sarà in grado di creare i propri token e quindi incorporarli nel codice ed eseguire l'attacco.
Lo stesso token può essere usato.
Quindi gli hacker possono semplicemente usare il loro token o il token di qualcun altro per bersagliare il loro bersaglio.
Quindi, per rendere il token imprevedibile e renderlo utilizzabile, il token deve avere un valore elevato in
modo che l'hacker non possa eseguire un attacco di forza bruta e scoprire quale sia il token che il token deve
essere casuale in modo che l'hacker non sia in grado di creare i propri token e deve essere univoco
per ogni utente, perché se gli utenti ricevono lo stesso token o token simili possono passarli e
quindi il token che funziona per l'hacker funzionerà per altre persone.
Quindi questo definirà l'intero punto.
È inoltre possibile aumentare la sicurezza del token includendolo in altri fattori e nell'algoritmo di generazione
di token.
Quindi puoi includere ad esempio la data e l'ora.
Quindi combinalo con un generatore casuale sicuro e quindi crittografalo.
Tutto ciò ovviamente sta accadendo sul lato server.
Quindi l'hacker non sarà in grado di sapere quale algoritmo stai usando perché il codice verrà eseguito
sul lato server.
Non devi necessariamente farlo usando un numero casuale numeroso sicuro e unico.
Ma se si desidera aumentare la sicurezza, è sufficiente aggiungere altri fattori e crittografare il token
prima di inviarlo all'utente.
Questo è effettivamente implementato in Matile day.
Quindi lascia che te lo mostri solo in azione.
Quindi andrò al giorno Matile qui.
Vado su una vespa allora sì o come aggiunta al blog.
Quindi questo ti consente di aggiungere un post sul blog in modo che non ti permetta di cambiare la tua password
o qualsiasi cosa consenta effettivamente agli anonimi di accedere ai post del nostro blog.
Quindi non puoi davvero chiedere alle persone una password.
In effetti andrò e cambierò la sicurezza in modo che sia la più alta perché ora è a zero.
Quindi ora è il più sicuro.
E se fai clic destro su questo e vai avanti, controlla l'elemento.
Ora ho intenzione di scorrere verso l'alto e come puoi vedere abbiamo il forum qui e abbiamo un input nascosto con un
valore molto lungo.
E questo è il token.
Quindi questo è già stato generato dal server e il server rifiuterà qualsiasi richiesta che inviamo
ad esso a meno che non abbia questo specifico token.
E se io uso questo modulo e lo mando a qualcun altro.
Quindi di nuovo le richieste che invieranno saranno rifiutate perché riceveranno un token diverso che questo token
è stato generato per me e solo per me.
Quindi lascia che ti mostri se in realtà sto aggiornando ora sto per ottenere un altro token.
E di nuovo, se lo aggiorno di nuovo, otterrò un altro token se lo modifico.
Quindi diciamo invece della capitale I alla fine inserirò un piccolo I se invio questo ora mi
sta dando un errore.
Ma lascia che non cambi questo, così di nuovo ho un altro token ora e se ho appena presentato
il modo in cui funziona funzionerà e ora abbiamo un blog chiamato test.
Quindi è così.
In realtà è molto semplice.
Non volevo dare troppi dettagli su come creare un token casuale e tutto il resto perché questo
dipende in modo specifico dal linguaggio di programmazione.
Questa è l'applicazione web è programmata in.
Ma volevo solo mostrarti il concetto o l'idea di come proteggere le applicazioni web da questo
tipo di vulnerabilità.
L'idea è che tu voglia assicurarti che l'utente invii i loro dati attraverso una pagina che tu li serva e
non da una pagina che è stata data loro da qualsiasi altra persona.
Quindi per fare ciò generiamo un token sul lato server questo token deve essere casuale a lungo e
univoco inviare quel token con la pagina con il modulo e incorporato come un modulo nascosto.
E poi ogni volta che un utente invia la risposta assicurati che invii lo stesso token che è stato
loro assegnato.