Ci sono le migliori pratiche per i test di sicurezza in un Agile di sviluppo del negozio?[chiuso]

Question

Per quanto riguarda lo sviluppo Agile, quali sono le migliori pratiche per i test di sicurezza per il rilascio?

Se si tratta di una pubblicazione mensile, ci sono negozi fare pen-test ogni mese?

Answer 1

Qual è la vostra applicazione di dominio?Dipende.

Dal momento che hai usato la parola "Agile", sto indovinando che è una web app.Ho una bella risposta facile per voi.

Andare a comprare una copia del Burp Suite (è il #1 Google risultato per "burp" --- un sicuro supporto!);ti costerà 99EU, o ~$180USD, o $98 Obama Dollari se si aspetta fino a novembre.

Burp funziona come un proxy web.Si naviga attraverso l'applicazione web con Firefox o IE o qualsiasi altra cosa, e raccoglie tutti i successi che si genera.Questi colpi di avere alimentato una funzione chiamata "Intruso", che è un web fuzzer.Intruso capire tutti i parametri di fornire a ciascuno di query gestori.Si cercherà quindi pazzo valori per ogni parametro, tra cui SQL, file system, e HTML metacaratteri.In un tipico complesso post di forma, andando a generare circa 1500 colpi, che potrai guardare attraverso per identificare spaventoso --- o, ancora più importante in un Agile contesto, nuovo --- risposte di errore.

Fuzzing ogni gestore di query in web app a ogni nuova release di iterazione è il #1 cosa si può fare per migliorare la sicurezza delle applicazioni, senza l'istituzione di un formale "SDLC" e l'aggiunta di organico.Al di là di esaminare il codice per maggiori web app di sicurezza hot spot:

• Utilizzare solo con parametri preparato le istruzioni SQL;non sempre basta concatenare le stringhe e dar loro da mangiare al vostro database di gestire.

• Filtro tutti gli ingressi ad una lista di noti personaggi buoni (alnum, punteggiatura di base), e, cosa più importante, filtro di uscita dati dai risultati delle query, per "neutralizzare" HTML metacaratteri in entità HTML (quot, lt, gt, ecc).

• Uso a lungo casuale difficile da indovinare identificatori ovunque si sta attualmente utilizzando semplici intero riga Id parametri di query, e assicurarsi che l'utente X può non vedere l'utente Y dati semplicemente indovinando chi gli identificatori.

• Il Test di ogni gestore di query nell'applicazione per assicurarsi che funzionino solo quando un valido, connesso cookie di sessione è presentato.

• Accendere il XSRF protezione web stack, che genererà un modulo nascosto token parametri su tutti i tuoi rendering di forme, per impedire agli aggressori di creazione di link malevoli che potranno inviare i moduli per gli utenti ignari.

• Utilizzare bcrypt --- e nient'altro --- per memorizzare le password con hash.

Answer 2

Io non sono un esperto di sviluppo Agile, ma immagino che l'integrazione di base automatizzato pen-test di software nel vostro ciclo di build sarebbe un buon inizio.Ho visto diversi pacchetti software là fuori che farà il test di base e sono adatti per l'automazione.

Answer 3

Io non sono un esperto di sicurezza, ma penso che il fatto più importante, che si dovrebbe essere a conoscenza di, prima dei test di sicurezza, è quello che si sta cercando di proteggere.Solo se si sa cosa si sta cercando di proteggere, si può fare una corretta analisi delle misure di sicurezza e solo allora si può iniziare la prova di tali misure attuate.

Molto astratto, lo so.Tuttavia, penso che dovrebbe essere il primo passo di ogni audit di sicurezza.

Answer 4

Unit test, La Difesa Di Programmazione e un sacco di tronchi

Unit test

Assicurarsi di unità di test il più presto possibile (ad es.la password deve essere crittografati prima dell'invio, il tunnel SSL è lavoro, etc).In questo modo si eviterà il tuo programmatori accidentalmente rendendo il programma insicuro.

La Difesa Di Programmazione

Io personalmente la chiamo Paranoico di Programmazione, ma Wikipedia non è mai sbagliato (sarcasmo).Fondamentalmente, si aggiungono test per le funzioni che la verifica di tutti gli ingressi:

• è il cookie dell'utente valido?
• è ancora connesso?
• sono la funzione di parametri protetti contro la SQL injection?(anche se si sa che l'input generati da le proprie funzioni, si metterà alla prova in ogni caso)

La registrazione

Registro tutto come un matto.La sua più facile per rimuovere i registri poi aggiungere loro.Un utente loggato?La sua registrazione.Un utente ha trovato un 404?La sua registrazione.Admin modificato/cancellato un post?La sua registrazione.Qualcuno è stato in grado di accedere a una pagina con accesso limitato?La sua registrazione.

Non stupitevi se il vostro file di registro raggiunge 15+ Mb durante la fase di sviluppo.Durante la beta, si può decidere che i registri per rimuovere.Se si desidera, è possibile aggiungere un flag per decidere quando un certo evento viene registrato.