Există cele mai bune practici pentru testarea securității într-un magazin de dezvoltare Agile?

Nu sunt expert în dezvoltarea Agile, dar mi-aș imagina că integrarea unor software-uri automate de testare automată în ciclul de construcție ar fi un început bun. Am văzut câteva pachete software care vor face teste de bază și sunt foarte potrivite pentru automatizare.

Nu sunt un expert în securitate, dar cred că cel mai important lucru pe care ar trebui să îl cunoașteți înainte de a testa securitatea este ceea ce încercați să protejeze. Numai dacă știți ce încercați să protejați, puteți face o analiză adecvată a măsurilor de securitate și numai atunci puteți începe testarea măsurilor implementate.

Foarte abstract, știu. Totuși, cred că ar trebui să fie primul pas al fiecărui audit de securitate.

Unit testing, Defense Programming and lots of logs

Testarea unității

Asigurați-vă că încercați unitatea cât mai curând posibil (de exemplu, parola trebuie criptată înainte de trimitere, tunelul SSL funcționează etc.). Acest lucru ar împiedica programatorii să facă accidental programul nesigur.

Programarea apărării

Eu personal numesc aceasta Programare Paranoid, dar Wikipedia nu este niciodată greșită ( sarcasm ). Practic, adăugați teste la funcțiile care verifică toate intrările:

• sunt cookie-urile utilizatorului valide?
• încă este conectat în prezent?
• sunt parametrii funcției protejați împotriva injectării SQL? (chiar dacă știți că intrările sunt generate de propriile dvs. funcții, veți testa oricum)

Conectarea

Înregistrează-te ca nebun. Este mai ușor să eliminați jurnalele apoi să le adăugați. Un utilizator sa logat? Înregistrați-o. Un utilizator a găsit 404? Înregistrați-o. Administratorul a editat / șters o postare? Înregistrați-o. Cineva a putut accesa o pagină restricționată? Înregistrați-o.

Nu fi surprins dacă fișierul dvs. de jurnal ajunge la 15+ Mb în timpul fazei de dezvoltare. În timpul versiunii beta, puteți decide care jurnale să fie eliminate. Dacă doriți, puteți adăuga un steag pentru a decide când un anumit eveniment este înregistrat.

Care este domeniul dvs. de aplicare? Depinde.

Deoarece ați folosit cuvântul "Agil", cred că este o aplicație web. Am un răspuns ușor de ușor pentru tine.

Mergeți să cumpărați o copie a Burp Suite (este rezultatul # 1 Google pentru "burp" --- o aprobare sigură!); va costa 99EU, sau ~ $ 180USD, sau $ 98 de dolari Obama dacă așteptați până în noiembrie.

Burp funcționează ca un proxy web. Navigați prin intermediul aplicației web folosind Firefox sau IE sau orice altceva și colectează toate înregistrările pe care le generați. Aceste rezultate sunt alimentate într-o funcție denumită "Intruder", care este un fuzzer web. Intrusul va descoperi toți parametrii pe care îi oferiți fiecăruia dintre agenții dvs. de interogare. Acesta va încerca apoi valori nebune pentru fiecare parametru, inclusiv SQL, sistem de fișiere și metacaractere HTML. Pe un post de tip complex, tipic, aceasta va genera aproximativ 1500 de hit-uri, pe care le veți căuta pentru a identifica înfricoșător - sau, mai important, într-un context Agil, noi răspunsuri de eroare.

Fuzzind fiecare manipulator de interogări în aplicația web la fiecare versiune de lansare este cel mai bun lucru pe care îl puteți face pentru a îmbunătăți securitatea aplicației fără a institui un SDLC formal și pentru a adăuga un număr de angajați. Dincolo de asta, examinați codul pentru punctele fierbinți de securitate importante pentru aplicațiile web:

• Utilizați numai instrucțiuni SQL pregătite parametrizate; nu trebuie doar să concatenați șirurile și să le alimentați cu mânerul bazei de date.

• Filtrați toate intrările într-o listă albă de caractere cunoscute (alnum, punctuație de bază) și, mai important, extrageți datele de filtrare din rezultatele interogării pentru a "neutraliza" metacaractele HTML în entitățile HTML gt, etc.).

• Utilizați identificatori lungi aleatorii greu de ghicit oriunde utilizați în prezent ID-uri de rând simple întregi în parametrii de interogare și asigurați-vă că utilizatorul X nu poate vedea datele utilizatorului Y doar prin ghicirea acelor identificatori. >

• Testați fiecare manipulator de interogări din aplicația dvs. pentru a vă asigura că funcționează numai atunci când este prezentată o cookie de sesiune validă, logată.

• Activați protecția XSRF în stivă web, care va genera parametrii de tip token ascunse pe toate formularele redate, pentru a împiedica atacatorii să creeze link-uri rău intenționate care să trimită formulare pentru utilizatorii care nu se întreabă.

  li>

• Utilizați bcrypt --- și nimic altceva --- pentru a stoca parolele hashed.