Sikkerhetstesting må ikke utføres av oss med sikkerhet i tittelen. Så hvordan kan du som utvikler komme i gang med enkel sikkerhetstesting og gjøre litt selv?
Min kollega fortalte hvordan utviklere kan begynne å tenke sikkerhet. Jeg plukker opp tråden og deler litt om verktøy, samt hvilke ressurser som er kjekke å ha med deg når du tester.
Du kommer langt med å spørre spørsmål «Hva skjer hvis jeg sender inn ugyldige verdier?» eller «Hva skjer hvis jeg besøker siden direkte uten å logge inn?».
Målet er å flytte fokuset vekk fra hvordan en normal person bruker applikasjonen, til hvordan kan applikasjonen gjøre ting den ikke skal gjøre.
- Den viktigste sikkerhetsjobben er det utviklerne som gjør!
Et kart over sikkerhet 🗺️
Mange utviklere har blitt kjent med OWASP og deres mest kjente verk, Top Ten. Det forteller om de ti mest utbredte sårbarhetene i webapplikasjoner, en god start når du ønsker å lære mer om sikkerhet.
OWASP har en rekke prosjekter som går dypere enn Top Ten, deriblant Web Security Testing Guide. Dette er et godt oppslagsverk som beskriver sårbarheter og hvordan du skal teste for dem.
Bare ikke bruk den som enda en evinnelig og forbanna sjekkliste, da går den fort i skuffen.
Nettbutikken du kan plage 🧨
Før du setter i gang med sikkerhetstesting, trenger du en webapplikasjon å jobbe med. Et av hobbyprosjektene dine kan være en god start, men det byr kanskje ikke på bredt nok spekter av sårbarheter.
Så hvor finner du en veldig usikker webapplikasjon?
Juice Shop er et OWASP-prosjekt som løser dette problemet. Dette er en nettbutikk med alle tenkelige sårbarheter, en perfekt skyteskive. Løsningen består av et API med en JavaScript-klient, så den minner om en moderne webapplikasjon.
Last ned Juice Shop og sett den opp på en server. Legg den bak en brannmur som kun godtar trafikk fra ditt nettverk, det er kjipt hvis andre begynner å plage din usikre webapplikasjon.
«Kanskje finner du sensitiv informasjon gjemt i disse kallene? Da sitter du kanskje med et viktig funn!»
Undersøk med DevTools 🔍
Mest sannsynlig har du allerede et verktøy for enkel sikkerhetstesting. Moderne webapplikasjoner er ofte skrevet i JavaScript og og Chrome DevTools lar seg studere klientapplikasjonene nøye.
Verktøyet kombinert med et kritisk blikk kan fort by på interessante funn. Det var her jeg startet sikkerhetsreisen min.
Network-fanen byr på en oversikt over trafikken som går mellom nettleseren og nettsiden. Alt fra lastingen av nettsiden til ressurser som stilsett og bilder fanges opp her. Dette kan fort bli en gullgruve fylt med informasjon.
Klientapplikasjoner genererer trafikk kjent som XHR, et eksempel er en JavaScript-klient som kommuniserer med et API. Kanskje finner du sensitiv informasjon gjemt i disse kallene?
Da sitter du kanskje med et viktig funn!
Webapplikasjoner lagrer ofte data på klienten. Cookies er det mest brukte, men local og session storage kan også holde på interessant informasjon. Application-fanen byr på funksjonalitet for å se hva ligger lagret.
Noen ganger finner du sensitiv informasjon, andre ganger finner du interessante verdier som kan endres. Kanskje lagres informasjon om nåværende bruker lokalt, er det mulig å få nye privilegier eller kanskje bli en annen bruker?
10 viktige prinsipper for sikkerhetsdesign
Bygg en effektiv verktøykasse 🛠️
Da jeg fortsatte sikkerhetsreisen, kom behovet for en større og kraftigere verktøykasse.
Burp Suite fra PortSwigger er en proxy som legger seg mellom nettleseren og Internett, som lar den logge trafikken du sender og mottar. Den kommer med en samling av verktøy som lar deg manipulere den samme trafikken. Burp Suite har blitt mitt viktigste verktøy i hverdagen som sikkerhetstester.
Det følger en innebygd utgave av Chromium som lar deg enkelt komme i gang. Naviger rundt med den innebygde nettleseren, den loggede trafikken kan vi i ettertid inspisere og arbeide med. Denne funksjonaliteten er mye av kraften til i Burp Suite.
Ofte ønsker vi ikke at absolutt all trafikk logges i Burp, heldigvis kan vi sette et scope slik at kun sidene vi er interessert i logges.
Som sikkerhetstester ønsker jeg ofte å endre på headere og annen last for å se hvordan en webapplikasjon reagerer, dette kan gjøres enkelt ved hjelp av Repeater.
Jeg starter ofte med å finne en forespørsel i loggen, denne sender jeg til Repeater som lar meg gjøre endringer på forespørselen før jeg sender den på nytt. Det er en veldig enkel handling, men Burp lar meg gjøre dette veldig effektivt.
Om man vil teste flere forskjellige verdier vil det være tungvint å legge de inn manuelt en etter en i Repeater. Heldigvis kan verktøyet Intruder hjelpe med å sende hundrevis av forespørsler på kort tid. Alt man trenger er en ordbok med alle variasjonene man vil teste, Intruder ordner resten og sender hundrevis av ulike forespørsler på veldig kort tid.
Gjennom konfigurasjon velger jeg hvor jeg ønsker å legge inn de ulike lastene eller om det er noen mønstre som det skal søkes etter.
Burp Suite byr på veldig mye mer funksjonalitet, men verktøyene jeg har snakket om er de viktigste. Verktøyene er tilgjengelige Burp Suite Community Edition som er tilgjengelig gratis fra PortSwigger.
Den betalte utgaven inneholder en skanner, men ikke fyr av automatiske verktøy før du forstår hvordan testing gjøres manuelt. Samtidig risikerer du å teste ting du ikke har lov til å teste.
Oppsummering
Det skal ikke mye til for å gjøre enkel sikkerhetstesting selv.
- Vær ondsinnet og tenk over hvordan applikasjonen ikke skal brukes.
- Ta med kart og kompass levert av OWASP.
- Hent frem en proxy og gi applikasjonen en veldig kjip dag.
Happy hackin’!
- 6 serverløse sikkerhetsfeil du aldri må gjøre!
Teknologisjefen advarer mot lange timeouts, tillatelser på avveie og mange avhengigheter.