Sikkerhetsrevisjon av webapplikasjoner og nettbutikker

Vi tester webapplikasjoner, API-er og WordPress- eller WooCommerce-butikker slik en angriper ville gjort, går gjennom koden og serveroppsettet og gir dere en rapport som sier hva som bør rettes først. Etter rettingene tester vi på nytt. Vi jobber bare med skriftlig tillatelse fra eieren av systemet.

Når en revisjon lønner seg

Sikkerhetsproblemer melder sjelden fra om seg selv. En revisjon utløses som regel av en endring: en lansering, noen som slutter, et spørsmål fra en partner.

En utvikler har sluttet, og dere er ikke sikre på hvilke nøkler og tilganger som forsvant med vedkommende
Produktet skal snart lanseres, og ingen har sett på det med en angripers øyne
En partner, investor eller bedriftskunde ber om bevis på at plattformen er testet
Nettbutikken kjører på dusinvis av plugins, og for én av dem er det nettopp publisert en sårbarhet
Produktet er bygd på et gammelt rammeverk som ingen i teamet vil røre
Dere har rettet funnene fra en tidligere revisjon og trenger noen som bekrefter at de er lukket

Hva vi sjekker

Testing av webapplikasjoner

Manuell testing av applikasjonen og forretningslogikken: tilgangskontroll, håndtering av inndata, filopplasting, økter og flytene der penger eller personopplysninger skifter hender.

API-er og autentisering

Innlogging, tilbakestilling av passord, tokens og håndtering av JWT, roller og rettigheter. Vi sjekker om én bruker kan nå en annen brukers data ved å endre en ID i en forespørsel.

WordPress og WooCommerce

Plugins og temaer med kjente sårbarheter, administratortilgang, eksponerte filer og konfigurasjon, og logikken i kassen, som priser, rabattkoder og endringer i ordrestatus.

Sikkerhetsgjennomgang av kode

Vi leser koden og historikken på jakt etter hemmeligheter i repositoriet, usikre spørringer, manglende kontroller og utdaterte biblioteker, også i eldre teknologistakker ingen har gått gjennom på mange år.

Herding av servere

SSH- og brannmurregler, åpne porter, TLS, sikkerhetshoder, rettigheter for database og filer, sikkerhetskopier lagret atskilt fra serveren, og beskyttelse mot brute force som ikke stenger ute deres eget kontor.

Ny test

Etter at teamet deres eller vårt har rettet funnene, tester vi hvert av dem på nytt og oppdaterer rapporten med status.

Hva vi ikke gjør

Disse reglene er en del av hver avtale og kan ikke forhandles.

Vi tester ikke noe system uten skriftlig tillatelse fra eieren
Vi kjører ikke belastningstester eller tjenestenektangrep mot produksjon uten en egen avtale
Vi deler ikke funn med andre enn kontaktpersonene som er navngitt i avtalen
Vi beholder ikke dataene eller testkontoene deres etter at arbeidet er avsluttet

En rapport som sier hva som bør rettes først

En liste med to hundre advarsler fra en skanner hjelper ikke et team å bestemme hva de skal gjøre på mandag. Rapporten vår vurderer hvert funn etter alvorlighetsgrad med CVSS, viser bevisene, for eksempel forespørselen og svaret som beviser problemet, forklarer hvordan det kan gjenskapes og sier hvordan det rettes. Eieren får et sammendrag for ledelsen på vanlig språk, og utviklerne får en tiltaksplan sortert etter risiko og innsats.

Der alvorlige problemer som regel skjuler seg

Automatiske skannere finner utdaterte versjoner. Problemene som lar noen ta over kontoer, ligger som regel et annet sted: et API som returnerer en annen kundes bestilling når nummeret i forespørselen endres, en signeringsnøkkel som ble lagt inn i repositoriet for flere år siden, en administratorrute som sjekker innloggingen, men ikke rollen, en kasse som stoler på prisen nettleseren sender, en sikkerhetskopi som er lagt igjen i en offentlig mappe. Å finne disse krever en person som leser koden og prøver flytene manuelt, og det er slik vi tester.

Ny test og herding, slik at rapporten ikke blir slutten

En revisjon lønner seg først når funnene er lukket. Etter rettingene tester vi hvert funn på nytt og merker det som lukket, delvis rettet eller fortsatt åpent. Hvis dere ønsker det, gjør utviklerne våre rettingene selv, og serverteamet vårt herder infrastrukturen: tilgang bare med nøkler, en brannmur som bare eksponerer det som må være offentlig, oppdatert TLS, egne databasebrukere med minimale rettigheter og sikkerhetskopier holdt unna serveren de beskytter.

Slik foregår en revisjon

Omfang og tillatelse

Vi avtaler hva som testes, hvorfra og når, og eieren av systemet signerer en skriftlig fullmakt. Dere stiller med testkontoer og, for en kodegjennomgang, tilgang til repositoriet.

Testing

Vi kartlegger applikasjonen, tester den manuelt og går gjennom koden og serveroppsettet innenfor det avtalte omfanget. Alt kritisk rapporteres til dere med en gang, det spares ikke til rapporten.

Rapport

Dere får funn vurdert med CVSS, bevis, rettinger, et sammendrag for ledelsen og en tiltaksplan, og vi går gjennom dem med teamet deres.

Rettinger

Deres eller våre utviklere jobber seg gjennom planen i rekkefølge etter risiko.

Ny test

Vi tester hvert funn på nytt og utsteder en oppdatert rapport med status for hvert av dem.

Hva vi tester og mot hvilke standarder

Standarder

Applikasjoner

Plattformer og teknologistakker

Infrastruktur

Slik kan vi samarbeide

Revisjon med ny test

Et fast omfang: testing, rapport og en ny test etter at teamet deres har rettet funnene.

Revisjon og rettinger

Vi tester, retter funnene i koden og på serveren, og bekrefter med en ny test.

Jevnlige gjennomganger

En gjennomgang før større releaser eller etter en fast plan, ofte kombinert med drift av nettsted eller servere.

Tilbakemeldinger

Vi behandler hver kunde og prosjektet deres med omtanke.

Revol-teamet fortsetter å effektivisere kundens utviklingskapasitet med arbeid av høy kvalitet og pålitelig support. De kommuniserer godt og viser en solid forståelse av kundens behov og virksomhet.

Tomas

Daglig leder (Yukon, Canada)

Arbeidet fra Revol har fullt ut innfridd forventningene, og kunden er fornøyd. Den friske tilnærmingen og evnen til å være tilgjengelige for support har vært verdifulle. Kunder kan trygt velge dem som et kommunikativt og kundeorientert team som hjelper dem å nå målene sine.

Andrey

Daglig leder, Stellium (USA)

Ofte stilte spørsmål

Trenger dere skriftlig tillatelse fra oss?

Ja, alltid. Eieren av systemet signerer en fullmakt som angir omfang, adresser og datoer. Kjører systemet hos en hosting- eller skyleverandør, følger vi også leverandørens regler for sikkerhetstesting.

Vil testingen ødelegge nettstedet vårt i drift?

Vi avtaler grensene på forhånd. Der det er mulig, tester vi på en testkopi med samme kode. I produksjon bruker vi testkontoer, unngår destruktive handlinger og kjører ikke belastningstester uten en egen avtale.

Hvordan skiller dette seg fra en automatisk sårbarhetsskanning?

En skanner finner kjente versjoner og vanlige feilkonfigurasjoner, og vi bruker også skannere. Funnene som betyr mest, som at én bruker kan lese en annen brukers data eller at en pris endres i nettleseren, krever en person som forstår applikasjonen og tester den manuelt.

Hva får vi helt konkret?

En rapport der hvert funn er vurdert med CVSS, med bevis, fremgangsmåte for å gjenskape det og retting, et sammendrag for ledelsen og en tiltaksplan. Etter den nye testen får dere en oppdatert versjon med status for hvert funn.

Kan dere rette det dere finner?

Ja. Utviklerne våre kan rette koden, og serverteamet vårt kan herde infrastrukturen. Noen kunder foretrekker at deres eget team retter og at vi verifiserer, og det fungerer like godt.

Er den nye testen en del av revisjonen?

Vi planlegger den inn i omfanget fra starten, fordi en revisjon uten ny test lar dere gjette om rettingene virket. Når den nye testen skjer, avhenger av hvor raskt rettingene gjøres.

Hvordan håndterer dere dataene våre og funnene?

Vi jobber under en taushetserklæring, deler funn bare med kontaktpersonene som er navngitt i avtalen, og sletter testdata og tilganger når arbeidet er avsluttet. Vi publiserer aldri detaljer om det vi finner.

Er dette en sertifisering?

Nei. Vi er ikke et sertifiseringsorgan, og rapporten er ikke et samsvarssertifikat. Den kan støtte arbeidet deres med regelverksetterlevelse og viser partnere som ber om bevis på testing, nøyaktig hva som ble sjekket og hvordan.