Det er veldig lett å tenke på funksjonalitet og kvalitet når man ser på andre sin kode, men hvordan er forholdet ditt til sikkerhet når du gjør "code review"? Hva er det egentlig man skal se etter, og hva bør man tenke ekstra på når du skal gå gjennom andre sin kode?
Det finnes mange gode rammeverk og verktøy som du kan bruke i dine utviklingsprosjekter for å styrke sikkerheten.
La oss derfor starte med å se på enkle sikkerhetsprinsipper både i koding og kodegjennomgang, som alle kan ta med seg i sine kodeprosjekter.
«De fleste har et forhold til feilhåndtering når de utvikler kode. Men ofte kan det være mer komplisert å håndtere feil som kommer fra andre datakilder,»
#1: Datavalidering
Det første man bør tenke på er hvordan man håndterer data inn i løsningen. Alt må valideres, og helst så tidlig som mulig. I tillegg bør man jo selvfølgelig validere hvem som får sende inn og hvem som får hente ut data.
Et spørsmål som jeg derfor ofte spør meg selv er - hva er det jeg som utvikler tillater av data i koden min? Mer restriktiv data gjør at man får mer kontroll på det som skjer inni applikasjonen, men også de interaksjonene man eksponerer seg mot. På den måten får du som utvikler lagt til grunn hvilke typer flyter du tillater i løsningen, men også hindre at du tar inn noe ondsinnet data.
Dette kan for eksempel gjøres ved å legge til dataannoteringsattributter på input-klassene dine.
#2: Feilhåndtering
De fleste har et forhold til feilhåndtering når de utvikler kode. Men ofte kan det være mer komplisert å håndtere feil som kommer fra andre datakilder, enten det er interne eller eksterne løsninger.
Henter man data fra X forskjellige løsninger så ender man fort opp med X unike måter å håndtere feil på. Kanskje har ikke en integrasjon så god dokumentasjon, så man har bare gått for en tilfeldig, standard feilhåndtering? Selv internt i en organisasjon vil mange team ha sin egen tilnærming til håndtering og kasting av feil.
Nøkkelordet her er standardisering! Man må være mer bevisst som utvikler på hva som returneres, hvor og når flyter skal avbrytes og eventuelle feil skal bli kastet. Start enkelt! Bli for eksempel enige om sentrale feilkoder som er viktige i ditt team og del dette med andre team. Dette vil også føre til store tidsbesparelser videre i utviklingsfasen for alle.
#3: Negative tester
Du er nettopp ferdig med å legge til en feature som brukerne har forespurt i lang tid. Ting ser fint ut, og du har til og med tatt deg tid til å lage tester! Men hva med de negative testene?
Å teste sikkerheten i en applikasjon kan gjerne bli sett på som en type negativ test. Disse testene fokuserer spesifikt på å utforske systemets grenser og svakheter ved å simulere uønskede situasjoner og mulige trusler. Start tidlig og bruk tiden gjennom hele utviklingsløpet på å lage gode negative tester. Er du egentlig logget av når du logger ut av løsningen?
Lag en test på det! Skal man ikke bruke denne rollen når man kaller dette APIet? Lag en test på det! I tillegg skaper dette også en bevissthet rundt potensielle angrepsflater og hvordan de kan beskyttes. Negative tester blir dermed et uvurderlig verktøy for å styrke den generelle sikkerhetskulturen innen utviklingsteamet.
«Bruk litt ekstra tid nå i sikkerhetsmåneden på hvordan du kan tenke sikker kode når du går igjennom codereviews!»
#4: Skjult logikk
Skjult logikk, eller ofte referert til som «obfuscation», kan representere en sårbarhet i et system ved å gjøre kode uklar eller vanskelig å forstå for mennesker.
Dette kan være enkle ting som å ha generiske eller upresise variabelnavn, omorganisere kodeblokker, legge til unødvendig logikk eller bruke unødvendige avanserte algoritmer. Å forholde seg til avanserte sikkerhetskonfigurasjoner hvor det skjer mye på en gang kan være vanskelig å vedlikeholde, og fører som oftest bare til mulige sikkerhetshull.
Bruk rammeverk til det fulle, som gjerne kommer med ferdigløsninger for for ekempel kryptering, autentisering og autorisasjon.
#5: Avhengigheter
Når man skriver ny kode så vil man som regel bygge på eksisterende kode, enten det er interne klasser og metoder, eller eksterne pakker og avhengigheter.
Man må være bevisst på all kode man bruker. Og ved arbeid med eldre kode eller legacy-systemer, er grundige kodegjennomganger nødvendig for å identifisere og rette opp potensielle sårbarheter. Når man bruker tredjepartsverktøy, bør man velge pålitelige og godt vedlikeholdte ressurser, gjerne det organisasjonen din bruker fra før av. Oppretthold regelmessige oppdateringer, og dette inkluderer også å informere resten av organisasjonen hvis ditt team fant noe som bør patches.
Velfungerende kode er konge, men velfungerende, sikker kode er det beste 😊 Bruk litt ekstra tid nå i sikkerhetsmåneden på hvordan du kan tenke sikker kode når du går igjennom codereviews! Så får du forhåpentligvis også gradvis økt bevisstheten rundt sikkerhetsaspekter i utviklingsteamet.
