No prvo se idemo podsjetiti - što je to OWASP?
OWASP ili Open Worldwide Application Security Project je međunarodna neprofitna organizacija koja osvještava o sigurnosti na internetu i radi na poboljšanju sigurnosti u softveru. Između ostalog, prikuplja informacije o ranjivosti web aplikacija i nudi mnoštvo projekata na kojima možete brusiti svoje vještine hakiranja, kao i niz dokumenata koji objašnjavaju kako zaštititi svoje aplikacije i sustave te osigurati siguran razvoj web aplikacija. Njihov najpoznatiji dokument je OWASP Top 10 koji govori o deset najčešćih ranjivosti web aplikacija i načinima na koje se mogu ublažiti - nisu napredne niti rijetke, samo su najčešće.
U prethodnim izdanjima VIDI-ja smo prezentirali OWASP TOP 10 iz 2021. godine, a sada ćemo se osvrnuti na all-time favorite i nove izazivače.
OWASP Top 10 za 2025. godinu donosi nekoliko novosti, ali i potvrđuje staro pravilo – većina sigurnosnih problema u web aplikacijama zapravo se ne mijenja tako brzo kako bismo možda očekivali. Neke ranjivosti su promijenile pozicije, pojavila su se i dva nova izazivača, no dobar dio liste ostao je vrlo sličan prethodnom izdanju. Zato ovaj put nećemo prolaziti svih deset kategorija detaljno, nego ćemo se fokusirati na dvije koje smatramo posebno zanimljivima: jednog „starog favorita“ koji uporno ostaje na vrhu liste i jednu noviju prijetnju koja sve više dobiva na važnosti.
New kids on the block
Novi dečki koji su uspjeli doći u Top 10 su Software Supply Chain Failure i Mishandling of Exceptional Conditions – a preraspodjelu starih i novih možete proučiti na slici 1.
Slika 1. Software Supply Chain Failure i Mishandling of Exceptional Conditons su nove kategorije 2025. godine. Loša kontrola pristupa ostaje na prvom mjestu kao i prethodnih godina. All-time favorit Injection (uključujući najpoznatiji SQL Injection) ostao je u Top 10, ali je pao s 3. na 5. mjesto, dok se tehnički napredni napad Server-Side Request Forgery apsorbirao u lošu kontrolu pristupa. Izvor: https://owasp.org/Top10/2025/0x00_2025-Introduction/
All-time favoriti - A01:2025 Loša kontrola pristupa
Što je kontrola pristupa? Da pojednostavimo – kada odete na posao, ostavljate li vrate i prozore širom otvorene? Ostavljate li otvorene prozore u autu preko noći? Naravno da ne, a zašto onda ne biste zaštitili i svoje URL-ove? Spriječili da netko mijenjajući slova i brojke dođe do podataka do kojih ne bi smio, kako bi uništio/promijenio podatke koje ne smije? Upravo to je srž kontrole pristupa, ništa kompleksno, ništa tajno - jednostavno igranje s URL-om.
Kako spriječiti?
Uvijek koristiti validaciju na poslužitelju i ograničeni broj upita koji može otići prema web poslužitelju koji isporučuje podatke i testirati autorizaciju. Kako testirati? Jednostavno, promotrite primjer niže koji smo preuzeli s OWASP službenih stranica.
Testirati možemo na način da pošaljemo zahtjev na adresu (host) www.example.com za resurs /account/viewSetttings. Kao username postavljamo ime korisnika i kolačić, što je u našem slučaju „example_user“ i „USER_SESSION“. Ovo je legitimni upit za korisnika example_user.
POST /account/viewSettings HTTP/1.1Host: www.example.com[other HTTP headers]Cookie: SessionID=USER_SESSION
username=example_user
Legitimni odgovor na taj zahtjev prema poslužitelju su username, email i address.
HTTP1.1 200 OK[other HTTP headers]{ “username”: “example_user”, “email”: “Ova e-mail adresa je zaštićena od spambota. Potrebno je omogućiti JavaScript da je vidite.”, “address”: “Example Address”}
U idućem koraku nastupa test. Ono što bi napadač pokušao jest pod kolačić postaviti svoju sesiju (u ovom slučaju prigodno nazvanu ATTACKER_SESSION) i gledati hoće li pod svojom sesijom dobiti tuđe podatke, a u slučaju da se dohvate tuđi podaci može ih probati uređivati ili brisati. Na taj način i mi sami možemo testirati stranice i vidjeti je li naša aplikacija ispravno postavila kontrolu pristupa.
POST /account/viewCCpincode HTTP/1.1Host: www.example.com[other HTTP headers]Cookie: SessionID=ATTACKER_SESSIONusername=example_user
Challenger - A03:2025 Software Supply Chain Failure
Kako bismo bolje razumjeli što ta ranjivost znači, moramo razumjeti što je Software Supply Chain, a kako bismo razumjeli što je Software Supply Chain moramo razumjeti što je Software Composition Analysis - pa krenimo redom.
Kako svi fizički proizvodi kao što je konzerva juhe od rajčice na slici 2 imaju svoje sastojke, tako i softver ima sastojke od kojih je izrađen. Tvornica juhe od rajčice želi kontrolirati kvalitetu, sigurnost i pouzdanost svojih dobavljača. Zašto? Zato jer žele prodavati kvalitetan proizvod i zarađivati na njemu. Kako bi imali kvalitetan proizvod, moraju imati kvalitetne sastojke. Kako bi imali kvalitetne sastojke, moraju imati dobru kontrolu kvalitete nad svojim dobavljačima. Proizvođači konzerve juhe od rajčice ne žele završiti u novinama kako su otrovali ljude, pa zato ulažu u sigurnost svojih namirnica, proizvodnog procesa i dobavljača. Kako to nije dovoljno, postoje i dodatne kontrole u vidu raznih regulatornih tijela koje provjeravaju tvornicu konzerva juhe od rajčice, a sve zato kako bi proizvodili finu, kvalitetnu i sigurnu juhu od rajčice.
Slika 2. Software Composition Analysis, odnosno sastojci juhe od rajčice. Kako juha od rajčice u konzervi ima popis sastojaka od kojih je načinjena, tako i softver ima sastojke od kojih je načinjen. Neki su sami uzgojeni (izrađeni) kod proizvođača, a neki su kupljeni sa stranog tržišta – rajčice iz polja sunčanih zemalja Južne Amerike ili kvalitetna biblioteka iz bespuća interneta bez aktivnih održavatelja i sumnjivog koda. Izvor: https://healthyheartmarket.com/products/campbells-condensed-unsalted-tomato-soup-10-75oz?srsltid=AfmBOorVF2fKUd7ZtBZxqXAMy6Ejhrs6QunrIMakQPpfrBenCI2nizBX
Sada kada znamo dovoljno o proizvodnom procesu konzerva juhe od rajčice, idemo na softver. Isto kao što vidite popis sastojaka od kojih je načinjena juha od rajčice (slika 2), tako i softver treba imati popis sastojaka od kojih je izrađen. Kod softvera to nisu fizički dijelovi kao kod juhe od rajčice, već drugi softver - a taj softver može u svojem procesu proizvodnje koristiti razne dodatke ili biblioteke. Problem je što te biblioteke mogu koristiti biblioteke drugih proizvođača, a te biblioteke opet ostale biblioteke, a te biblioteke… - uglavnom, shvatili ste poantu, a to je da želimo znati tko je proizveo te biblioteke i od čega se one sastoje. Popis sastojaka od kojih je softver napravljen zovemo kompozicijom softvera ili Software Composition, a analiza sastojaka softvera je Software Composition Analysis. Dokument koji dobivamo od softvera u kojem se nalaze sastojci se zove Software Bill of Materials ili kraće SBOM, a primjer možete vidjeti na slici 3.
Kada promatramo sastojke tog softvera, želimo znati tko ga je proizveo (da ne bi to ispali hakeri koji podmeću svoj špijunski softver) i koje je verzije, želimo znati tko ga održava i kakvi su budući planovi za održavanje tog softvera jer ne želimo graditi svoj sustav uz tuđe biblioteke, pa da nekada u budućnosti održavatelji odustanu od novog razvoja ili održavanja, želimo znati ima li kakvih licenci vezanih uz te sastojke te kako ga smijemo koristiti i moramo li nešto platiti. Kada identificiramo proizvođače, verzije i licence tog softvera, možemo se povezati s bazama ranjivosti i vidjeti ima li taj sastojak kakav sigurnosni propust.
Sada zamislite da kupujete novi softver. Kao i kod juhe od rajčice, zanima vas od čega se sastoji, pa ćete zatražiti SBOM kako biste to i saznali, i u tom trenu ste počeli upravljati lancem nabave svojih softverskih produkata ili rješenja koje koristite. Naravno da se i brinete o sigurnosti, pa vjerujem da sada i znate što znači Software Supply Chain Security tj. sigurnost dobavnog lanca vašeg softvera.
I koje su ranjivosti te kada ste ranjivi? Što sve i kada može poći po zlu? Ranjivosti dobavnog lanca se događaju kod izrade, distribucije i ažuriranja softvera. U sastojke softvera pokušavaju se uvući zlonamjerne biblioteke ili zlonamjerni kod treće strane te zlonamjerni alati. Sigurno ima nešto zlonamjernog u vašem softveru ako ne pratite verzije paketa biblioteka i ako ne pratite sigurnosne novosti te ne radite sigurnosni sken svojeg softvera. Zamislite da saznate da je neki paket koji koristite u svojem softverskom proizvodu ranjiv/zlonamjeran, a imate proizvod u različitim verzijama kod različitih korisnika. Ranjivosti se mogu uvući u operativne sustave, sustave za upravljanje bazama podataka, aplikacije, komponente, biblioteke…
Slika 3. Ovako izgleda SBOM tj. dokument s popisom sastojaka od kojih je softver izrađen. Ovaj dokument se kreira u trenutku izrade aplikacije i šalje na reviziju sustavima za upravljanje ranjivostima. Sustavi za upravljanje ranjivostima su povezani s bazama ranjivosti i mogu nam ukazati na to ima li koji sastojak sigurnosni propust. Na slici se može vidjeti naziv paketa (Package), verzija (Version) i licenca (License).
Postoji li primjer iz stvarnog svijeta? Naravno.
Napad na tvrtku SolarWinds 2020. godine. Napadači su u proces izgradnje softvera ugradili zlonamjerni kod. SolarWinds je tu verziju softvera isporučio kod više od 18.000 svojih korisnika, a jedan od korisnika je i vlada SAD-a. Zlonamjerni kod je omogućavao udaljeni pristup napadača svim korisnicima koji su preuzeli tu verziju softvera.
Log4Shell je iznimno popularna biblioteka za pisanje dnevničkih zapisa u Java aplikacijama. Ranjivost je postojala od 2013. godine, a otkrila se u 2021. godini. Ranjivosti je omogućavala izvršavanje zlonamjernog koda svugdje gdje je postojao Log4Shell i gdje je postojao pristup internetu.
Slika 4. Jedna od nadzornih ploča gdje možete vidjeti učitane SBOM izvještaje. Između ostalog vidljiva je verzija (version) svake komponente, ranjivost (vulnerability), kritičnost (severity) i izvor (analyzer). Kako svaka ranjivost nije iskoristiva, već ovisi o kontekstu u kojem se nalazi, možete je evidentirati u polju za reviziju (audit trail). Izvor: https://dependencytrack.org/
Kako se obraniti?
Uvoditi praćenje verzija softvera u proces izrade – pratiti repozitorij koda, razvojne alate, integracije trećih strana. OWASP nudi odlične metodologije i alate s kojima si možete pomoći – a to su:
CycloneDX – da biste kreirali izvještaj,
DependencyTrack – kako biste taj izvještaj mogli vizualno pratiti i odlučivati o ranjivostima,
DefectDojo – kako biste pratili sve izvještaje.
CycloneDX
CycloneDX je standard za SBOM kod izrade softvera. Pomaže vam izraditi SBOM i mnogo drugih xBOM-ova (Everything as Bill of Materials) kao što su:
SaaSBOM – pomoć kada koristite softver kao uslugu,
HBOM – kada koristite hardver,
ML-BOM – strojno učenje,
CBOM – kriptografski popis kako biste znali koje algoritme koristite,
OBOM – inventar runtime okruženja, konfiguracija i operativnih ovisnosti sustava,
MBOM – evidencija načina izrade komponenti ili servisa koja osigurava sljedivost i reproducibilnost kroz životni ciklus proizvoda,
BOV – Strukturirani popis ranjivosti s procjenama rizika i preporukama za razmjenu sigurnosnih informacija,
VDR – izvještaj o poznatim ili novootkrivenim ranjivostima koji omogućuje koordinirano otkrivanje sigurnosnih problema,
VEX – informacija o stvarnoj iskoristivosti ranjivosti u konkretnom proizvodu radi procjene realnog rizika,
CDXA – standard za sigurnosne tvrdnje, dokaze i compliance podatke koji omogućuje „compliance as code“,
CRNF (Common Release Notes Format) – standardizirani strojno čitljiv format release notesa koji olakšava automatizaciju i komunikaciju promjena softvera.
Mnoštvo ostalih informacija i detalja o xBOM-ovima možete saznati na https://cyclonedx.org/guides/.
DependencyTrack
DependencyTrack je open source Software Composition Analysis platforma za kontinuiran nadzor i analizu SBOM-ova, pod pokroviteljstvom je OWASP-a i možete je besplatno koristiti te ima integraciju na mnoštvo ostalih alata - od kojih je jedan i Defect Dojo (u nastavku). Uz analizu SBOM-a moguće je i:
Praćenje ovisnosti – jasan pregled svih biblioteka i komponenti u aplikacijama,
Detekcija ranjivosti – automatski pronalazi poznate sigurnosne propuste,
Prioritizacija rizika – fokus na ono što stvarno treba prvo riješiti,
Lifecycle monitoring – sigurnosni nadzor kroz cijeli životni ciklus softvera,
Policy & compliance – jednostavna kontrola sigurnosnih pravila i usklađenosti,
Alerting – obavijesti čim se pojavi nova prijetnja kroz kanale koje se namjeste,
Vizualizacija i izvještaji – pregledni dashboardi za brze sigurnosne odluke (primjer se može vidjeti na slici 4),
open-source SCA – moćan, otvoreni alat (besplatan) za sigurniji software supply chain.
Slika 5. Primjer izgleda nadzorne ploče u DefectDojo. Na prvi pogled izgleda kao previše informacija, ali moguće je uređivati widgete i tako dobiti optimalan prikaz za svačije potrebe. Izvor: https://defectdojo.com/platform
DefectDojo
Dok nam DependencyTrack kao alat daje analizu što koristimo u softveru, DefectDojo nam odgovara na pitanje koje sigurnosne probleme imamo i kako ih riješiti. Može agregirati izvještaje iz više AppSec alata kao što su DependencyTrack i uz SBOM-ove, agregira rezultate statičke analize koda (SAST), dinamičke analize koda (DAST) i drugih sigurnosnih testova na jedno mjesto, a uz to nudi razne funkcionalnosti praćenja, prioritizacije i rješavanja sigurnosnih problema.
OWASP Top 10 2025 još jednom potvrđuje da je sigurnost aplikacija kontinuiran proces – od pravilne kontrole pristupa, preko sigurnog razvoja koda, pa sve do nadzora dobavnog lanca softvera. Nove kategorije ranjivosti jasno pokazuju da se sigurnosni fokus sve više širi izvan same aplikacije na ekosustav alata, biblioteka i procesa koji sudjeluju u njezinoj izradi i održavanju. Drugim riječima, sigurnost više nije samo tehničko pitanje, već pitanje upravljanja, transparentnosti i odgovornosti kroz cijeli životni ciklus softvera.
