Installationen och laborationsmiljön definierar ramarna: isolerade VirtualBox‑nät, fasta privata IP‑adresser och avstängd internetåtkomst skapar en säker testbädd där sårbarheter kan utnyttjas utan risk för extern påverkan. I denna miljö belyses flera återkommande feltyper: svaga hashfunktioner och avsaknad av salt, okrypterad HTTP‑trafik, föråldrade TLS‑konfigurationer, svaga JWT‑signeringsnycklar och exponerade objektlagringar. De konkreta övningarna — SQL‑injektion mot DVWA där användarhashar extraheras och knäcks med hashcat, paketavlyssning av ett PHP‑inloggningsformulär med Wireshark, analys av TLS‑svagheter med testssl.sh och Burp, bruteforce mot JWT‑nycklar samt åtkomst till en publik S3‑bucket via localstack — visar repeterbart hur dessa fel leder till konfidentiell dataexfiltration eller fullständig kompromiss av applikationsbehörigheter.

Analysen visar gemensamma svagheter: äldre och snabba hashalgoritmer som MD5 saknar arbetsfaktor och salt, vilket gör dem trivialt utsatta för ordlista‑ och GPU‑drivna attacker; HTTP överför känsliga fält i klartext och är därmed mottagligt för MITM; svag eller felkonfigurerad TLS (t.ex. stöd för TLS 1.0 eller RC4) underminerar transportens konfidentialitet; korta eller förutsägbara JWT‑hemligheter tillåter tokenförfalskning; och felaktiga åtkomstkontroller i objektlagring läcker filer publikt. Praktiska resultat i labbet—återfunna lösenord, avlästa POST‑fält, testssl‑rapporter, knäckta JWT‑nycklar och hämtade filer från en publik bucket—dokumenteras och arkiveras som PCAP, hashlistor, Burp‑förfrågningar och skärmdumpar för att ge spårbar evidens och för att jämföra variationsförsök (t.ex. MD5 vs SHA‑1, TLS 1.0 vs TLS 1.3).

Att genomföra dessa övningar kräver disciplin: återställ VMen mellan tester för att undvika korruption, isolera miljön från produktion och internet, och spara artefakter i ett strukturerat format (t.ex. CherryTree) med tydliga kataloger per assessment. Verktygsspecifika problem—GPU‑fel i hashcat, beroendeproblem i jwt_tool eller nätverkskonfigurationer—avhjälps genom logggranskning, uppdatering av paket och omstart av tjänster. I en professionell pentest‑rapport skall resultaten korreleras med sannolik påverkan: ett knäckt admin‑lösenord i testmiljö motsvarar potentiell full ägarskap i produktion om samma svagheter finns.

Förebyggande åtgärder följer av samma principer som angreppen exponerar. För lösenord: använd minnes‑ eller arbetskrävande hashfunktioner (Argon2 eller Bcrypt) med per‑användare salt och en lämplig kostnadsparameter; undvik SHA‑familjen och MD5 för lagring av autentiseringshemligheter. För transport: kräver moderna protokoll—TLS 1.3 eller sen TLS 1.2 med säkra ciphersuites—och helt avaktiverade svaga protokoll som SSLv2/SSLv3/TLS 1.0. För JWT hantering: använd starka, entropirika signeringsnycklar och överväg asymmetrisk signering (RS/ES) där det är lämpligt; validera algoritmfältet strikt och tillåt inte “alg: none”. För molnlagring: hårdställ åtkomstkontroller, tillämpa principen om minsta privilegium och granska policys och offentlig åtkomst regelbundet. Implementera dessutom övervakning och loggning så att misstänkta åtkomstmönster upptäcks tidigt.

Vid pedagogisk användning av dessa övningar är det viktigt att jämföra svårighetsgrader och mitigationskostnad: att byta hashalgoritm har en annan utvecklings- och driftskostnad än att migrera TLS‑konfigurationer eller byta JWT‑arkitektur, och beslut bör prioriteras efter riskanalys. Dokumentera alltid konfigurationer före och efter ändring så att förbättringer kan mätas. Utöver tekniska kontroller är organisatoriska åtgärder centrala: säkra utvecklingsrutiner, hemlighetshantering (t.ex. secrets managers), regelbundna kod‑ och konfigurationsgranskningar samt återkommande labbtester för att verifiera att åtgärderna fungerar i praktiken.

Vad läsaren behöver förstå utöver det ovanstående: hur angriparens kostnad och tillgängliga verktyg (GPU‑kluster, ordlistor, MITM‑verktyg) påverkar realiserbarheten av en attack; att labbframgång inte automatiskt översätts till produktion utan att kontextuella faktorer (infrastruktur, nätverksisolering, användarbeteenden) kan höja eller sänka risken; att säkerhet är ett lager av åtgärder där kryptografi, konfiguration, åtkomstkontroll och processer måste samverka; och att verifierbarhet—loggar, artefakter, reproducerbara tester—är lika viktigt som upptäckten själv för att kunna rekommendera och validera effektiva motåtgärder.

Hur säkrar man mot deserialiserings- och CI/CD-integritetsfel?

Oavsiktlig deserialisering av opålitliga data, felkonfigurerade pipeliner och osignerade artefakter utgör samma grundläggande hot: exekvering eller injektion av kod utanför a

Vad bör man förstå om etiska och juridiska överväganden vid penetrationstestning av webben?

Webbpenetrationstestning innebär att simulera angrepp på ett system, vilket är en teknik som både etiskt och juridiskt är mycket känslig. Penetration