La mia domanda è, per un sito "normale", cosa pensi sia sufficiente per proteggere dai metodi usati da "script kiddies"? Ad esempio, SQL injection, XSS e cose del genere.
Stessa domanda per gli hash delle password. Pensi che sia sufficiente hash con MD5 + salt random, o minimo SHA1 + random sale, o dovrebbe essere usato qualcosa di ancora più strong?
So che nessuna applicazione è completamente sicura, ma voglio ottenere una buona sicurezza senza essere eccessivamente complessa.
Questa sembra una domanda "quanto è lungo un pezzo di corda". Non c'è una risposta definitiva. Tutto dipende dal valore dei dati o da questo sito Web, dalla probabilità che venga attaccato, dall'abilità o dagli strumenti che l'utente malintenzionato potrebbe avere, dalle vulnerabilità che il sito potrebbe già avere, ecc. Dovresti anche valutare la complessità o costo di implementazione dei controlli di sicurezza rispetto a quanto guadagni o perdi. per esempio. quanto è facile o difficile cambiare l'hash da MD5 a SHA1 rispetto a cosa potresti perdere se qualcuno riceve quegli hash.
Direi che la probabilità che qualsiasi sito Web su Internet venga attaccato dai copioni-kiddie è ragionevolmente alta. Ci sono un sacco di strumenti e un sacco di persone annoiate che vogliono divertirsi, o imparare come essere un hacker. Quindi, come minimo, vorresti assicurarti di essere coperto da vulnerabilità note. Se vuoi fare un ulteriore passo avanti, prova a scansionarlo con alcuni strumenti che gli script kiddies potrebbero usare per scoprirlo. Ci sono anche un numero crescente di fornitori di servizi SaaS che offrono questo tipo di servizio, alcuni di loro potrebbero anche avere un'opzione gratuita di base. Puoi iniziare facilmente con quello e continuare a crescere / migliorare in base al tuo profilo di rischio. Quando lo consideri, non pensare solo agli script kiddies e agli hacker. E il tuo personale? sviluppatori, amministratori di sistema, il tuo provider di hosting? Persone con accesso legittimo, che potrebbero commettere un errore o deliberatamente fare qualcosa di male. Anche quelli sono un potenziale rischio. Inoltre, non si tratta solo di problemi tecnici. Pensa all'ingegneria sociale, agli attacchi di phishing, ecc.
Oltre a questo, se è per il tuo apprendimento e sviluppo. Prova ad elencare tutti quei miglioramenti / problemi di sicurezza e valutarli in qualche modo. Anche se non sei sicuro, è meglio avere alcune priorità in mente. Inizia con gli articoli che sono il più grande "bang for the buck", cioè facile da correggere, ad alto rischio. Quindi vai giù per la lista e migliora gradualmente la tua sicurezza.
Cerca di capirlo da un punto di vista leggermente più vicino alla realtà.
Ci sono persone là fuori con diversi livelli di abilità che attaccheranno il tuo sistema web per molte ragioni che vanno da motivi politici, commerciali, di carne personale o semplicemente per motivi di intrattenimento.
Le ragioni non hanno alcuna conseguenza alla fine della giornata. Il fatto che un sistema web sia vulnerabile e sia stato sfruttato è il problema principale.
È responsabilità dello sviluppatore assicurarsi che tutti gli input siano di tipo set e che le chiamate al database siano preparate correttamente.
La responsabilità dell'utente dell'applicazione web è di assicurarsi che sia aggiornato con la versione più recente del software applicativo e le versioni più recenti di eventuali plug-in e componenti aggiuntivi che possono anche utilizzare.
Se gli utenti dell'applicazione hanno aderito a questa regola, lo sfruttamento delle applicazioni si ridurrebbe a un'ombra del suo sé attuale.
Se si utilizza un'applicazione che presenta vulnerabilità di input che non sono state corrette con patch dagli sviluppatori, è possibile correggerle da sole o passare a un'applicazione che non sia vulnerabile in questo modo.
Se un utente trascura comunque di tenere aggiornate le proprie applicazioni quando sono disponibili correzioni, per essere sinceri, sono loro che lo script non è l'hacker.
Leggi altre domande sui tag sql-injection hash xss