Penetracijsko testiranje web aplikacija: vodič za naručitelje

Web aplikacija je za većinu tvrtki najizloženija meta jer je dostupna svima s interneta, danonoćno, iz cijelog svijeta. Penetracijsko testiranje web aplikacije je kontrolirani napad na tu aplikaciju koji izvode iskusni testeri, a oni pokušavaju probiti autentifikaciju, zlouporabiti logiku, ukrasti podatke i proširiti ovlasti jednako kao stvarni napadač. Cilj nije popis teoretskih problema, nego dokaz što napadač stvarno može učiniti vašoj aplikaciji, vašim korisnicima i vašim podacima, uz jasne upute kako to popraviti.

Ovaj vodič je za tehničke voditelje i poslovne ljude koji ovaj posao naručuju i moraju ga opravdati. Objašnjava što test jest, po čemu se razlikuje od skeniranja, kako teče korak po korak, što biste trebali dobiti, što određuje cijenu, koliko često testirati i kako se sve povezuje s obvezama koje već nosite po NIS2, DORA-i, ISO 27001 i GDPR-u. Vezano za obranu i sigurnu izgradnju, pogledajte i sigurnost web aplikacija.

Što je penetracijsko testiranje web aplikacije

Penetracijski test web aplikacije je vremenski omeđena, ciljana procjena u kojoj testeri pokušavaju kompromitirati konkretnu aplikaciju. Rade iz dogovorenog opsega, najčešće skupa domena, korisničkih uloga i API krajnjih točaka, i slijede stvarne puteve napada dok ne uspiju ili ne iscrpe razumne mogućnosti. Rezultat je skup potvrđenih nalaza, svaki s putem za reprodukciju, izjavom o učinku i konkretnim ispravkom.

Test je u srži ručni jer najopasnije ranjivosti web aplikacija žive u poslovnoj logici i kontroli pristupa, a njih ne može pronaći alat koji ne razumije što vaša aplikacija treba raditi. Automatski alati pomažu u širini i u otkrivanju poznatih obrazaca, ali odluku o tome je li nešto stvarno iskoristivo i koliko šteti donosi tester.

Penetracijski test nije skeniranje

Najčešća zabluda na tržištu je da su skeniranje ranjivosti i penetracijski test ista stvar. Skener uspoređuje odgovore vaše aplikacije s bazom poznatih potpisa. Penetracijski test rezonira o vašoj aplikaciji. Skener će reći da je neka biblioteka zastarjela. Tester će pokazati da junior korisnik promjenom jednog parametra u zahtjevu čita račune svih drugih klijenata, što nijedan skener ne prijavljuje jer je aplikacija svaki put vratila uredan odgovor. Razliku detaljnije razlažemo u tekstu procjena ranjivosti vs penetracijski test.

Klase ranjivosti koje tražimo

Web ima stabilan skup načina na koje puca, a OWASP Top 10 je javna referenca koju većina timova poznaje.¹ Koristimo je kao osnovu, a ne kao popis za odštrikavanje, jer najopasniji nalazi na stvarnim aplikacijama rijetko su udžbenički primjeri. Kategorije ispod opisuju gdje provodimo najviše vremena i zašto svaka pogađa reguliranu tvrtku.

• Slaba kontrola pristupa, gdje korisnik dohvaća podatke ili funkcije izvan svoje uloge, najčešći je ozbiljan nalaz i izravno se veže na obvezu prijave povrede podataka.
• Injekcija, uključujući SQL, naredbe i predloške, i dalje se pojavljuje u modernim okruženjima jer novi okviri uvode nove točke ranjivosti brže nego što ih timovi nauče braniti.
• Slabosti autentifikacije i sesija, poput predvidljivih tokena, izostanka ograničenja na prijavu i slomljenog postupka za promjenu lozinke, omogućuju preuzimanje računa bez ijedne ranjivosti u kodu.
• Zlouporaba poslovne logike, gdje aplikacija radi točno kako je izgrađena ali tijek dopušta prijevaru, poput ponavljanja popusta, preskakanja koraka plaćanja ili odobravanja vlastitog zahtjeva, nevidljiva je alatima i traži testera koji razumije vašu domenu.
• Krivotvorenje zahtjeva na strani poslužitelja (SSRF) i nesigurna deserijalizacija otvaraju napadaču put iz javne aplikacije u unutarnje sustave i cloud metapodatke, pretvarajući jednu grešku u potpuni proboj.
• Izlaganje osjetljivih podataka kroz opširne poruke o greškama, nezaštićene sigurnosne kopije i preširoke API odgovore otkriva upravo ono do čega je regulatorima i napadačima najviše stalo.

Kad je aplikacija vođena API-jem, a većina modernih proizvoda jest, testiramo i prema OWASP API Security Top 10. API-ji pucaju na svoj poseban način, o čemu pišemo u tekstu sigurnost API-ja.

Kako test teče, korak po korak

Dobar test slijedi discipliniran postupak, a jasnu metodologiju trebate očekivati prije nego itko dotakne vašu aplikaciju. Ovako vodimo test web aplikacije od početka do ponovnog testa. Oblik je dosljedan i kad dubina varira prema opsegu.

1. 01
   Opseg i pravila angažmana

   Dogovaramo ciljane URL-ove, korisničke uloge koje se testiraju, što je izvan granica, razdoblje testiranja i hitni kontakt koji može zaustaviti test ako se produkcija ponaša loše.
2. 02
   Izviđanje i mapiranje

   Popisujemo površinu aplikacije, svaku stranicu, parametar, krajnju točku i stanje prijave, da ništa u opsegu ne ostane neispitano.
3. 03
   Testiranje kroz uloge

   Prijavljujemo se kao svaka razina ovlasti koju date i pokušavamo prijeći granice među njima, jer se najozbiljniji nalazi pojavljuju tek kad je tester unutra.
4. 04
   Iskorištavanje i povezivanje

   Svaku ranjivost potvrđujemo iskorištavanjem, a zatim spajamo manje propuste u jedan put napada visokog učinka, jer stvarni proboji su gotovo uvijek lanci, a ne pojedinačne greške.
5. 05
   Analiza učinka i dokazi

   Dokumentiramo što točno svaki nalaz izlaže, sa snimkama zaslona te parovima zahtjeva i odgovora koje vaši inženjeri mogu ponoviti.
6. 06
   Izvještaj i živo predstavljanje

   Provodimo tehničke i poslovne dionike kroz nalaze, rizik i redoslijed ispravaka po prioritetu.
7. 07
   Podrška za ispravak i ponovni test

   Provjeravamo da vaši ispravci stvarno zatvaraju problem, a ne da ga premještaju, i izdajemo izvještaj s evidentiranim statusom rješenja.

Tehnike iskorištavanja povezujemo s okvirom MITRE ATT&CK gdje to vašim braniteljima pomaže povezati nalaz s detekcijom koju trebaju izgraditi. Taj most između ofenzivnih nalaza i obrambenih kontrola razlika je između testa koji se arhivira i testa koji mijenja vaše stanje sigurnosti.

Black box, grey box i white box

Birat ćete perspektivu testiranja, a izbor mijenja i cijenu i pokrivenost. Pojmovi opisuju koliko testeri znaju na početku. Pogrešan izbor troši budžet na ponovno otkrivanje onoga što ste mogli jednostavno predati.

• Black box ne daje testeru unutarnje znanje i simulira vanjskog napadača bez vjerodajnica, što je realno ali troši vrijeme na otkrivanje koje dodaje malo sigurnosne vrijednosti.
• Grey box daje vjerodajnice za svaku ulogu i osnovnu dokumentaciju, što je ispravna zadana postavka za većinu web aplikacija jer usmjerava vrijeme testera na pronalaženje grešaka u kontroli pristupa i logici.
• White box dodaje izvorni kod, dijagrame arhitekture i pristup razvoju, što daje najdublju pokrivenost i najjači je izbor za aplikacije visokog rizika s novcem ili reguliranim podacima.
• Čisti black box na složenoj aplikaciji s prijavom često promaši najvažnije nalaze jer tester nikad ne uđe do mjesta gdje živi stvarna šteta.

Black box pokazuje što vanjski napadač nađe u tjedan dana. Grey box pokazuje što ustrajan napadač na kraju postigne. Za većinu organizacija drugi odgovor je onaj koji je bitan.

Što biste trebali dobiti

Isporuka je mjesto gdje mnogi testovi tiho podbace. Izvještaj pun ispisa skenera, napuhan informativnim nalazima, nije penetracijski test, nego račun s priloženim PDF-om. Na svaki redak trebate moći djelovati.

• Sažetak za upravu na razumljivom jeziku koji navodi ukupan rizik, najgori realan ishod i je li aplikacija sposobna nositi podatke koje drži.
• Popis nalaza rangiran po stvarnom poslovnom učinku, a ne po sirovom CVSS rezultatu, jer propust u kontroli pristupa nad financijskim podacima nadmašuje visoko ocijenjen problem na stranici do koje nitko ne dolazi.
• Potpune korake za reprodukciju svakog nalaza, uključujući točne zahtjeve, da vaši inženjeri mogu potvrditi i popraviti bez dodatnog sastanka.
• Konkretan ispravak za svaki nalaz koji imenuje rješenje, a ne općenit savjet da provjeravate unos.
• Ponovni test ispravaka i ažuriran izvještaj koji pokazuje što je potvrđeno zatvorenim, što je dokaz koji će vaši revizori i klijenti tražiti.
• Jasnu izjavu o tome što je bilo u opsegu, a što nije, da izvještaj bude pošten o vlastitim granicama.

Koliko često testirati i kada

Godišnji test je donja granica koju većina okvira očekuje, ali kalendar je pogrešan način razmišljanja. Web aplikacija se mijenja svakim ciklusom razvoja, a test vrijedi samo za verziju na kojoj je proveden. Ispravan ritam prati vaš tempo izdavanja i vaš rizik.

• Testirajte barem jednom godišnje svaku aplikaciju u opsegu usklađenosti, jer je to minimum koji očekuju revizori, klijenti i osiguravatelji.
• Testirajte prije svakog većeg izdanja koje mijenja autentifikaciju, tijek plaćanja ili podatkovni model, jer su to promjene koje najčešće uvode ozbiljan propust.
• Testirajte nakon značajne promjene arhitekture, poput prelaska na novog pružatelja identiteta, jer nove granice stvaraju nove rupe.
• Testirajte kontinuirano kroz model usluge ako izdajete tjedno, da pokrivenost prati vaš kod umjesto da zastari mjesec dana nakon jednokratnog izvještaja.
• Ponovno testirajte nakon svakog ispravka, jer nepotvrđen ispravak je nada, a ne kontrola.

Test web aplikacije dio je šireg programa, a za aplikacije u stalnom razvoju uklapa se u sigurni razvoj i smislen ritam izdavanja.

Što određuje cijenu

Penetracijski test web aplikacije naplaćuje se po danima testera, a broj dana određuju opseg i dubina, ne veličina vaše tvrtke. Mala stranica je nekoliko dana. Velika platforma s prijavom, mnogo uloga, dubokim API-jem i plaćanjima može trajati nekoliko tjedana. Ekonomiju detaljno razlažemo u tekstu cijena penetracijskog testiranja, ali glavne varijable su broj korisničkih uloga, veličina API površine, složenost poslovne logike i odabrana perspektiva testiranja. Najjeftinija ponuda gotovo je uvijek skeniranje prerušeno u test.

Kako se veže s propisima

Test web aplikacije jedan je od najizravnijih dokaza koje možete staviti pred revizora ili regulatora. Pokazuje da kontrole koje štite regulirane podatke testirate, a ne samo dokumentirate. Glavni okviri svi očekuju ovaj posao, iako ga drukčije opisuju.

• ISO/IEC 27001:2022 očekuje upravljanje tehničkim ranjivostima i siguran razvoj u sklopu 93 kontrole Dodatka A, a test web aplikacije daje konkretan dokaz za oboje.
• NIS2, u Hrvatskoj prenesen kroz Zakon o kibernetičkoj sigurnosti, podiže ljestvicu upravljanja tehničkim rizikom za ključne i važne subjekte, a redovito testiranje aplikacija jasan je način da pokažete da tu obvezu ispunjavate.³
• DORA, Uredba (EU) 2022/2554 na snazi od siječnja 2025., traži od financijskih subjekata redovito testiranje otpornosti, gdje je testiranje web aplikacija temeljna komponenta, a detalje razlažemo za financijske institucije.
• GDPR traži primjerene tehničke mjere zaštite osobnih podataka, a dokazano testirana kontrola pristupa izravno smanjuje rizik povrede i obvezu prijave.

Test koji se uredno preslikava na vaš okvir štedi vam trud kasnijeg prevođenja nalaza u dokaze za reviziju. Tu vezu ugrađujemo u izvještaj kroz rad na upravljanju, riziku i usklađenosti, pa isti angažman služi i sigurnosnom timu i revizorima.

Kako Raptoric pomaže

Penetracijski test web aplikacije najjasniji je način da saznate što napadač stvarno može učiniti aplikaciji koja nosi vaše najosjetljivije podatke, a daje dokaze koji izdrže pred revizorima, klijentima i regulatorima. Testiramo ručno i po priznatoj metodologiji te isporučujemo izvještaj s dokazom učinka, ponovljivim nalazima i ponovnim testom, kroz penetracijsko testiranje web aplikacija. Recite nam pošteno što vaša aplikacija treba, dogovorite uvodni razgovor i reći ćemo vam i kad joj treba manje nego što ste očekivali.