Er det beste praksis for å teste sikkerheten i en Agile utvikling butikk?

stemmer
10

Angå Agile utvikling, hva er beste praksis for å teste sikkerheten per utgivelse?

Hvis det er en månedlig utgivelse, er det butikker gjør penn-tester hver måned?

Publisert på 05/08/2008 klokken 15:05
kilden bruker
På andre språk...                            


4 svar

stemmer
2

Hva er din søknad domene? Det kommer an på.

Siden du brukte ordet "Agile", jeg gjetter det er en web-app. Jeg har en fin enkel svaret for deg.

Gå kjøpe en kopi av Burp Suite (det er # 1 Google resultat for "rap" --- en sikker anbefaling!); det vil koste deg 99EU, eller ~ $ 180USD, eller $ 98 Obama dollar hvis du venter til november.

Burp fungerer som en web proxy. Du blar gjennom web app bruker Firefox eller IE eller hva, og det samler alle treff du genererer. Disse treff blir matet til en funksjon kalt "Intruder", som er et web fuzzer. Intruder vil finne ut alle parametre du gir til hver og en av dine spørre handlers. Det vil da prøve gale verdier for hver parameter, inkludert SQL, filsystem, og HTML-metategn. På en typisk kompleks form innlegg, dette kommer til å generere ca 1500 treff, som du vil se gjennom å identifisere skremmende --- eller, enda viktigere i en Agile sammenheng, nye --- feilreaksjoner.

Fuzzing hver spørring handler i nett app ved hver utgivelse iterasjon er # 1 ting du kan gjøre for å forbedre applikasjonssikkerhet uten å iverksette en formell "SDLC" og legge bemanning. Utover det, gjennomgå kode for de store web app sikkerhets hot spots:

  • Bruk kun parametriseres forberedt SQL-setninger; ikke alltid bare sette sammen strenger og mate dem til databasen håndtaket.

  • Filtrere alle innganger til en hvit liste over kjente gode tegn (alnum, grunnleggende tegnsetting), og, enda viktigere, utgang filtrere data fra resultatene spørre å "nøytralisere" HTML-metategn til HTML enheter (quot, lt, gt, etc).

  • Bruk lange tilfeldige vanskelig å gjette identifikatorer hvor som helst du bruker, enkle heltall rad IDer i søkeparametere, og sørge for at brukeren X kan ikke se brukerens Y data bare ved å gjette disse identifikatorer.

  • Test hver spørring handler i programmet for å sikre at de fungerer bare når en gyldig, logget på session cookie er presentert.

  • Slå på XSRF beskyttelse i nett stabelen, som vil generere skjult skjema token parametre på alle dine utførte former, for å hindre angripere fra å lage ondsinnede lenker som vil sende inn skjemaer for intetanende brukere.

  • Bruk bcrypt --- og ingenting annet --- å lagre hashet passord.

Svarte 10/09/2008 kl. 21:19
kilden bruker

stemmer
1

Enhetstesting , Forsvars Programmering og massevis av loggene

enhetstesting

Sørg for at du enheten test så tidlig som mulig (for eksempel passordet skal krypteres før sending, SSL tunnel fungerer, etc). Dette vil hindre at programmerere fra utilsiktede programmet usikker.

Forsvars Programming

Jeg personlig kaller dette Paranoid Programmering men Wikipedia er aldri feil ( sarkasme ). I utgangspunktet, legger du tester til funksjoner som kontrollerer alle innganger:

  • er brukerens cookies gyldig?
  • er han fortsatt logget inn?
  • er funksjonsparametrene beskyttet mot SQL-injeksjon? (Selv om du vet at inngangen er generert av dine egne funksjoner, vil du teste likevel)

logging

Logge alt som gale. Det er lettere å fjerne logger deretter å legge dem. En bruker har logget inn? Logg det. En bruker har funnet en 404? Logg det. Admin redigeres / slettes et innlegg? Logg det. Noen var i stand til å få tilgang til en begrenset side? Logg det.

Ikke bli overrasket om loggfilen når 15+ Mb under utviklingsfasen. Under beta, kan du bestemme hvilke logger for å fjerne. Hvis du vil, kan du legge til et flagg til å bestemme når en bestemt hendelse logges.

Svarte 18/08/2008 kl. 02:40
kilden bruker

stemmer
1

Jeg er ikke en sikkerhetsekspert, men jeg tror det viktigste faktum du bør være klar over, før testing sikkerhet, er det du prøver å beskytte. Bare hvis du vet hva du prøver å beskytte, kan du gjøre en skikkelig analyse av sikkerhetstiltak og bare da kan du begynne å teste de iverksatte tiltak.

Veldig abstrakt, jeg vet. Imidlertid tror jeg det bør være det første trinnet i enhver sikkerhetsrevisjon.

Svarte 05/08/2008 kl. 17:50
kilden bruker

stemmer
1

Jeg er ingen ekspert på Agile utvikling, men jeg vil tro at å integrere noen grunnleggende automatisert penn-test programvare til din bygge syklus ville være en god start. Jeg har sett flere programvarepakker der ute som vil gjøre grunnleggende testing og er godt egnet for automatisering.

Svarte 05/08/2008 kl. 17:19
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more