Mi chiedo quali sono i controlli di sicurezza prioritari che dovresti fare per lanciare una nuova webapp?
Immagino le vulnerabilità della forza bruta e lo scripting cross-site. Quali sono le altre cose che hai assolutamente da controllare anche se non hai tempo per farlo?
OWASP si è così chiamato Top Ten Project , che mostra quali sono le vulnerabilità più popolari. Ma non dovresti mai limitarti solo a quegli assegni che sono elencati qui. Non mi è mai piaciuto come suona - "mostrami le 10 principali vulnerabilità". Una risposta abbastanza simile è qui: link , nel mezzo della filosofia. Il primo paragrafo esprime pienamente la mia opinione. Lasciatemi citare:
If your intention is to write secure code, then I would recommend to avoid such questions like "top10 vulnerabilities". There is no point in focusing only on some desired sort of bugs, because there are quite similar chances to introduce bug of typecasting, integer overflow, off-by-one, stack overflow and others if your knowledge in C/C++ is weak and you have small experience in programming.
SQL Injection è grande se si dispone di qualsiasi tipo di interazione con il database ed è relativamente facile da testare. Tra le richieste di assistenza cross-site (CSRF) ce n'è un'altra di cui non posso fare a meno. È anche una buona idea controllare gli attacchi di canonicalizzazione dei file, specialmente se supporti il caricamento degli utenti o il download di qualsiasi tipo.
Il resto dipende molto dalla tua app, dal tipo di dati che contiene e da chi sono gli utenti.
Se fossi davvero critico in tempo, mi assicurerei che la mia applicazione fosse controllata per quanto segue:
Mi piacerebbe avere abilità "brute force". Naturalmente, gli utenti hanno bisogno di password sicure, e anche la struttura delle directory e i file possono sempre essere rinforzati. Ricorda che la sicurezza da oscurità non funziona da sola :)
Penso che Ams abbia ragione, tuttavia in termini di maggiore esposizione, vale la pena guardare le statistiche. Consulta il rapporto sulla violazione dei dati di Verizon , Krebs Rapporto sulla sicurezza Java e WHID Security Report per alcune grandi fonti di informazioni su quali attacchi stanno realmente accadendo su Internet.
Le minacce più importanti sono quelle che tentano di accedere al back-end, come il database. SQL injection è in cima alla lista; il controllo che devi fare è assicurarti che l'input dell'utente non sia direttamente inserito nella stringa per una query dinamica; l'input dell'utente è tutto ciò che viene dal client; anche se l'utente non è in grado di modificarlo nel modulo o sul browser, immagina di poter intercettare il traffico lasciando il browser e iniettare qualsiasi cosa in qualsiasi campo. Quindi tieni sempre presente: "non fidarti dell'input proveniente dal client".
Quindi non fidandosi dell'input dell'utente, ora devi convalidare ogni input; per l'iniezione SQL, è necessario eliminare qualsiasi carattere non accettato; ad esempio, se si suppone che l'utente cerchi un numero, non accettare nulla tranne una combinazione di 0-9 per una certa lunghezza; rimuovi il resto e inseriscilo nella query. È una buona idea evitare del tutto le query dinamiche e utilizzare query parametrizzate e stored procedure nel database.
Il prossimo attacco superiore è un'iniezione che può essere indirizzata ad altri utenti; come XSS. La storia con XSS è simile all'iniezione SQL, non dovresti fidarti dell'input dell'utente e fare una validazione nella whitelist dopo aver ricevuto qualsiasi input. In generale, i controlli lato client assicurano che il formato che l'utente ha digitato i dati non sia sufficiente e che tutto debba essere ricontrollato sul lato server.
Devi prestare particolare attenzione alla parte di autenticazione; il nome utente e la password sembrano una funzionalità semplice; non è. È necessario accertarsi che all'accesso eseguito correttamente venga generato un nuovo valore di sessione e impostato sul cookie del cliente. È inoltre necessario assicurarsi che per il resto del tempo l'utente abbia effettuato l'accesso, questa sessione non sia esposta tramite HTTP; cioè, devi andare su SSL. La sessione deve essere casuale, abbastanza lunga e non immaginabile. La maggior parte dei linguaggi di programmazione può prendersene cura; non reinventare la ruota. Assicurati che la sessione abbia i flag Secure e HTTPSolo impostati; e assicurarsi che sia scaduto dopo un periodo di inattività o una disconnessione manuale. La reimpostazione della password e il cambiamento sono anche funzionalità molto sensibili; che ha bisogno di un lungo post da discutere.
Una parte molto importante è l'autorizzazione. Una volta che un utente è autenticato, ciò non significa che tu abbia finito; ogni utente deve accedere solo a determinate pagine o dati; quindi ogni richiesta deve essere controllata sul lato server per prevenire l'escalation dei privilegi.
Leggi altre domande sui tag webserver web-application penetration-test