Web Application Security

Pentest Report Project

Et eksamensbasert webapplikasjons-pentestprosjekt fra ETH2100, gjennomført mot den fiktive kunden Boris Lockpicks i et kontrollert VM-labmiljø. Prosjektet handlet om å kartlegge mål, vurdere funn, forstå scope og presentere sårbarheter i en profesjonell pentest-rapport.

Web securityPenetration testingEthical hackingKali LinuxNmapOWASP ZAPNiktoSSLyzeSource reviewReporting
Kontekst
ETH2100 / Boris Lockpicks
Type
Akademisk lab / eksamensoppgave
Rolle
Testing, validering og rapportering
Fokus
Scope, risiko og tiltak

Oversikt

Pentest Report Project var et klientlignende eksamensprosjekt i ETH2100 Etisk Hacking. Oppgaven var å gjennomføre en teknisk sikkerhetsvurdering av en webapplikasjon i et kontrollert labmiljø og levere en skriftlig rapport i profesjonell pentest-stil.

Scenarioet var knyttet til den fiktive kunden Boris Lockpicks, som hadde en webshop i beta. Prosjektverdien lå ikke bare i å finne tekniske svakheter, men i å tolke funn, dokumentere dem ryddig og forklare risiko og tiltak på en måte en mottaker kan bruke.

Scope og rammer

Testingen var avgrenset til den utdelte Boris Lockpicks VM-en og labmiljøet. Applikasjonen kjørte som en beta-webshop i en VMware-basert Host-Only/VMNet1-konfigurasjon, og målmaskinen fikk dynamisk IP-adresse via DHCP.

Oppgaven tillot whitebox-testing og statisk kodegjennomgang fordi kildekode var tilgjengelig som del av eksamensmaterialet. Samtidig var OSINT og sosial manipulering eksplisitt utenfor scope, og det selvsignerte TLS-sertifikatet skulle ikke rapporteres som en sårbarhet.

  • Målet var en kontrollert VM-lab, ikke et ekte produksjonsmiljø.
  • Boris Lockpicks var en fiktiv kunde og ikke et kommersielt oppdrag.
  • Serveren skulle vurderes bredere enn bare webserveren på port 443.
  • Funn måtte dokumenteres i en profesjonell rapport med tydelig risiko og anbefalte tiltak.

Min rolle

Jeg arbeidet med målkartlegging, forståelse av laboppsettet, verktøystøttet testing, manuell validering og kildekodegjennomgang der det var relevant.

Prosjektet innebar også å vurdere relevans og utnyttbarhet innenfor scope, strukturere bevis, skrive risikoforklaringer og formulere forbedringstiltak som passet en profesjonell rapport.

Methodology

Testingstilnærming

Arbeidet startet med å identifisere målmaskinen i labnettverket og kartlegge eksponerte tjenester. Deretter ble webapplikasjonen gjennomgått med en kombinasjon av automatiserte verktøy, manuell testing og kildekodekontekst der det ga verdi.

Nmap ble brukt for tjenestekartlegging, OWASP ZAP for webapplikasjonsskanning, Nikto for web- og serverobservasjoner, SSLyze for TLS-relatert analyse og nettleserbasert testing for manuell validering. Verktøyfunn ble behandlet som signaler som måtte tolkes, ikke som ferdige rapportfunn.

  • Finne riktig mål i et dynamisk VM-labnettverk.
  • Kartlegge tjenester og vurdere hva som burde undersøkes videre.
  • Gjennomgå webfunksjonalitet og scanner-output med manuell kontroll.
  • Bruke kildekodekontekst for å forstå relevans og sannsynlighet.
  • Prioritere funn basert på risiko, scope og praktisk utnyttbarhet.
  • Dokumentere nok bevis til at rapporten ble etterprøvbar uten å bli en exploit-oppskrift.

Viktige testområder

Testingen dekket flere områder rundt applikasjonen og servermiljøet. Målet var å skille mellom relevante funn, konfigurasjonsobservasjoner og støy fra automatiserte verktøy.

  • Service discovery: kartlegging av åpne porter og tjenester for å avgjøre videre testløp.
  • Webapplikasjonstesting: gjennomgang av funksjonalitet med scanner-output og manuell validering.
  • Inputvalidering: vurdering av hvordan brukerinput ble håndtert uten å publisere payloads eller exploit-steg.
  • Autentisering og tilgang: vurdering av innlogging, mulig credential-eksponering og kontorisiko innenfor lab-scope.
  • Server og konfigurasjon: vurdering av eksponering og konfigurasjonsfunn med respekt for oppgavens avgrensninger.
  • Rapportering og tiltak: oversette tekniske observasjoner til strukturerte funn, alvorlighet og anbefalte forbedringer.

Rapportering og kommunikasjon

Prosjektet handlet ikke bare om å finne tekniske svakheter, men om å gjøre funnene forståelige. Et godt pentest-funn må forklare hva som ble observert, hvorfor det betyr noe, hvilken risiko det gir, og hva som bør gjøres videre.

Den skriftlige leveransen måtte strukturere funn i tydelige tabeller med nummerering, tittel, alvorlighet, forklaring, bevis og anbefalte tiltak. Scanner-output måtte tolkes og prioriteres, ikke bare kopieres inn i rapporten.

Sikkerhet og etikk

Siden prosjektet var en etisk hacking-oppgave, var scope og autorisasjon en sentral del av arbeidet. Testingen ble behandlet som et kontrollert labscenario med tydelige grenser, ikke som ubegrenset angrep mot en reell kunde.

Offensive teknikker ble brukt med defensiv hensikt: å forstå risiko, dokumentere funn og foreslå forbedringer. Den offentlige case study-en inkluderer derfor ikke passord, payloads, kommandoer eller steg-for-steg utnyttelse.

  • OSINT og sosial manipulering var utenfor scope og ble ikke behandlet som testmål.
  • Det selvsignerte sertifikatet ble ikke rapportert som en sårbarhet fordi oppgaven eksplisitt avgrenset det.
  • Labfunn ble ikke fremstilt som produksjonsrisiko uten kontekst.
  • Risiko ble forklart uten å overdrive eller gjøre rapporten til en angrepsguide.

Utfordringer

En viktig utfordring var å skille reelle funn fra scannerstøy og avgjøre hva som faktisk hørte hjemme i hovedrapporten. En beta-applikasjon kan ha uferdig funksjonalitet, men en pentest-rapport må likevel være presis og nyttig.

  • Forstå labnettverk, VMNet1-oppsett og dynamisk IP-adresse før testingen kunne starte.
  • Balansere teknisk detalj med lesbarhet for en kundeorientert rapport.
  • Dokumentere nok bevis uten å gjøre rapporten unødvendig tung.
  • Forklare risiko og tiltak uten å overclaim'e alvorlighet.
  • Bruke kildekodekontekst uten å miste fokus på faktisk observerbar risiko.

Hva jeg lærte

Prosjektet ga praktisk erfaring med hvordan tekniske observasjoner blir til en profesjonell pentest-rapport. Det styrket forståelsen av at god sikkerhetstesting handler like mye om scope, validering og kommunikasjon som om verktøybruk.

  • Hvordan strukturere en profesjonell pentest-rapport med funn, risiko og tiltak.
  • Hvordan koble tekniske observasjoner til reell risiko og forretningsmessig relevans.
  • Hvordan tolke scanner-output og validere funn manuelt.
  • Hvordan scope avgjør hva som skal testes, rapporteres og utelates.
  • Hvordan skrive forbedringsråd som er nyttige uten å være exploit-orienterte.
  • Hvordan jobbe ansvarlig med offensive teknikker i et kontrollert VM-labmiljø.

Resultat

Pentest Report Project demonstrerer praktisk erfaring med webapplikasjonssikkerhet, kontrollert labtesting, tjenestekartlegging, sårbarhetsvurdering, scope-bevisst testing og evidensbasert rapportering.

Som portfolio-case viser prosjektet hvordan jeg jobber med etisk hacking på en ansvarlig måte: teknisk nok til å undersøke funn, men strukturert nok til å kommunisere risiko og defensive tiltak tydelig.

Visuelle plassholdere

Områder for fremtidige rapportbilder

Plassholderne viser hvor fremtidige utdrag fra rapportstruktur, verktøyoversikter og defensive anbefalinger kan legges inn.

Discovery

Service discovery / Nmap-oversikt

Fremtidig plass for en trygg, redigert oversikt over tjenestekartlegging og scope-relevante observasjoner.

Rapportutdrag kan legges inn senere

Web scan

Web scan summary

Fremtidig plass for et ikke-sensitivt sammendrag av webskanningsresultater og validerte observasjoner.

Rapportutdrag kan legges inn senere

Validation

Manuelle valideringsnotater

Fremtidig plass for anonymiserte notater som viser hvordan funn ble kontrollert før rapportering.

Rapportutdrag kan legges inn senere

Report

Sårbarhetstabell og rapportstruktur

Fremtidig plass for rapportlayout med nummererte funn, alvorlighet og anbefalte tiltak.

Rapportutdrag kan legges inn senere

Remediation

Tiltak og forbedringsforslag

Fremtidig plass for defensive anbefalinger skrevet for utviklere eller systemansvarlige.

Rapportutdrag kan legges inn senere