OWASP Top 10 najpoznatiji je popis u sigurnosti web aplikacija. Objavljuje ga Open Worldwide Application Security Project, neprofitna zajednica koja okuplja stručnjake iz cijelog svijeta, a popis sažima deset najozbiljnijih kategorija rizika za web aplikacije.1 Posljednje izdanje objavljeno je 2021. godine i temelji se na podacima iz stotina tisuća stvarnih aplikacija te na anketi struke o rizicima koje brojke same ne hvataju. Za razvojne timove, testere i naručitelje softvera to je zajednička polazna referenca. Ako aplikacija dobro adresira ovih deset područja, uklonjen je velik dio najčešćih uzroka napada.
Za reguliranu hrvatsku tvrtku iz financija, zdravstva, kritične infrastrukture ili SaaS-a popis ima i praktičnu, ugovornu vrijednost. Web aplikacija je najizloženiji dio sustava jer je javno dostupna svima na internetu. Curenje osobnih podataka kroz nju izravno aktivira obveze prema GDPR-u i nadzor AZOP-a, a u financijskom sektoru i zahtjeve DORA-e za otpornost. OWASP Top 10 daje zajednički jezik kojim tvrtka može provjeriti svoj softver i postaviti jasan kriterij dobavljaču. Ovaj tekst objašnjava svaku od deset kategorija iz izdanja 2021., daje konkretan primjer i obranu, te pokazuje kako popis koristiti u praksi bez čestih pogrešaka.
Ovo je dio našeg pregleda sigurnosti web aplikacija. Testiranje i ispravljanje ovih rizika pružamo kroz sigurnost aplikacija i clouda te ofenzivnu sigurnost.
Što je OWASP i zašto je popis industrijska referenca
OWASP je otvorena, neprofitna zajednica koja besplatno objavljuje alate, vodiče i metodologije za sigurnost softvera. Top 10 njihov je najpoznatiji proizvod, a ugled je stekao jer nije nastao iz mišljenja jednog proizvođača nego iz podataka. Većina kategorija rangira se prema učestalosti i utjecaju ranjivosti pronađenih u golemom broju stvarnih aplikacija, a dio prema anketi stručnjaka o rizicima koji su važni iako ih skeneri rijetko bilježe.
Zbog te metodologije popis je postao zajednički jezik cijele industrije. Razvojni tim, tester i naručitelj mogu o riziku govoriti istim pojmovima. Ugovori, sigurnosni upitnici i zahtjevi za ponudu redovito se pozivaju na OWASP Top 10 kao mjeru kvalitete. Standardi sigurnog razvoja, poput NIST okvira SSDF, naslanjaju se na iste obrasce ranjivosti.2 Zato pokrivanje ovih deset područja danas predstavlja osnovnu razinu dužne pažnje za svaku javno dostupnu aplikaciju.
Deset kategorija iz izdanja 2021.
Izdanje iz 2021. donosi deset kategorija, od kojih su tri nove ili znatno preoblikovane u odnosu na ranija izdanja: nesiguran dizajn, propusti integriteta softvera i podataka te SSRF. Tablica daje sažet pregled, a odjeljci ispod razrađuju svaku kategoriju s primjerom i obranom.1
| Kategorija | Što znači | Osnovna obrana |
|---|---|---|
| A01 Slaba kontrola pristupa | Korisnik dohvaća podatke ili izvodi radnje koje mu ne pripadaju. | Provjera ovlasti na poslužitelju pri svakom pozivu, uskraćivanje kao zadano. |
| A02 Kriptografski propusti | Osjetljivi podaci nisu ispravno zaštićeni u prijenosu ili pohrani. | HTTPS posvuda, snažni algoritmi, hashiranje lozinki, šifriranje osjetljivih polja. |
| A03 Injekcija | Nepouzdani unos mijenja upit ili naredbu, primjerice SQL injekcija. | Parametrizirani upiti, validacija unosa, kontekstualno escapanje izlaza. |
| A04 Nesiguran dizajn | Sigurnost nije ugrađena u arhitekturu od početka. | Modeliranje prijetnji, sigurni obrasci dizajna, sigurnosni zahtjevi. |
| A05 Pogrešna konfiguracija | Zadane postavke, otvorene usluge ili izloženi podaci. | Učvršćivanje, uklanjanje suvišnih funkcija, dosljedan postupak postavljanja. |
| A06 Ranjive i zastarjele komponente | Korištenje knjižnica i okvira s poznatim ranjivostima. | Popis komponenti, praćenje ranjivosti, redovito ažuriranje. |
| A07 Propusti autentifikacije | Loše upravljanje prijavom, lozinkama i sesijama. | MFA, zaštita od pogađanja lozinki, sigurno upravljanje sesijama. |
| A08 Propusti integriteta softvera i podataka | Nepouzdani izvori koda ili ažuriranja bez provjere. | Provjera potpisa, osigurani CI/CD lanac, kontrola ovisnosti. |
| A09 Propusti bilježenja i nadzora | Napad se ne primijeti jer nema zapisa ni upozorenja. | Bilježenje sigurnosnih događaja, centralizacija, upozorenja i nadzor. |
| A10 SSRF | Aplikacija se navede da pošalje zahtjev na neželjeno odredište. | Validacija odredišta, popis dopuštenih hostova, ograničenje izlaznog prometa. |
A01 do A04: pristup, kriptografija, injekcija i dizajn
A01 slaba kontrola pristupa najčešća je kategorija u izdanju 2021. Nastaje kad aplikacija provjeri da je korisnik prijavljen, ali ne provjeri smije li baš on vidjeti traženi podatak ili izvesti radnju. Tipičan primjer je korisnik koji u adresi promijeni broj računa i dohvati tuđi račun, ili obični korisnik koji pozove administratorsku rutu. Obrana je provjera ovlasti na poslužitelju pri svakom pozivu, po načelu uskraćivanja kao zadanog stanja, nikad samo skrivanjem u sučelju.
A02 kriptografski propusti odnose se na osjetljive podatke koji nisu zaštićeni kako treba. To uključuje promet bez HTTPS-a, lozinke pohranjene u čistom tekstu ili sa slabim algoritmom, te osjetljiva polja poput OIB-a koja stoje nešifrirana u bazi. A03 injekcija nastaje kad nepouzdani unos mijenja upit ili naredbu. Klasičan primjer je SQL injekcija, gdje napadač u polje za pretragu unese vrijednost koja produži upit prema bazi. Obrana su parametrizirani upiti i dosljedna validacija unosa, koji jasno odvajaju podatke od naredbi.
A04 nesiguran dizajn nova je kategorija iz 2021. i pomiče težište prije pisanja koda. Razlikuje se od pogrešne konfiguracije: ovdje propust nije u postavci nego u samoj zamisli sustava. Primjer je tok oporavka lozinke koji se oslanja na sigurnosno pitanje s lako dostupnim odgovorom, ili plaćanje koje vjeruje iznosu poslanom s klijenta. Takve greške nijedan skener ne hvata jer aplikacija radi točno kako je zamišljena. Obrana je modeliranje prijetnji i postavljanje sigurnosnih zahtjeva u fazi dizajna.
A05 do A07: konfiguracija, komponente i autentifikacija
A05 pogrešna sigurnosna konfiguracija obuhvaća zadane lozinke, otvorene administrativne sučelja, detaljne poruke o greškama koje otkrivaju unutarnju strukturu i suvišne usluge koje nitko ne koristi. Primjer je oblak spremnik s podacima ostavljen javno dostupnim ili okvir pokrenut u razvojnom načinu rada na produkciji. Obrana je sustavno učvršćivanje, uklanjanje svega nepotrebnog i ponovljiv, dokumentiran postupak postavljanja okoline.
A06 ranjive i zastarjele komponente odnose se na knjižnice, okvire i alate s poznatim, javno objavljenim ranjivostima. Moderna aplikacija sastoji se većinom od tuđeg koda, pa jedna zastarjela ovisnost može otvoriti cijeli sustav. Obrana počinje popisom svih komponenti i njihovih verzija, praćenjem objava o ranjivostima i redovitim ažuriranjem. A07 propusti autentifikacije obuhvaćaju slabe lozinke, nepostojanje zaštite od pogađanja, loše upravljanje sesijama i izostanak višefaktorske provjere. Obrana je dvofaktorska autentifikacija, ograničavanje pokušaja prijave i sigurno rukovanje tokenima sesije.
A08 do A10: integritet, bilježenje i SSRF
A08 propusti integriteta softvera i podataka nova su kategorija usmjerena na lanac opskrbe softvera. Nastaje kad aplikacija preuzme kod, ovisnost ili ažuriranje iz nepouzdanog izvora bez provjere. Primjer je mehanizam automatskog ažuriranja koji ne provjerava digitalni potpis, ili CI/CD lanac u koji napadač ubaci zlonamjernu izmjenu. Obrana je provjera potpisa, kontrola ovisnosti i osiguravanje cjevovoda za izgradnju i isporuku.
A09 propusti bilježenja i nadzora znače da se napad dogodi, ali ga nitko ne primijeti jer nema zapisa ni upozorenja. Bez vidljivosti, prosječno vrijeme do otkrivanja proboja mjeri se mjesecima, a to izravno utječe i na rok prijave incidenta prema GDPR-u i NIS2 obvezama. Obrana je bilježenje sigurnosno važnih događaja, centralizacija zapisa i upozorenja koja netko stvarno prati. A10 SSRF, na engleskom Server-Side Request Forgery, nastaje kad se aplikacija navede da sama pošalje zahtjev na odredište koje napadač zada. Primjer je funkcija dohvaćanja slike s URL-a koju napadač usmjeri na unutarnji servis u oblaku i tako dođe do internih podataka. Obrana je validacija odredišta, popis dopuštenih hostova i ograničavanje izlaznog prometa aplikacije.
Gotovo svaki ozbiljan propust web aplikacije svodi se na isto: poslužitelj nije provjerio smije li korisnik napraviti to što traži.
Kako se popis koristi u praksi
OWASP Top 10 najbolje funkcionira kao osnova, ne kao potpun popis. To je polazna referenca koja pokriva najčešće i najutjecajnije rizike, ali ne sve. Aplikacije koje se snažno oslanjaju na sučelja za strojeve trebaju dodatno pogledati OWASP API Security Top 10, a sustavi s velikim jezičnim modelima imaju vlastiti skup rizika. U praksi popis ima tri uloge: vodilja razvojnom timu, kriterij u nabavi softvera i okosnica metodologije pri testiranju.
- 01Ugradite sigurnost u dizajnModelirajte prijetnje i postavite sigurnosne zahtjeve prije pisanja koda, ne nakon incidenta.
- 02Provjeravajte unos i pristupTretirajte svaki vanjski unos kao nepouzdan i provjeravajte ovlasti na poslužitelju pri svakoj radnji.
- 03Održavajte komponenteVodite popis ovisnosti, pratite objave o ranjivostima i redovito ažurirajte.
- 04Testirajte aplikacijuKombinirajte automatsko skeniranje i ručno penetracijsko testiranje web aplikacija.
- 05Bilježite i nadziriteVodite zapise sigurnosnih događaja i postavite upozorenja kako biste napad primijetili na vrijeme.
Veza s testiranjem i sigurnim razvojem
OWASP Top 10 je referenca za rizike, ali sam po sebi ne osigurava aplikaciju. Da bi imao učinak, mora biti ugrađen u dvije prakse. Prva je siguran razvoj: pristup poznat kao DevSecOps znači razmišljanje o prijetnjama od dizajna i automatske sigurnosne provjere kroz cijeli razvojni ciklus. Ispravljanje propusta u fazi dizajna mnogo je jeftinije od krpanja nakon lansiranja.
Druga praksa je testiranje. Automatski skeneri pronalaze dio rizika s popisa, posebno injekciju i zastarjele komponente, ali ne hvataju greške u logici, kontroli pristupa i dizajnu. Te kategorije, koje su ujedno najopasnije, otkriva tek ručno penetracijsko testiranje web aplikacija koje razumije kontekst aplikacije. Po našem iskustvu, kombinacija automatskog skeniranja u cjevovodu i periodičnog ručnog testa daje najbolju pokrivenost, a stvarna procjena ovisi o opsegu aplikacije.
Kako Raptoric pomaže
Testiramo web aplikacije prema OWASP metodologiji i pomažemo razvojnim timovima ugraditi sigurnost u proces, kroz sigurnost aplikacija i clouda i ofenzivnu sigurnost. Kao neovisna tvrtka ne prodajemo softver koji bismo trebali testirati, pa su naši nalazi nepristrani. Dogovorite uvodni razgovor.