En pentester ankommer et ukjent nettsted og ser bare fasaden. De virkelige sårbarhetene, SQL-injeksjoner, XSS, path traversal, skjuler seg i dypet: skjulte kataloger, glemte endepunkter, ikke-åpenbare forespørselsparametere. Manuell gjennomgang sluker timer. Automatisert gjennomgang, uten riktig verktøy, bommer enten på kritiske inngangspunkter eller krasjer applikasjonen med en skred av forespørsler.

Burp Suite Professional løser denne oppgaven med en kombinasjon av «crawler + skanner». Én gjennomkjøring, og du har et applikasjonskart der hver side er sjekket for dusinvis av sårbarhetsklasser. Alt i ett vindu, uten skript eller kommandolinje.

Denne guiden er en trinnvis gjennomgang av Burp Suite sin crawler og skanner: fra grunnleggende gjennomgang til finjustering av revisjonen. Skjermbilder er oppdatert for 2024+-versjoner, logikken har ikke endret seg siden Burp 2.0. Vi dekker Crawl, Audit og den kombinerte Crawl and Audit-modusen.

💡 Rask oversikt:

• Start en grunnleggende crawl-skanning: Dashboard-fanen, New Scan, Crawl, få et nettstedskart i Target.
• Konfigurer crawleren for oppgaven din: ekskluder URL-er utenfor scope, legg til påloggingsinformasjon, juster forespørselspoolen.
• Gå videre til revisjon: Audit Selected Items på en hvilken som helst URL fra kartet, Burp finner sårbarheter og organiserer dem etter alvorlighetsgrad.
• Kombiner Crawl + Audit for ende-til-ende-testing: crawleren traverserer nettstedet, skanneren sjekker umiddelbart hver oppdagede side.
• Fullfør analysen ved å studere Advisory: payload, forespørsel/respons, CVSS og utbedringstrinn.

Hva er en web-crawler i Burp Suite

En web-crawler (også kjent som en spider) er en mekanisme som traverserer en webapplikasjon: følger lenker, sender inn skjemaer og logger inn i beskyttede seksjoner. Resultatet er et tre-lignende nettstedskart i Target-fanen, der hver URL kommer med HTTP-metoder og forespørselsparametere.

Frem til versjon 1.7 brukte Burp Suite Spider, et separat verktøy med sin egen fane. Fra og med Burp 2.0 erstattet PortSwigger det med Crawler, bygget direkte inn i Dashboard. Alle automatiserte handlinger, gjennomgang, revisjon, logging, er samlet i ett vindu. Administrasjon: pause/gjenoppta for hver oppgave separat.

I bunn og grunn gjør crawleren det samme som DirBuster eller Dirb: oppregner kataloger, registrerer skjulte URL-er. Men, i motsetning til dem, analyserer Burp Crawler sideinnhold, kjører JavaScript (hvis analyse er aktivert), og forstår applikasjonens navigasjonslogikk. DirBuster og Dirb brute-forcer bare ved hjelp av en ordliste. Crawler bygger en applikasjonsgraf.

Kjøre crawleren: grunnleggende skanning

Åpne Burp Suite og bytt til Dashboard-fanen. Panelet er delt inn i fire soner:

• Tasks, alle kjørende gjennomganger og skanninger. Herfra kan du pause, gjenoppta og vise detaljer for hver oppgave.
• Event log, Burp Suite-hendelser: proxy-oppstart, modulfeil, skanningsfullføring.
• Issue activity, oppdagede sårbarheter med filtrering etter alvorlighetsgrad og type.
• Advisories, detaljert kort for den valgte sårbarheten: payload, forespørsel/respons og CVSS.

Klikk på New Scan-knappen øverst i Tasks-seksjonen.

Et New Scan-popup-vindu vil dukke opp med to alternativer:

• Crawl and audit, gjennomgang + revisjon i én kjøring;
• Crawl, kun gjennomgang.

For en første introduksjon, velg Crawl. Skriv inn en test-URL, for eksempel http://testphp.vulnweb.com, og klikk OK.

Vinduet vil lukkes. I Dashboard under Tasks vil en ny oppgave dukke opp, «Crawl testphp.vulnweb.com». Event log vil bekrefte «Crawl started»-hendelsen.

Etter et par minutter vil oppgaven fullføres. Se etter resultatet i Target-fanen, crawleren sender ut nettstedskartet der i form av et URL-tre.

I høyre panel kommer hver URL med HTTP-metoder og en Parameters-kolonne. Parametere indikerer inngangspunkter, potensielt sårbare for injeksjoner. Dobbeltklikk på kolonneoverskriften Parameters, URL-er med parametere vil stige til toppen.

Venstre panel i Target er okkupert av nettstedstreet, klikkbart og med URL-nesting. Velg en hvilken som helst katalog, høyre panel viser umiddelbart dens metoder og parametere.

Finjustering av crawleren

Grunnleggende gjennomgang er tilstrekkelig for enkle nettsteder. Men en reell applikasjon er mer kompleks: noen sider er utenfor scope, lukkede seksjoner krever autorisasjon, og en skjør applikasjon tåler ikke dusinvis av samtidige forespørsler.

Vi går tilbake til Dashboard, klikker New Scan igjen, men nå skynder vi oss ikke med OK. Vi konfigurerer.

Ekskludere URL-er utenfor scope

I Scan details-seksjonen, finn Detailed scope configuration. Gå til Excluded URL prefixes og legg til en URL som ikke skal inkluderes i gjennomgangen, for eksempel http://testphp.vulnweb.com/signup.php.

Opprette en tilpasset konfigurasjon

Gå til Scan configuration og klikk på New-knappen.

Et vindu med parametere åpnes. Konfigurasjonsnavnet kan stå som standard. Nøkkelparameteret er Crawl optimization: en glidebryter fra «Fastest» til «Deepest» bestemmer hvor dypt gjennomsøkeren går inn i applikasjonen. For en produksjonstest setter du den nærmere Deepest, for rask rekognosering nærmere Fastest.

Tids- og sideantallsgrenser settes også her. Fornuftige verdier for en mellomstor applikasjon: Maximum crawl time, 50 minutter, Maximum unique locations discovered, 5000.

Påloggingsinformasjon for lukkede seksjoner

Hvis applikasjonen krever innlogging, kryss av for Log in to user registration portals og Log in using invalid credentials. Gjennomsøkeren vil forsøke å registrere seg med tilfeldige data eller oppgi bevisst feil påloggingsinformasjon for å se nettstedets oppførsel ved mislykket autentisering.

Klikk Save, konfigurasjonen vises i nedtrekkslisten Scan configuration.

La oss nå legge til ekte påloggingsinformasjon, de er nyttige hvis gjennomsøkeren støter på en adminportal eller lukket seksjon. Gå til Application login-seksjonen og klikk Create.

Skriv inn brukernavn og passord, klikk OK.

Ressurspool og samtidige forespørsler

Resource pool-seksjonen styrer hvor mange samtidige forespørsler gjennomsøkeren sender til applikasjonen og med hvilken forsinkelse. For en skjør applikasjon reduserer du antall tråder og øker forsinkelsen. For en demostand lar vi standardverdiene stå.

Klikk OK, gjennomsøkeren starter med den angitte konfigurasjonen. Vi følger fremdriften på Dashboard.

Etter fullføring går vi til Target-fanen. Siden signup.php er fraværende i sidekartet, det ekskluderte prefikset fungerte som tiltenkt.

Sårbarhetsskanning: revisjonsmodus

Kravleren gir oss et applikasjonskart. Revisjon går lenger, den sjekker oppdagede URL-er for sårbarheter: SQL-injeksjoner, XSS, kommandoinjeksjon, path traversal og dusinvis av andre klasser. I Burp Suite-terminologi kalles dette «aktiv skanning».

I motsetning til passiv skanning (analyse av responser uten ekstra forespørsler), sender aktiv revisjon modifiserte forespørsler med payloads og tolker applikasjonens respons.

Revisjon med standardinnstillinger

Hvis applikasjonen allerede er skannet av kravleren, kan du revidere enhver URL fra nettstedskartet. På Target-fanen høyreklikker du på basis-URL-en og velger Scan.

Vinduet New Scan åpnes igjen, men nå er alternativet Audit selected items aktivt. Alle URL-er fra nettstedskartet hentes automatisk inn i feltet Items to scan. Klikk OK.

Vi går til Dashboard. Bildet har endret seg: seksjonene Tasks og Event log er aktive, og viktigst av alt, Issue activity og Advisories har nå data.

I løpet av få minutter sendte skanneren omtrent 17 000 forespørsler og identifiserte sårbarheter gruppert etter alvorlighetsgrad: høy (rød), middels (gul), info (grå).

Et vindu med en fullstendig oversikt åpnes. Fanen Audit items viser sjekkede URL-er og antall oppdagede sårbarheter.

Fanen Issue activity viser den samme informasjonen brutt ned etter alvorlighetsgrad. Hver sårbarhet kan utvides for å se veiledningen.

Fanen Advisories viser hele kortet for den valgte sårbarheten. Øverst finner du URL, alvorlighetsgrad, konfidens, CVSS-score. Nedenfor ligger beskrivelsen, anbefalinger for utbedring og lenker til eksterne ressurser om denne sårbarhetsklassen.

For å se den spesifikke HTTP-forespørselen og -responsen som utløste funnet, gå til fanen HTTP request/response. Det er her du ser payloaden Burp sendte til applikasjonen og serverresponsen som bekrefter sårbarheten.

Finjustering av revisjonen

Standardrevisjonen dekker alle sårbarhetsklasser. Men noen ganger trenger du å snevre inn fokuset: sjekk bare SQL-injeksjoner eller bare XSS. Eller, omvendt, legg til egendefinerte sjekker for et spesifikt API.

Opprette en revisjonsprofil

Vi åpner vinduet New Scan igjen. I seksjonen Scan configuration klikker du på New for å opprette en revisjonskonfigurasjon.

I vinduet som åpnes, gå til fanen Audit optimization. Her er tre nivåer:

• Default, standard dekning, balanse mellom hastighet og dybde;
• Thorough, utvidet sett med payloads og dypere sjekking av hver parameter;
• Fast, lettvektsmodus, færre forespørsler og sjekker.

Seksjonen Issues reported lar deg velge spesifikke sårbarhetsklasser. La for eksempel bare SQL injection og Cross-site scripting stå igjen, så vil ikke skanneren kaste bort tid på å sjekke path traversal eller kommandoinjeksjon.

Under fanen Revisjonsoptimalisering > Tilpasset kan du mer nøyaktig konfigurere skjæringspunktet mellom klasser og intensiteten på kontrollene.

Skanntyper

Under fanen Revisjonsoptimalisering finnes en seksjon for Skanntype med fire aggressivitetsnivåer:

• Passiv, kun trafikkanalyse, ingen ekstra forespørsler. Trygg for produksjon, men finner bare headere og konfigurasjonsproblemer.
• Lett aktiv, minimalt sett med aktive kontroller. Kompromiss mellom dekning og risiko.
• Middels aktiv, flere kontroller, middels belastning. For staging.
• Intrusiv, fullt sett, inkludert destruktive kontroller. Kun på isolerte testmiljøer.

Samme sted kan JavaScript-analyse aktiveres valgfritt, slik at crawleren kjører JS for å oppdage dynamisk innhold og skjulte endepunkter i SPA-applikasjoner.

Det endelige valget av skanntype vises øverst i konfigurasjonsvinduet.

Injeksjonspunkter

Injeksjonspunkter er posisjoner i forespørsler der Burp setter inn payloads. Som standard bestemmer skanneren dem automatisk: URL-parametere, POST-body, headere, cookies. I avansert modus kan du begrense eller utvide settet med posisjoner.

Vi lagrer konfigurasjonen, og den dukker opp i nedtrekkslisten.

Klikk OK. Skanneren sender omtrent 2700 forespørsler (mot 17 000 ved en full revisjon) og finner ett sårbarhet med høy alvorlighetsgrad.

Når du nå høyreklikker på en URL i Target, dukker det opp ikke ett, men to skannealternativer: standard og vår tilpassede.

Innebygde kontroller fra biblioteket

Manuell revisjonskonfigurasjon er ikke påkrevd. Burp Suite leveres med et bibliotek av ferdige profiler. Når du oppretter en ny konfigurasjon, klikker du Velg fra bibliotek nederst i vinduet.

Velg en hvilken som helst innebygd profil, for eksempel en som er skreddersydd for en bestemt sårbarhetsklasse eller applikasjonstype.

Den valgte profilen hentes tilbake til vinduet New Scan.

Klikk OK. Etter at revisjonen er fullført, viser URL-kontekstmenyen i Target tre skannealternativer: standard, egendefinert og bibliotek.

Skanning + revisjon i én kjøring

Så langt har vi kjørt gjennomsøking og revisjon hver for seg. Men Burp Suite støtter ende-til-ende-modusen Crawl and Audit: først traverserer den applikasjonen, og deretter sjekker den umiddelbart alt som ble funnet for sårbarheter.

Klikk New Scan igjen på Dashboard, velg Crawl and audit, og angi URL-en.

I konfigurasjonsdelen, når du klikker Create, spør Burp hvilken del som skal konfigureres: gjennomsøkingsoptimalisering eller revisjonsparametere. De interne parameterne er de samme som vi så separat.

Dette er hovedmodusen for produksjonspenetrasjonstesting: én kjøring dekker både rekognosering og sårbarhetsoppdagelse. For store applikasjoner med titusenvis av sider er det raskere å dele opp i to trinn, først gjennomsøkingen, deretter revisjonen. Men for de fleste nettsteder leverer Crawl and Audit resultater i én gjennomkjøring.

Oppgavehåndtering: sletting og opprydding

Fullførte og utdaterte oppgaver bør slettes for å unngå å rote til Dashboard. Klikk på søppelbøtteikonet ved siden av oppgaven.

Bekreft slettingen i popup-vinduet.

Oppgaver slettes umiddelbart, sammen med alle innsamlede data. Før du sletter, må du forsikre deg om at revisjonsresultatene er lagret eller eksportert.

Video: komplett gjennomgang av Burp Suite Scanner

Gjennomsøkeren og skanneren er bare en del av Burp Suite. Denne videoen dekker hele penetrasjonstestsyklusen: fra proxy-konfigurasjon til aktiv revisjon og utnyttelse av oppdagede sårbarheter.

⁉️🤔 Ofte stilte spørsmål

Hvordan skiller Burp Suite sin crawler seg fra DirBuster og Dirb?

DirBuster og Dirb jobber fra en ordliste og teller opp katalognavn fra en ferdiglaget liste. Burp Suite Crawler bygger en applikasjonsgraf: analyserer sideinnhold, trekker ut lenker, sender inn skjemaer og kan logge inn. Resultatet er et applikasjonskart med navigasjonsrelasjoner, metoder og parametere. Den finner det ordlister ikke har: dynamiske URL-er, inngangspunkter via JavaScript-viderekoblinger og skjulte endepunkter bak innloggingsskjemaer.

Hvilken versjon av Burp Suite trengs for crawler og audit?

Crawler og aktiv audit er kun tilgjengelig i Burp Suite Professional ($499 per bruker per år for 2026, Burp Suite Professional priser). Community Edition inkluderer proxy, Repeater, Intruder med ratebegrensning og Decoder, men ikke Crawler og ikke Scanner. Professional gir begge verktøyene pluss ubegrenset Intruder, Collaborator og BCheck-skript for egendefinerte sjekker. Fra og med versjon 2025 inkluderer Professional også Burp AI, en AI-assistent for tolkning av skanneresultater. Enterprise Edition legger til CI/CD-integrasjon, planlegger og teamsamarbeid.

Kan man skanne et nettsted som ikke er synlig fra internett?

Crawler og audit fungerer gjennom Burp Suite sin oppstrømsproxy. Alt som er tilgjengelig for nettleseren gjennom Burp Proxy er tilgjengelig for crawleren: localhost, staging-servere bak VPN, bedriftsportaler. Ingen ekstra nettverkskonfigurasjon er nødvendig, scope settes via Target scope.

Hvordan unngå å krasje produksjon med aktiv audit?

Velg Light active i stedet for Intrusive. Deaktiver sjekker med risiko for datakorrupsjon: SQL-injeksjon med INSERT/UPDATE/DELETE, destruktiv kommandoinjeksjon, filopplasting. Tre regler: (1) Kun passive for første gjennomkjøring, (2) Light active uten intrusive-sjekker for andre, (3) Intrusive kun på staging. Ressurspool: 1 tråd, 500 ms forsinkelse.

Hva er forskjellen på passiv audit og aktiv audit?

Passiv audit (Passive scanning) sender ikke nye forespørsler, den analyserer trafikk som allerede har passert gjennom proxyen: headere, cookies, responskropper. Aktiv audit (Active scanning) genererer nye forespørsler med modifiserte payloads. Passiv vil ikke finne SQL-injeksjon, men vil identifisere manglende sikkerhetsheadere og cookies uten HttpOnly/Secure. I praksis brukes begge sekvensielt: passiv mens man surfer, aktiv rettet mot interessante endepunkter.

Hvor relevant er Burp Suite i 2026?

Burp Suite forblir de facto-standarden for web-pentesting. I 2025 la PortSwigger til en AI-assistent for sårbarhetsanalyse, i 2026 en kombinert Professional/Community-installer, Markdown-notater og utvidet HTTP-trafikkontroll. Konkurrenter (OWASP ZAP, Caido) er på fremmarsj, men når det gjelder dybde i aktiv audit og utvidelsesøkosystem, er Burp fortsatt utilgjengelig.

Hvilken Burp Suite-modus du bør velge for oppgaven din

Crawler, audit eller begge samtidig, valget avhenger av pentest-stadiet og målet.

Hvis du trenger å bygge et applikasjonskart før manuell analyse, kjør Crawl med Deepest-optimalisering. Legg til påloggingsdetaljer for lukkede seksjoner og ekskluder URL-er utenfor scope (utloggingssider, passordtilbakestilling).

Hvis kartet allerede finnes og målet er å finne sårbarheter, bruk Audit på et spesifikt sett med URL-er. For første gjennomkjøring, Passive + Light active. La Intrusive være igjen til staging.

For omfattende testing «fra bunnen av», Crawl and Audit. Én kjøring, minimale manuelle operasjoner.

Og hovedregelen: kjør aldri Intrusive på andres produksjon uten skriftlig samtykke. Selv Light active etterlater spor i serverlogger.