I SpareBank 1 Utvikling legger vi mye innsats i å lage løsninger med riktig sikkerhet innebygd. Noe av det gjøres av oss med “sikkerhet” i stillingstittelen, men den viktige sikkerhetsjobben er det utviklerne som gjør.
Av og til er sikkerhet enkelt å se. Det kan være autentisering, kryptering eller validering, eller annen sikkerhetsfunksjonalitet. Det er åpenbart viktig at det virker, men applikasjonssikkerhet er mye mer enn som så.
Sikkerhet er summen av hvordan applikasjonen din reagerer når noen med uærlige hensikter pirker borti applikasjonslogikken eller den tekniske stacken. Sikkerhet er en egenskap i applikasjonen, og oppstår eller forsvinner i den daglige utviklingen av helt vanlig kode.
Heldigvis jobber de fleste av oss også mer eller mindre smidig. Et nøkkelkonsept her er at utviklingsteamene har selvstendig ansvar for applikasjonene sine. Det inkluderer sikkerhetsegenskapene, like mye som ytelsen og brukeropplevelsen.
Sikkerhetsarbeidet i en utviklingsorganisasjon er selvsagt mer enn å peke på at utviklerne har ansvaret, men man vil aldri lykkes om utviklerne ikke har forutsetningene for selv å oppdage at det kan være fare på ferde i dagens fjerde pull request.
Hvordan sørger man for at utviklerne lukter sikkerhetsuglene i kodemosen? At SQL må være parameterisert, eller at serialisering har sine fallgruver?
Som mye annet er det øvelse som gjelder, og vi har den tvilsomme fordelen av at vi som bransje gjentar de samme sikkerhetsfeilene om og om igjen. Dermed kan man øve seg på alt som har gått feil før.
Her følger noen varianter vi i SpareBank 1 Utvikling har prøvd med stort hell! Først en kort oversikt, så detaljer om hver enkelt, med fordeler og ulemper:
- Natas: Enkel testing av sårbar app
- KWASHC: Fiks en rekke sårbarheter i en webapp
- Hack yourself first: Strukturert workshop
- Bugbounties: Test andres løsninger på lovlig vis
- Online training
Til slutt er det også et avsnitt om nyttige verktøy for sikkerhetstesting.
Ingrid-Alice (25) frykter hun ikke lærer nok om sikkerhet
#1: Natas
Natas fra Over the wire består av et tredvetalls “capture the flag”-oppgaver (CTF), der man skal utnytte en sårbarhet i oppgaveapplikasjonen for å skaffe seg en nøkkel som man bruker for å få tilgang til neste oppgave.
Fordeler:
- Krever ikke noe oppsett. Det er bare å starte på oppgave 0 og fortsette derfra.
- Fungerer godt som gruppearbeid.
- Dekker svært mange vanlige sårbarhetsklasser, gjerne i flere varianter eller med utilstrekkelige fikser.
- Går over http og ikke https, så forutsetter ikke at man må sette opp sertifikathåndtering i webproxy (se avsnitt om verktøy).
Ulemper:
- Kommer ikke med noen form for forklaring eller introduksjon til sårbarhetene, så det er nok en del av oppgavene som kan være vanskelige å starte på om man står på bar bakke. Man finner fasit for oppgavene om man søker, men da må man ha litt disiplin for ikke å bare lese hele løsningen.
- Ikke fokus på hvordan man bør fikse sårbarhetene.
#2: Kantega Web Application Security Hero Challenge (KWASHC)
KWASHC er i stor grad utviklet av Kantega i Trondheim (si navnet litt fort!). Hovedfokuset er ikke på å finne sårbarhetene, men å fikse dem i koden.
Består av en serverkomponent med oppgaver og scoreboard, og en sårbar bloggtjeneste skrevet i Java.
Fordeler:
- Fokus på sikker koding, og ikke testing.
- Forklarer sårbarhetene, så man har et greit grunnlag for å finne løsninger selv om det er nytt stoff.
- Open source, så du kan tilpasse eller utvide som du vil.
- Scoreboard gjør det underholdende å kjøre i mild konkurranseform, gjerne mellom grupper.
Ulemper:
- Krever litt lokalt oppsett.
- Ikke den aller mest moderne tekniske frontendstacken, med Spring MVC og serverside-rendret jsp. Kanskje du vil modernisere den?
#3: Hack yourself first
Troy Hunt, bl.a. kjent for have i been pwned?, holder en veldig god applikasjonssikkerhetsworkshop kalt Hack yourself first.
SpareBank 1 Utvikling har både leid inn Troy for å holde denne workshopen on-site, og sendt enkeltutviklere på fellesworkshops hos NDC Security. Det er en blanding av undervisning og oppgaver over to dager.
Troy har også mye innhold online på Pluralsight, inkludert Hack yourself first i videoform. Det er nok likevel ikke helt det samme som å delta på en workshop.
Fordeler:
- Nøkkelferdig opplegg fra profesjonell kursholder.
- To fulle dager lar en gå litt i dybden på mange tema. Holder man workshopen internt legger det rette til gode diskusjoner om hvordan man selv bygger løsninger.
Ulemper:
- Koster en del.
Hva innebærer egentlig input-validering?
#4: Bugbounties
I år opprettet vi en applikasjonssikkerhetsgruppe for jobbing sammen på fagdagen. Der har vi blant annet tenkt å jobbe med bugbounties. Bugbounty-program er uorganisert sikkerhetstesting: Firma registrerer løsningene sine hos tilbydere som Bugcrowd eller HackerOne, og så kan hver og en av oss sikkerhetsteste dem fritt innenfor de rammene de spesifiserer.
Det er en veldig god øvelse på å få se ting fra angriperens perspektiv. -Hva inneholder denne applikasjonen? Hva slags teknologistack finner vi, og hvordan kan vi prøve å misbruke funksjonalitet eller implementasjon?
HackerOne har forøvrig en flott Hacktivity-side, der fulle rapporter på publiserte sårbarheter ligger. Mye fin inspirasjon.
Fordeler:
- Det blir ikke mer realistisk enn produksjonsløsninger.
- Man får utforske varierte teknologistacker, og får reflektere litt over likheter og forskjeller, og patterns som legger opp til sårbarheter. Da blir det enklere å gjenkjenne dem i egne systemer.
- Det er veldig tilfredsstillende når man finner noe!
- En del av programmene utbetaler penger for funn.
«Det er veldig tilfredsstillende når man finner noe!»
Ulemper:
- Systemene som er del av slike programmer er typisk ganske modne, og det kan være relativt utfordrende.
- I motsetning til opplæringsløsninger og CTF’er er man aldri sikker på om det faktisk er en sårbarhet å finne i den delen av løsningen man pirker på.
- Man må være den første som rapporterer en gitt sårbarhet i en løsning for å bli premiert direkte. Det er likevel tilfredsstillende å finne.
- Programmene krever typisk en form for proof-of-concept-angrep som beviser sårbarheten. Avhengig av sårbarheten kan det være omfattende å lage. Se hacktivity for eksempler.
- De overspiller verdien av HTTPS-sertifikater
#5: Online training
Flere leverandører har opplegg for guidet selvopplæring i applikasjonssikkerhet. SpareBank 1 Utvikling har foreløpig ikke valgt å gå for en slik løsning, men det kan være det passer andre utviklingsorganisasjoner bedre.
Av de jeg har prøvd selv, virker Adversary som en av de mer komplette. Du kan teste dem selv, med denne gjennomgangen av en feil i autorisasjonskontrollen Facebook hadde i 2018.
Portswigger Academy er gratis, og har også noen gode labs det er verdt å ta en kikk på.
Fordeler:
- Lav terskel for å komme i gang.
- Dekker typisk bredt.
Ulemper:
- Noe varierende kvalitet og forvirrende plattformer.
#6: Verktøy
Skal man eksperimentere med websikkerhet er det veldig nyttig å bruke en webproxy, som lar en se og endre på trafikken mellom nettleser og server.
Noen alternativer:
- Burp Suite. Industristandarden. Koster litt i full utgave. Verdens eneste fungerende Java Swing-applikasjon!
- OWASP ZAP. Gratis, open source. Den andre Java Swing-applikasjonen.
- Charles proxy. Populært på Mac.
- Fiddler. Populært på Windows.
Heldigvis går de fleste seriøse webløsninger over TLS (https), men det betyr også at webproxyen til å terminere TLS-forbindelsen. For å unngå at nettleseren (med rette) protesterer på sertifikatfeil, forutsetter det at man setter opp nettleseren sin til å stole på CA-sertifikatet som proxyen har generert.
De forskjellige proxyleverandørene forklarer hvordan man går fram for å gjøre det, men et konkret tips er å bruke en dedikert nettleser, så slipper man å sende all legitim trafikk gjennom proxyen når man ikke tester.
Firefox har sitt eget oppsett av både proxy og sertifikater, mens andre i større grad baserer seg på globale systeminnstillinger.
«Om du kan, dra på Hack yourself first.»
Oppsummering
Her var det mye å velge mellom, selv om det ikke er en utfyllende liste. Mange av tilnærmingene utfyller hverandre på en god måte, men hvor skal man begynne?
Det kommer mye an på hvor mye man føler man kan, men en mulig rekkefølge å iterere over kan være:
- Om du kan, dra på Hack yourself first. Den har blitt holdt flere ganger i Norge, for eksempel på NDC Security i Oslo.
- Online training om noen tema, enten i de dedikerte løsningene foreslått over, eller på Pluralsight.
- Når man er klar til å eksperimentere litt selv kan må gå over på NATAS eller KWASHC.
- Bugbounties er supert når man er klar til å eksperimentere på virkelige systemer!
Happy hacking!
Takk til Vidar Moe, Adrian Alexander Eriksen, Kristoffer Berg, og Stian Conradsen.
- Hva er det som er så positivt med å legge koden din tilgjengelig?
8 risikoer ved Github og andre kodehus.