Sikkerhetstest på 1, 2 og 3

Jeg har sittet i mange prosjekter hvor vi utvikler web-applikasjoner som skal lanseres på en gitt dato. Ofte har vi god kontroll på både test og verifisering av funksjonelle krav, mens de ikke-funksjonelle kravene ofte faller mellom to stoler. Sikkerhet er et slikt krav. Det beste er å ha en utvikler som tar på seg rollen som sikkerhetsansvarlig slik at teamet får eierskap til sikkerhetsaspektet helt fra starten. Men det er sjeldent jeg opplever at det er slik.

Det jeg opplever er at det hyres inn et sikkerhetsfirma som sjekker applikasjonen og infrastrukturen - men dette kommer ofte på plass i seneste laget. Da risikerer vi å finne feil og mangler som er tidskrevende å rette. Noen ganger kan vi midlertidig se bort fra slike feil og mangler, og heller planlegge å levere feilrettelsen i en fremtidig leveranse. Andre ganger stopper vi opp for å korrigere, for så å kjøre en ny avsjekk. Det siste fører jo selvfølgelig til at leveransedatoer ofte skyves på (noe som sjeldent er populært).

Så, hva kan vi gjøre for å unngå en slik situasjon?

Først: ønsker du å lære mer om temaet så meld deg gjerne på Meetup i regi av Norsk Testforum som skal være 25.august kl.17–19. Det er både digitalt og fysisk. Klikk her for mer informasjon.

Nå vil jeg ikke si at dette er en jobb som kun testressurser skal utføre, eller at det er en jobb som en testleder ikke kan gjøre. Dette er en vanvittig enkel oppgave som hvem som helst i teamet kan utføre. Det eneste som kreves er at du tar tak i resultatet som kommer ut og gjør noe med utfallet underveis i utviklingsprosessen. Jeg har opplevd å kjøre en mini-sikkerhetstest der jeg legger inn feilene som har blitt funnet i feilrapporteringssystemet uten at noen har tatt tak i disse — for så å få samme kommentarer etter at det er utført en penetrasjonstest. Dette har igjen ført til unødvendige armer og ben helt på tampen, og resultert i forsinkelser.

Det er veldig viktig å merke seg at testen som jeg skal vise til videre i innlegget, ikke tar bort behovet for å utføre en penetrasjonstest.

Først: installasjon av verktøy

Verktøyet jeg bruker heter OWASP Zed Attack Proxy (ZAP) og er laget av OWASP, en organisasjon som jobber for forbedret sikkerhet knyttet til web-applikasjoner.

1. Start med å laste ned ZAP fra https://owasp.org/www-project-zap/
2. Velg installasjon i henhold til operativsystem / systemtype. Når installasjonsfilen er lastet ned klikker du to ganger på denne for å starte installasjonen. Du blir spurt om du vil la programmet gjøre endringer på datamaskinen, velg “Ja”.
3. Klikk deg gjennom installasjonsveiviseren og kjør standard installasjon.

Oppstart av ZAP

Etter installasjonen er fullført starter du ZAP. Du møtes av et vindu som spør hvordan du vil lagre sesjonen din. Velg det som passer deg, og klikk “Start”.

Da får du opp et vindu med tre deler. I starten kan du se på den øverste delen med tre knapper; her kan du enten kjøre en automatisk skann, en manuell skann, eller å lære mer ved å klikke på den tredje knappen.

Utførelse av en manuell test

Jeg pleier å bruke manuell skann, da undersøkes applikasjonen samtidig som jeg klikker meg rundt i den. Klikk først på “Manual Explore”- knappen, deretter legger du inne URL’en til applikasjonen som skal testes ut. Velg så hvilken browser du ønsker å benytte i testen.

Klikk så på “Launch Browser”- knappen. I mitt eksempel åpnes en Chrome browser med et Heads up display. Her kan du velge å ta en gjennomgang av de ulike mulighetene. Jeg hopper over denne (burde huket bort “Enable HUD”).

Fordi jeg tester ut Systek sin hjemmeside er det denne som åpner seg opp i browseren via ZAP. På venstre side vil vi se resultatene fortløpende, og på høyre side kan vi skru av og på forskjellige “angrepsmåter”, samt får en oversikt over feil på hele “siten”. Klikk på Start-knappene for å starte de ulike angrepene.

Vi kan følge med på resultatet samtidig som vi navigerer rundt på sidene. Som vi ser på figuren under, etter 21% skann av siden “Våre tjenester” har vi funnet to medium kategori varsler på akkurat denne siden, mens høyre meny viser totalt tre varsler.

Mens et aktivt skann pågår kan vi også se fremgangen i ZAP under “Active scan”. Men personlig liker jeg å holde meg i browseren til jeg er helt ferdig.

Når vi er ferdig, kan vi ta ut en rapport i ZAP. Da klikker vi på “Alerts”-fanen nederst i applikasjonen, se figur under.

Her får du en forklaring på feilen samt hvor varslet kommer fra. Jeg pleier å bruke “Generate Report” i ZAP for å lage en rapport jeg kan dele med utviklerne. Her velger jeg også bort andre sites enn våre egne — så slipper vi å ta hensyn til varsler som er avdekket hos tredjeparter.

Avsnittet “Alert count by alert type” er den første jeg pleier å se på. Den gir en fin oversikt over status.

Ved å klikke på de forskjellige varslene under kolonnen “Alert type” kan vi få både informasjon om varselet og hvordan problemet kan løses. Etter en gjennomgang med utviklingsleder kan informasjonen fra denne rapporten bli med videre inn til feilrapporteringsverktøyet slik at manglene kan utbedres. Når en sikkerhetstest så utføres på et senere tidspunkt vil vi slippe å få disse i fanget også :)

Håper denne lille gjennomgangen kan bidra til at du får utført sikkerhetstestene på en enklere måte.

Jeg vil til slutt anbefale deg å følge med på https://owasp.org/www-project-top-ten/ for til enhver tid holde deg oppdatert på hva som er top 10 sikkerhetsrisiko for web-applikasjoner.

Ønsker du å vite mer, eller er nysgjerrig på en karriere i Systek? Ta gjerne kontakt med oss på systek@systek.no eller se dine muligheter på våre hjemmesider.