H4 Täysin Laillinen Sertifikaatti

Tekijä: Aapo Tavio

Pohjana Tero Karvinen 2026: Tunkeutumistestaus 2026 kevät, Tunkeutumistestaus

h4 Täysin Laillinen Sertifikaatti

Käytettävän ympäristön ominaisuudet

• Host

  • Host PC: HP Laptop 15s-eq3xxx

  • OS: Ubuntu 24.04.4 LTS

  • Processor: AMD Ryzen™ 7 5825U with Radeon™ Graphics × 16

  • Memory: 16.0 GiB

  • NIC: Realtek Semiconductor Co., 802.11 ax Wireless

  • Architecture: x86_64

  • Firmware version: F.20

  • Kernel Version: Linux 6.17.0-20-generic

• Virtual Machine

  • OS: Kali GNU/Linux Rolling

  • Release: 2026.1

  • Kernel Version: Linux 6.18.12+kali-amd64

  • Architecture: x86-64

  • Hardware Vendor: QEMU

  • Hardware Model: Ubuntu 24.04 PC Q35 + ICH9, 2009

  • Hardware Version: pc-q35-noble

  • Firmware Version: 1.16.3-debian-1.16.3-2

  • Firmware Date: Tue 2014-04-01

• Metasploitable2

  • OS: Ubuntu 8.04

  • Hypervisor: KVM/QEMU

  • CPUs: 2

  • Memory: 2048MiB

  • Storage: 8 GiB

x) Lue/katso ja tiivistä. (Tässä x-alakohdassa ei tarvitse tehdä testejä tietokoneella, vain lukeminen tai kuunteleminen ja tiivistelmä riittää. Tiivistämiseen riittää muutama ranskalainen viiva kustakin artikkelista - ei pitkiä esseitä. Kannattaa lisätä myös jokin oma ajatus, idea, huomio tai kysymys.)

OWASP 2021: OWASP Top 10:2021 A01:2021 – Broken Access Control (IDOR ja path traversal ovat osa tätä)

• Pääsynhallinta (Access control) asettaa rajat käyttäjän sallitulle toiminnalle
  • Pääsynhallinnan haavoittuvuudet mahdollistaa yleensä tiedon
    1. paljastamisen
    2. muuttamisen
    3. tuhoamisen
    4. Liiketoiminnallisen toiminnon suorittamisen
• Pääsynhallinnan haavoittuvuuksien ehkäiseminen
  • Palvelimen ja server-less APIn koodilla
  • Pääsynhallinnan testaaminen

PortSwigger Academy: Insecure direct object references (IDOR)

• IDOR on pääsynhallinnan haavoittuvuus
  • Toteutuu sovelluksen salliessa objekteihin pääsyn käyttäjän syötteellä
  • Useimmiten horisontaalista liikettä haavoittuvuutta hyödyntäen
    • Voi olla vertikaalistakin

PortSwigger Academy: Path traversal

• Path traversal (tai directory traversal) haavoittuvuus mahdollistaa hyökkääjän liikkua hakemistopuussa
  • Liikkumisen lisäksi voi pystyä pahimmassa tapauksessa muokkaamaan dataa kohteessa
• Haavoittuvuuden ehkäisy
  • Paras suojaus on estää käyttäjän syöte tiedostojärjestelmän APIin kokonaan
  • Jos ei ole mahdollista
    • Syötteen validoiminen
      1. Whitelist sallituista arvoista
      2. Whitelist sallituista merkeistä
    • Käyttäjän syötteen lisääminen sallittuun hakemistopolkuun hyödyntäen tiedostojärjestelmän APIa ja parametrejä

PortSwigger Academy: Cross-site scripting

• Cross-site scripting (XSS) on asiakaspuolen (client side) haavoittuvuus
  • Hyökkääjä pystyy skriptien kautta manipuloimaan toisten käyttäjien toimia
• XSS hyökkäykset
  • Reflected XSS
    • Asiakas tekee http-pyynnön hyökkääjän saastuttamaa URLia hyödyntäen
  • Stored XSS
    • Hyökkääjä syöttää sovellukseen validoimatonta ja haitallista dataa joka sisältyy muiden käyttäjien vastauksiin sovelluksesta
  • DOM-based XSS
    • Hyökkääjä laatii skriptin joka hyödyntää JavaScriptin objekteja asiakkaan kommunikoidessa sovelluksen kanssa
• XSS hyökkäysten ehkäisy
  • Automaattinen haavoittuvuuksien skannaaminen sovelluksesta
  • Manuaalinen testaaminen syötteiden avulla
  • Whitelist menetelmän hyödyntäminen syötteille
  • Ulos lähtevän datan koodaaminen toiseen muotoon (output encoding)
  • Sopivien http-vastausten otsakkeiden käyttäminen

a) Totally Legit Sertificate. Asenna OWASP ZAP, generoi CA-sertifikaatti ja asenna se selaimeesi. Laita ZAP proxyksi selaimeesi. Laita ZAP sieppaamaan myös kuvat, niitä tarvitaan tämän kerran kotitehtävissä. Osoita, että hakupyynnöt ilmestyvät ZAP:n käyttöliittymään. (Voi vaatia Firefox about:config network.proxy.allow_hijacking_localhost. Foxyproxy laittoi tämän aiemmin päälle itse. Kalin Firefox ESR oli viimeksi ongelmia Foxyproxyn kanssa - vaihtoehtona on asettaa Proxy käsin Settings, hakusana “proxy”)

17.4.2026 21:38

Aloitin asentamalla zaproxyn, jota tehtävänannon vinkeissä suositeltiin kalille komennoilla

$ sudo apt-get update #Päivittää paikallisen pakettilistan
$ sudo apt-get install zaproxy #Lataa ja asentaa zaproxy ohjelman

Avasin zaproxyn, josta löysin sertifikaatin kohdasta “Server Certificates”.

Kuva 1. Ohjelma oli generoinut sertifikaatin valmiiksi

Painoin “save” ja tallensin sertifikaatin kotihakemistooni. Menin lisäämään firefoxiin tallentamani sertifikaatin. Firefox kysyi lisäysprosessin yhteydessä haluanko luottaa sertifikaattiin web-sivujen ja sähköpostien käyttäjien identifioimisessa? Laitoin web-sivujen tunnistuksen päälle.

Kuva 2. Ikkuna tuli esiin sertifikaatin valitsemisen jälkeen

Laitoin metasploitablen päälle, koska testaan sen web-sivujen avulla proxyä. Lisäsin lisäksi firefoxin proxy asetuksiin osoitteen 127.0.0.1:8080, jotta selain ohjaisi liikenteen zapiin.

Kuva 3. Ohjasin kaiken http-liikenteen localhost porttiin 8080

Menin tämän jälkeen metasploitablen weppisivuille, mutta zap ei pysäyttänyt pyyntöä. Firefoxin proxy asetuksissa luki, että localhost-osoitteisiin ei ohjattaisi liikennettä ollenkaan. Tehtävän vinkeissä opettaja antoi neuvon muuttaa rivin “network.proxy.allow_hijacking_localhost” asetuksia firefoxissa tai vaihtoehtoisesti käyttää foxyproxyä. Käytän foxyproxyä seuraavassa tehtävässä, joten en tee sillä nyt. Kävin muuttamassa “network.proxy.allow_hijacking_localhost” arvoon true urlissa about:config.

Kuva 4. Valinta oli oletuksena false

Ihmettelin ensiksi, miksi kaikki pyynnöt meni vieläkin läpi ilman selaimen roikkumista. Huomasin zapin yläosassa olevan vihreä pallo, jonka voi painaa punaiseksi, jolloin pyynnöt ja vastaukset pitää erikseen välittää eteenpäin zapista.

Kuva 5. Kuvassa näkyy pyyntöjä, vastauksia ja kuva siepattuna

b) Kettumaista. Asenna “FoxyProxy Standard” Firefox Addon, ja lisää ZAP proxyksi siihen. Käytä FoxyProxyn “Patterns” -toimintoa, niin että vain valitsemasi weppisivut ohjataan Proxyyn. (Läksyssä ohjataan varmaankin PortSwigger Labs ja localhost.)

18.4.2026 8:35

Otin firefoxin asetuksista proxyn pois päältä, jotta pääsin lataamaan ja asentamaan foxyproxyn Mozillan laajennuksien alustalta. Seuraavaksi kävin laittamassa zapin proxyksi foxyproxyn asetuksista.

Kuva 6. Asetukset foxyproxissa

Laitoin samalla tehtävänannon mukaisen rivin kohtaan “Proxy by Patterns”, jolla pystyin suodattamaan proxyyn ohjatun liikenteen ip-osoitteen perusteella. Toiminnon ollessa päällä vain metasploitablen osoitteeseen 192.168.100.251 lähtevät pyynnöt ja vastaukset lähetetään proxyn kautta. Asteriskit ovat “wildcard” merkkejä, jotka ilmaisevat suodatuksen tarttumisen vaikka tähden kohdalla olisi mitä tahansa merkkejä.
(FoxyProxy. URL: URL Patterns)

Kuva 7. Selainlisäosan valikosta saa säädettyä toimintoja helposti

Kuten ylläolevasta kuvasta ilmenee, valinta “Proxy by Patterns” laittaa päälle vain metasploitablen liikenteen sieppauksen proxyyn ja “zap” puolestaan kaiken liikenteen.

PortSwigger Labs. Ratkaise tehtävät. Selitä ratkaisusi: mitä palvelimella tapahtuu, mitä eri osat tekevät, miten hyökkäys löytyi, mistä vika johtuu. Kannattaa käyttää ZAPia, vaikka malliratkaisut käyttävät harjoitusten tekijän maksullista ohjelmaa. Monet tehtävät voi ratkaista myös pelkällä selaimella. Malliratkaisun kopioiminen ZAP:n tai selaimeen ei ole vastaus tehtävään, vaan ratkaisu ja haavoittuvuuden etsiminen on selitettävä ja perusteltava.

Cross Site Scripting (XSS)

c) Reflected XSS into HTML context with nothing encoded

19.4.2026 10:37

Lähdin tekemään ensimmäistä tehtävää ja siellä oli blogisivusto vastassa, jonka urlin laitoin foxyproxyn kohtaan “Proxy by Patterns”.

Kuva 8. Osoite wildcard merkkien kanssa

Osoite oli “web-security-academy.net” jonka laitoin wildcard-merkkien kanssa jälleen kerran. Syötin tämän jälkeen blogisivustolle hakusanan “a”. Katsoin samalla ohjetta zapin käytöstä.
(Arkenstone Learning. Youtube. URL: OWASP ZAP Step-by-Step Tutorial)

Kuva 9. Sivu haun tekemisen jälkeen

Menin katsomaan zapiin ja avasin manual request editorin get-pyynnöstä, jolla hain sivustolta hakusanalla “a”.

Kuva 10. Osa muuttamattomasta get-pyynnöstä

Tämän jälkeen palautin mieleeni artikkelin josta tein tiivistelmän Cross-site scripting.

Laitoin hakusanan “a” tilalle pyyntöön tekstin “haloo” alert-funktioon script-tagien sisälle, koska muuta syötettä sivulle en antanut.

Kuva 11. Uusi pyyntö

Lähetin uuden pyynnön, jonka jälkeen avasin vastauksen zapista firefoxilla.

Kuva 12. Selain avattuna zapista

Tekstille tuli kirjoittamani viesti. Painoin “ok”, jonka jälkeen sain vahvistuksen tehtävän onnistuneesta suorittamisesta.

Kuva 13. Tehtävä oli suoritettu

Tehtävässä oli reflected-xss haavoittuvuus, koska käyttäjän syöte hyväksyttiin backendissä ilman whitelisting menetelmää. Lisäksi kaikki käyttäjän syöttämät syötteet palautettiin käyttäjän selaimelle, jolloin script oli mahdollista ajaa selaimessa. Uloslähtevää dataa asiakkaalle ei ollut myös muutettu toiseen muotoon.

d) Stored XSS into HTML context with nothing encoded

19.4.2026 11:12

Tehtävän tehtävänannossa mainittiin, että haavoittuvuus on kommenttiosiossa ja suorittaakseen labin on tehtävä kommentti joka suorittaa alert-funktion blogi julkaisua katsottaessa.

Painoin “view post” ensimmäisestä blogi julkaisusta. Julkaisun lopussa oli kommentti osio.

Kuva 14. Kommentti osio sivun lopussa

Syötin kommenttikenttään ja nimeksi “moi” sekä sähköpostiosoitteeksi moi@moi.com. Tämän jälkeen kommenttini ilmestyi sivustolle. Menin katsomaan lisää zapista.

Avasin requesterissa post-pyynnön, jonka lähetin palvelimelle lisätessäni kommentin.

Kuva 15. Post pyynto ja parametrit

Muutin seuraavaksi kommentin parametrin alert-funktioksi tekstillä “haloo” ja lisäsin vielä script-tagit, jolloin skripti tallennetaan palvelimelle kommenttina. Kun joku lataa ja avaa blogi julkaisun selaimessaan, selain ajaa samalla skriptin.

Kuva 16. Parametrit muutettuna ja valmiina lähettämiseen

Lähetin post-pyynnön uudestaan muokatuilla parametreillä ja avasin vastauksen firefoxissa. Tällä kertaa tuli not found ilmoitus.

Kuva 17. Http-pyynnön vastaus avattuna selaimessa

Menin ensimmäiseen selausistuntoon, jonka latasin uudelleen ilman välimuistia shift+reload näppäimillä. Sieltä tuli ilmoitusta.

Kuva 18. Skriptin ilmoitus sivun päivittämisen jälkeen

Lisäksi tuli vielä onnistuneen labin ilmoitus.

Kuva 19. Ilmoitus onnistuneesta suorituksesta alertin jälkeen

Olikin loogista, että post-pyyntöön ei tullut vastausta selaimessa, koska sehän oli vain pyyntö tallentaa palvelimelle kommentti. Uusissa get-pyynnöissä script suoritetaankin. Backend-logiikassa ei ollut siis taaskaan whitelisting käytäntöä hyödynnetty syötteen validoinnissa. Lisäksi uloslähtevää dataa asiakkaalle ei ollut muutettu toiseen muotoon.

e) Selitä esimerkin avulla, mitä hyökkääjä hyötyy XSS-hyökkäyksestä. Alert(“Hei Tero!”) ei vielä tarjoa kummoista pääsyä. (Tässä alakohdassa ei tarvitse tehdä testejä tietokoneella, pelkkä lyhyt ja selkeä selitys riittää.)

Hyökkääjä hyötyy xss-hyökkäyksestä laittaessaan skriptin toteuttamaan jonkin toiminnon toisen käyttäjän puolesta. Esimerkkinä voisi mainita vaikkapa pankkipalvelujen sivuston, jonka osoitteesta hyökkääjä on laatinut haitallista koodia sisältävän linkin tai hyökkääjä on onnistunut saastuttamaan palvelimen päässä olevan koodin. Kun asiakas avaa sivuston omalla client-sovelluksellaan, haitallinen koodi suoritetaan samalla. Käyttäjän ollessa kirjautuneena haitallinen koodi voi suorittaa asiakkaana tilisiirtoja tai mitä vain muitakin toimintoja, joita haitallinen koodi määrittää suoritettavan.

Path traversal

f) File path traversal, simple case. Laita tarvittaessa Zapissa kuvien sieppaus päälle.

19.4.2026 13:00

Tehtäväsivulla oli nettikauppa.

Kuva 20. Osa tehtävän etusivusta

Katsoin muistin virkistämiseksi sivua aiheesta Path traversal. Klikkasin “view details” painiketta “Packaway Carport” tuotteen alta. Menin katsomaan zapista get-vastausta, jossa oli kuva tuotteesta ja arviointitähdistä html-koodissa.

Kuva 21. Vastauksessa alleviivattuna punaisella kuvatiedostot

Ajattelin tässä vaiheessa, että miten lähettäisin get-pyynnön palvelimelle, jotta saisin kuvan src-attribuuttiin laitettua hakemistopolkua muuttavan arvon. Kuvat tulivat vastauksessa vasta, joten ajattelin lisätä img-elementin jo get-pyyntöön parametrina.

Minulla tuli timeout ilmoitus portswiggeristä, joten minun piti käynnistää uudelleen harjoitussivusto. Lisäsin parametrin pyyntöön.

Kuva 22. Lisätty parametri

Lähetin pyynnön, mutta sain vastauksena selaimessa vain samanlaisen sivuston kuin aiemmin.

Kuva 23. Osa sivusta, joka oli samanlainen kuin aiemmin

Kuvasta näkyy myös tehtävän olevan ratkaisematta, koska siinä ei ole punaista nauhaa tekstillä. Ajattelin muutenkin parametrin olevan aika toimimaton yritys, koska mitään parametrejä ei ollut valmiina pyynnössä, joita olisi voinut muokata. Voihan sitä kaikkea toki kokeilla harjoitellessa.

Onnistuin kuitenkin ratkaisemaan tehtävän asettamalla get-pyyntöön parametrin “productId=1” tilalle “filename=../../../etc/passwd”.

Kuva 24. Alkuperäinen ja muuttamaton url get-pyynnössä

Kuva 25. Muutettu osa get-pyyntöä

Sitten sainkin jo onnistumisesta ilmoituksen selaimessani.

Kuva 26. Ilmoitus onnistuneesta suorituksesta

Ymmärsin haavoittuvuuden olevan samanlainen kuin linkkaamassani sivussa “Path traversal”. Kuvat haettiin todennäköisesti hakemistopolusta “/var/www/images/”, jolloin sain hypittyä hakemistopuussa juurihakemistoon ja sieltä navigoitua passwd tiedostoon. Sivustolla ei ollut taaskaan whitelisting menetelmää hyödynnetty syötteen validoinnissa ja yhdenmukaistettua base directoryä ei oltu asetettu valittavan pyyntöihin.

g) File path traversal, traversal sequences blocked with absolute path bypass

19.4.2026 15:23

Tehtävänannossa mainittiin, että palvelimella hyödynnetään whitelisting menetelmää syötteen validoinnissa, mutta tiedostonimiä käsitellään relatiivisesti oletus hakemistossa. Minun piti taas saada tiedosto passwd haettua.

Jälleen kerran oli nettikauppa kyseessä. Klikkasin ensimmäisen tuotteen auki selaimessa. Sitten menin zapiin katsomaan.

Kuva 27. Kuva vastauksen html-koodissa

Sain ratkaistua labin.

Kuva 28. Muutettu osa get-pyyntöä

Kuva 29. Ilmoitus onnistuneesta suorittamisesta

Tietääkseni tehtävässä oli juurihakemisto oletuspolkuna, koska sain suoraan haettua tiedoston absoluuttisella hakemistopolulla. Ilmeisesti kuvatkin olivat juurihakemistossa, koska niiden hakeminen html-koodissa oli muodossa /image?filename=7.jpg. Haavoittuvuus oli läsnä, koska palvelimen oletushakemisto oli juurihakemisto. Base directory saattoi olla asetettuna palvelimelle, mutta se ei auta mitään jos base directory on juurihakemisto.

h) File path traversal, traversal sequences stripped non-recursively

19.4.2026 16:26

Tehtävässä oli taas haettava tiedosto passwd. Tehtävänannossa todettiin myös polkujen muuttamisen merkit (kaksi pistettä) olevan suodatettu karsimalla (stripped) ei-rekursiivisesti. Ajattelin tämän tarkoittavan varmaankin sivuston suodattamisen lopettamista vain ensimmäisten polkujen muuttamisten merkkien jälkeen, joten voisin ensin laittaa blokattavat merkit ja sitten varsinaiset luettavat merkit.

Kuva 30. Alkuperäinen koodi sivuston kuvassa

Kokeilin pyyntöä muodossa [protokolla ja urlin alku]web-security-academy.net/image?filename=…./…./…./etc/passwd, mutta sain vastauksena vain bad request 400. Sain ratkaistua kuitenkin tehtävän hieman muuttamalla pyyntöä.

Kuva 31. Muutettu osa pyyntöä

Kuva 32. Ilmoitus onnistumisesta selaimessa

Ensimmäinen pyyntö epäonnistui, koska backend koodi karsi pyynnöstä selkeästi kaksi pistettä ja ensimmäisen kenoviivan, jolloin pyyntöön ei jäänyt enää kenoviivoja määrittämään hakemistopolkua. Haavoittuvuus olisi korjattavissa varmasti helpoiten sisällyttämällä base directory ennen annettua syötettä palvelimen päässä.

Insecure Direct Object Reference (IDOR)

i) Insecure direct object references

19.4.2026 18:13

Tehtävässä piti saada käyttäjän “carlos” salasana ja kirjautua hänen tililleen. Sivustossa tallennettiin chat lokit suoraan tiedostojärjestelmään sekä ne palautetaan staattisella urlilla.

Kuva 33. Tehtävän etusivu

Klikkailin linkkejä sivuilla ja katsoin niitä zapissa lisää. En ollut varma miten lähtisi tehtävää ratkaisemaan, mutta ajattelin get-pyynnön urlin muokkaamisen voivan olla tässäkin ratkaisu. Kokeilin ensimmäiseksi lisätä chatin urliin carlos.

Kuva 34. Ensimmäinen yritys url muutettuna

Ei onnistunut vaan sain vastaukseksi 404 not found. Tämän jälkeen tutkittuani liikennettä päädyin pohtimaan, että todennäköisesti ladattaessa käyttäjän chat tiedosto painikkeesta “view transcript” ja sen vastauksena lähetettävä get-pyyntö olisi avainasemassa. Tehtävänannossahan sanottiin, että chat lokitiedostot palautetaan suoraan staattisesti. Post-pyynnöllä laitettiin selvästi keskustelu tiedostojärjestelmään.

Kuva 35. Post-pyyntö lokin lataamisprosessissa

Jota seurasi get-pyyntö.

Kuva 36. Get-pyyntö post-pyynnön jälkeen

En vain tiennyt yhtään, mikä voisi olla halutun tiedoston nimi, koska en päässyt tekemään käyttäjää sivuilla. Jos saisin käyttäjätilin luotua sivustolle pääsisin näkemään polun, josta käyttäjän tiedosto haetaan.

Latasin monta kertaa chat historiani sivuilta ja jokainen uusi tiedosto lisäsi yhden numeron tiedostonimeen. Ensimmäinen ladattu tiedosto oli nimeltään “2.txt”, joten tajusin carloksen lokitiedoston olevan erittäin todennäköisesti “1.txt”. Tämä toimikin.

Kuva 37. Muokattu get-pyyntö palvelimelle

Avasin selaimessa paluuviestinä tulleen urlin, joka selaimen avaamisen jälkeen latasi lokitiedoston automaattisesti koneelleni. Avasin tiedoston ja salasana löytyikin sieltä.

Kuva 38. Salasana carloksen lokitiedostossa

Menin kirjautumaan tehtäväsivuille carloksen tunnuksilla, jonka jälkeen homma oli paketissa.

Kuva 39. Tehtävän onnistumisen ilmoitus

IDOR haavoittuvuus voitaisiin ehkäistä käyttämällä kompleksisia tunnistetietoja. Tämä ei yksinään riitä, koska on olemassa silti mahdollisuus, että joku pääsee hänelle kuulumattomiin resursseihin käsiksi. Pääsynhallinta on välttämätön osa IDOR hyökkäysten estämistä. Pitäisi myös pyrkiä välttämään tunnistetietojen käyttöä urlissa ja post-pyynnöissä.
(OWASP Cheat Sheet Series Team. URL: Insecure Direct Object Reference Prevention Cheat Sheet)

Tehtävän palvelimella ei ollut siis kompleksisia tunnistetietoja, koska lokitiedostot tallennettiin nousevassa järjestyksessä. Pääsynhallintaakaan ei ollut implementoitu, koska kuka vaan sai ladattua lokitiedoston.

j) Vapaaehtoinen, helppo: Asenna pencode ja muunna sillä jokin merkkijono (encode a string).

En tehnyt kyseistä tehtävää.

k) Vapaaehtoinen: Mitmproxy. Asenna MitmProxy. Esittele sitä terminaalissa (TUI). Ota TLS-purku käyttöön. Poimi historiasta hakupyyntö, muokkaa sitä ja lähetä uudelleen.

En tehnyt kyseistä tehtävää.

l) Vapaaehtoinen: Ratkaise lisää PortSwigger Labs -tehtäviä. Kannattaa tehdä helpoimmat “Apprentice” -tason tehtävät ensin.

En tehnyt kyseistä tehtävää.

Lähteet

Arkenstone Learning. 5.8.2021. OWASP ZAP Step-by-Step Tutorial. Youtube. Katsottavissa: OWASP ZAP Step-by-Step Tutorial. Katsottu: 19.4.2026.

FoxyProxy. URL Patterns. Luettavissa: URL Patterns. Luettu: 18.4.2026.

OWASP Cheat Sheet Series Team. Insecure Direct Object Reference Prevention Cheat Sheet. Luettavissa: Insecure Direct Object Reference Prevention Cheat Sheet. Luettu: 19.4.2026.

OWASP Top 10 Team. A01:2021 – Broken Access Control. Luettavissa: A01:2021 – Broken Access Control. Luettu: 17.4.2026.

PortSwigger Academy. Cross-site scripting. Luettavissa: Cross-site scripting. Luettu: 17.4.2026.

PortSwigger Academy. Insecure direct object references (IDOR). Luettavissa: Insecure direct object references (IDOR). Luettu: 17.4.2026.

PortSwigger Academy. Path traversal. Luettavissa: Path traversal. Luettu: 17.4.2026.

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html