Rapport

Slik ser rapporten ut

Rapporten er det du sitter igjen med. Den skal kunne leses av ledelsen på fem minutter og av en utvikler i to timer, uten at noen av dem må gjette.

Oppbygging

Hva rapporten inneholder

Sammendrag for ledelsen
Én side uten fagspråk: hva som ble testet, hva som ble funnet, hvor alvorlig det er og hva som bør gjøres først. Den kan videresendes til styret eller til en kunde som spør, uten at du må skrive den om.
Bekreftede funn
Ett oppslag per funn, nummerert F-01 og oppover, med alvorlighetsgrad, berørt ressurs, dokumentasjon på hvordan det ble funnet, hva konsekvensen er og hva som må endres. Der det finnes en relevant standard, står referansen med, for eksempel OWASP API5:2023.
Det som holdt, og hvorfor
En egen del med det som ble angrepet uten å gi etter, og hva dere har gjort bra. Ble et forsøk stoppet, står det hvorfor, og hvilken kontroll som tok det. Kom vi rundt den likevel, står det også, og hvordan. Da vet dere både hva som virker og hvor langt det rekker.
Dekning og gjenstående punkter
Hva som ble rukket, hva som ikke ble det, og hva som krever noe fra dere før det kan testes. Ingenting ligger igjen som en stilltiende antakelse.
Rekkefølge på utbedring
Funnene sortert i den rekkefølgen de bør fikses, ikke bare etter alvorlighetsgrad. Noen ting er raske og fjerner mye risiko; andre er store og kan vente.
Opprydding etter testen
Testdata, kontoer og eventuelle spor vi har lagt igjen, og hva som er fjernet. Du skal slippe å lure på hva som fortsatt ligger i systemet etter at vi er ferdige.
Vedlegg
Kjente CVE-er i komponentene som er i bruk, oversikt over teknologi og versjoner, og kontroll av tredjepartskomponenter. Det som er sjekket automatisk og vist seg å være falske positive, står oppført som nettopp det: avvist, med begrunnelse.

Skala

Hva gradene betyr

Alvorlighetsgraden settes etter hva som faktisk kan skje, ikke etter hva et verktøy skriver ut.

Alvorlighetsgrad: Kritisk
Utnyttbar nå, med direkte tilgang til data eller systemer. Fikses først.
Alvorlighetsgrad: Høy
Utnyttbar med moderat innsats, eller gir vesentlig utvidet tilgang.
Alvorlighetsgrad: Middels
Krever spesielle forutsetninger, eller gir begrenset tilgang alene.
Alvorlighetsgrad: Lav
Liten praktisk risiko, men bør ryddes opp i.
Alvorlighetsgrad: Info
Observasjon uten direkte risiko. Tatt med for fullstendighetens skyld.

Eksempler

Tre funn, slik de står i rapporten

Funnene under er ekte i form, men anonymisert: domener, adresser og identifikatorer er byttet ut med verdier som er reservert for dokumentasjon.

Alvorlighetsgrad: KritiskF-01

Innlogget bruker kan hente dokumenter som tilhører andre kunder

Berørt
GET /api/v2/documents/{id} på app.eksempel.no
Dokumentasjon
# Innlogget som bruker i tenant 1188. GET /api/v2/documents/8841 HTTP/1.1 Host: app.eksempel.no Authorization: Bearer <token, tenant 1188> HTTP/1.1 200 OK Content-Type: application/json {"id":8841,"tenantId":"1207","tittel":"Styreprotokoll Q3","eier":"…"} # ^^^^ dokumentet tilhorer en annen kunde
Konsekvens
Enhver innlogget bruker kan lese dokumenter på tvers av kunder ved å telle seg gjennom id-ene. Det holder med en vanlig konto. Ingen administratorrettigheter er nødvendig. Dokumentene i miljøet inneholder styrepapirer og personopplysninger.
Tiltak
Sjekk tilhørighet i endepunktet, ikke i grensesnittet: hent dokumentet med både id og tenant-id i spørringen, og svar 404 når de ikke stemmer overens. Legg samme sjekk i et felles lag som alle dokumentendepunkter går gjennom, og dekk den med en test som forsøker et fremmed dokument.
Referanser
CWE-639 · OWASP API1:2023
Alvorlighetsgrad: HøyF-02

Domenet ber ikke mottakere gjøre noe med forfalsket e-post

Berørt
_dmarc.eksempel.no
Dokumentasjon
$ dig +short TXT _dmarc.eksempel.no "v=DMARC1; p=none; rua=mailto:[email protected]" $ dig +short TXT eksempel.no "v=spf1 include:spf.protection.outlook.com ~all"
Konsekvens
SPF finnes, men DMARC står på p=none. Mottakere blir dermed bedt om å ikke gjøre noe med e-post som utgir seg for å komme fra domenet. En faktura sendt i virksomhetens navn fra en fremmed avsender blir levert som vanlig i innboksen til kunder og leverandører.
Tiltak
Les rapportene som allerede kommer inn på rua-adressen og bekreft at all legitim utsending er dekket av SPF og DKIM. Gå så til p=quarantine med pct=100, og videre til p=reject når rapportene er rene. Sett samtidig SPF til -all i stedet for ~all.
Referanser
RFC 7489
Alvorlighetsgrad: MiddelsF-03

Origin-serveren svarer direkte, utenom CDN-et

Berørt
203.0.113.24:443
Dokumentasjon
$ curl -sI https://www.eksempel.no --resolve www.eksempel.no:443:203.0.113.24 HTTP/2 200 server: nginx/1.24.0 x-cache: MISS x-served-by: origin-01 # Samme forespørsel gjennom CDN-et treffer brannmuren i front.
Konsekvens
Origin-adressen er nåbar direkte. Da kan trafikk sendes utenom brannmuren og ratebegrensningen som ligger i CDN-et, og eventuelle blokkeringsregler der får ingen effekt.
Tiltak
Slipp bare inn trafikk fra CDN-leverandørens adresseområder i brannmuren foran origin, og avvis resten. Krev i tillegg et delt hode eller et klientsertifikat mellom CDN og origin, slik at direkte forespørsler avvises selv om adressen blir kjent.

Neste

Vil du ha en slik rapport for deres oppsett

Bestill en test, så får du svar innen én virkedag med scope-dokument til signering og bekreftet testvindu.