OWASP
Ielaušanās testēšana atbilstoši OWASP metodoloģijai
Kritiska kļūda maksā vismazāk tad, ja to atrod testētājs, nevis uzbrucējs. Tīmekļa lietotņu un API ielaušanās testēšanu veicam atbilstoši OWASP metodoloģijai – tā ir starptautiski atzīta mēraukla, uz kuru atsaucas gan izstrādātājs, gan auditors. Visas desmit riska kategorijas pārbaudām arī manuāli, jo automatizēta skenēšana ir tikai sākumpunkts.
Mums uzticas
OWASP
Kas ir OWASP un kāpēc uz to atsaucas visi?
OWASP (Open Web Application Security Project) ir starptautiska bezpeļņas organizācija, kas nodarbojas ar programmatūras drošību. Tās materiāli ir atklāti un pieejami bez maksas, un tieši tāpēc tie kļuvuši par mērauklu: uz vienu un to pašu sarakstu atsaucas izstrādes komanda, auditors un arvien biežāk arī pasūtītājs.
Mums OWASP nav ievainojamību saraksts, bet gan darba ietvars. Tāpēc vienas un tās pašas lietotnes divas pārbaudes ir salīdzināmas, un rezultātu vairs nenosaka tas, kurš speciālists pie tās apsēdies. Ar to var iepriekš aprakstīt gan tvērumu, gan pārklājumu, tāpēc jau pirms darba sākuma zināt, ko pārbaudīsim un ko ne.
Nosaukumi Latvijā atšķiras, darbs paliek tas pats. Nacionālās kiberdrošības likumā (NKDL) un Ministru kabineta noteikumos Nr. 397 to sauc par IKT infrastruktūras drošības pārbaudi, tirgū – par ielaušanās testu jeb pentestu. Metodoloģija abos gadījumos ir viena un tā pati.
OWASP Top 10
OWASP Top 10 latviski: desmit nopietnākie tīmekļa riski
Testēšanas pamatā ir OWASP Top 10 – desmit nopietnāko tīmekļa lietotņu risku saraksts. To uztur nozares kopiena, balstoties uz simtiem organizāciju datiem, un secība nav nejauša: sākam ar to, kas var nodarīt vislielāko postu. Kategoriju nosaukumus atstājam angliski, jo tādi tie ir gan ziņojumā, gan kļūdu reģistrā; latvisko skaidrojumu liekam iekavās.
Testējam atbilstoši spēkā esošajai OWASP Top 10:2025 redakcijai. Ja vajadzīgas 2021. gada kategorijas, sagatavojam sasaisti ar tām.
| Risks | Apraksts |
|---|---|
| A01:2025 – Broken Access Control (nepietiekama piekļuves kontrole) | Piekļuves kontroles trūkums vai kļūda ļauj uzbrucējam tikt pie datiem un funkcijām, uz kurām viņam nav tiesību. 2025. gada redakcijā šajā kategorijā iekļauts arī Server-Side Request Forgery (SSRF). |
| A02:2025 – Security Misconfiguration (nepareiza drošības konfigurācija) | Servera, ietvara vai pašas lietotnes iestatījumi paver ceļu uzbrukumam – visbiežāk tāpēc, ka spēkā palikuši ražotāja noklusējumi. |
| A03:2025 – Software Supply Chain Failures (programmatūras piegādes ķēdes trūkumi) | Uzbrukums caur programmatūras piegādes ķēdi: atkarībām, pakotņu repozitorijiem, būvēšanas sistēmu vai atjauninājumu kanālu. Šeit ietilpst arī komponentes ar zināmām ievainojamībām. Kategorija ir plašāka nekā 2021. gada „Vulnerable and Outdated Components“, kuru tā aizstāj. |
| A04:2025 – Cryptographic Failures (kriptogrāfijas trūkumi) | Slikti īstenota šifrēšana, caur kuru noplūst sensitīvi dati: paroles, personas dati, maksājumu informācija. |
| A05:2025 – Injection (injekcijas) | Uzbrucējs var lietotnē ievadīt un izpildīt savu kodu – tāda ir SQL injekcija. Tā viņš pārņem kontroli pār datubāzi vai visu sistēmu. |
| A06:2025 – Insecure Design (nedroša projektēšana) | Projektēšanas kļūda, ko ar vienu koda labojumu novērst nevar: jāmaina arhitektūra. |
| A07:2025 – Authentication Failures (autentifikācijas trūkumi) | Vājās vietas pieteikšanās procesā, paroļu apstrādē un sesiju pārvaldībā, kuras ļauj uzbrucējam ienākt likumīga lietotāja vārdā. |
| A08:2025 – Software or Data Integrity Failures (programmatūras vai datu integritātes trūkumi) | Kļūdas, kas ļauj uzbrucējam nomainīt datus vai pašu programmatūru – tipiski atjaunināšanas laikā. |
| A09:2025 – Security Logging and Alerting Failures (žurnalēšanas un brīdināšanas trūkumi) | Par maz ierakstu žurnālos, trūkstoši brīdinājumi, vāja uzraudzība. Uzbrukumu tāpēc ir grūti pamanīt, par to laikus paziņot un vēlāk atjaunot notikumu gaitu. |
| A10:2025 – Mishandling of Exceptional Conditions (izņēmuma situāciju nepareiza apstrāde) | Nepareizi apstrādātas kļūdas, izņēmumi un neparedzēti stāvokļi: lietotne avarē, kļūdas gadījumā pieprasījumu izlaiž cauri tā vietā, lai to noraidītu, vai detalizētos kļūdu paziņojumos un izsaukumu steka saturā izpauž savu iekšējo uzbūvi. Jauna kategorija 2025. gada redakcijā. |
OWASP projekti
Ar Top 10 vien nepietiek: ko pārbaudām papildus?
OWASP Top 10 ir labs sākumpunkts, taču desmit kategorijas nenosedz visu lietotnes uzbrukuma virsmu. Pārējo aizpildām ar citiem OWASP projektiem un rīkiem.
OWASP ASVS
Detalizēts drošības kontroļu prasību saraksts. Ejam tam cauri punktu pa punktam, tāpēc pārbaude sniedzas krietni dziļāk par desmit kategorijām. Līmeni – L1, L2 vai L3 – saskaņojam pirms darba sākuma.
OWASP API Top 10
API riskiem ir savs saraksts. Testējam tos atsevišķi, jo aiz saskarnes ceļš līdz datiem parasti ir īsāks.
OWASP ZAP un Dependency-Check
Manuālo darbu papildinām ar dinamisko analīzi un pārbaudām, uz kurām ārējām bibliotēkām ar zināmām ievainojamībām lietotne balstās.
OWASP SAMM
Palīdzam sakārtot arī izstrādes procesu, lai kļūda atklātos jau kodējot, nevis testa beigās.
Darba gaita
Kā notiek ielaušanās tests atbilstoši OWASP?
Visā darba gaitā jūs zināt, kurā posmā esam un ko tieši pārbaudām. Ar jūsu komandu sazināmies regulāri, tāpēc darbs neapstājas tikai tādēļ, ka kādam vēl jāapstiprina piekļuve.
Tvērums un noteikumi
Kopā nosakām mērķus, tvērumu un testēšanas noteikumus. Vienlaikus izveidojam draudu modeli tieši šai lietotnei: kuru tā interesē un ko uzbrucējs no tās gribētu iegūt.
Testēšana un analīze
Izmantojam gan automatizētus rīkus, gan manuālu darbu, taču katru konstatējumu pārbaudām praksē. Scenāriju veido OWASP Top 10 un ASVS, ko papildinām ar to, kas vajadzīgs konkrētajai lietotnei.
Ziņojums
Ziņojumā ir gan kopsavilkums vadībai, gan tehnisks apraksts izstrādātājiem. Katram konstatējumam norādām ietekmi, riska līmeni un konkrētus novēršanas soļus.
Atkārtota pārbaude
Pēc labojumiem veicam atkārtotu pārbaudi bez papildu maksas un rakstiski apstiprinām, kuri konstatējumi ir novērsti.
Klientu atsauksmes
Ko par mums saka klienti
Kāpēc testēšanu atbilstoši OWASP uzticēt mums?
Publiska metodika
Strādājam atbilstoši OWASP Top 10, ASVS un WSTG. Pirms darba varat redzēt, kā vērtēsim, un pēc darba – pārbaudīt, vai tas tiešām izdarīts.
Manuāls darbs
Automatizēts rīks atrod zināmas kļūdas. Biznesa loģikas kļūdas, apietas piekļuves tiesības un vairāku ievainojamību savienošanu vienā uzbrukuma ķēdē atrod cilvēks.
Konkrēti novēršanas soļi
Ziņojums nav problēmu saraksts. Pievienojam koda fragmentus, atsauces uz avotiem un secību, kādā trūkumus labot.
Sadarbība ar izstrādātājiem
Runājam tieši ar izstrādātājiem, ne tikai ar projekta vadītāju. Pēc ziņojuma nodošanas nepazūdam.
Biežāk uzdotie jautājumi
01 Kas ir OWASP Top 10 un kurš to veido?
OWASP Top 10 ir pasaulē visbiežāk citētais saraksts ar desmit nopietnākajiem tīmekļa lietotņu drošības riskiem. Aiz tā stāv simtiem organizāciju iesūtītie dati un tūkstošiem speciālistu darbs, un reizi dažos gados sarakstu atjaunina. Spēkā esošā redakcija ir 2025. gada.
02 Vai testēšana atbilstoši OWASP aizstāj citus drošības standartus?
Nē. OWASP ir ieteikumu un metodoloģiju kopums, nevis sertificējams standarts kā ISO/IEC 27001 vai PCI DSS. Tam nevar arī „atbilst“: tā ir atklāta metodika, kuru uztur pati nozare, un neviens par to apliecinājumu neizsniedz.
Toties tests atbilstoši OWASP sedz tieši tās tehniskās prasības, ko šie standarti izvirza. Nacionālās kiberdrošības likums (NKDL) un Ministru kabineta noteikumi Nr. 397 saviem subjektiem paredz regulāras IKT infrastruktūras drošības pārbaudes, un ziņojums der par tehnisku pierādījumu, ka pārbaude tiešām notikusi.
HAXORIS ir Slovākijas uzņēmums: veicam tehnisku drošības testēšanu, nevis NKDL 44. pantā noteikto auditu, un atzinumu par likuma prasību izpildi neizsniedzam.
03 Ko saņemat darba beigās?
Ziņojumu: kopsavilkumu lēmumu pieņēmējiem un tehnisku aprakstu par katru konstatējumu. Katram no tiem blakus ir OWASP kategorija, riska līmenis, soļi atkārtošanai un konkrēts novēršanas ieteikums. Rezultātus pārrunājam noslēguma sanāksmē, un pēc labojumiem veicam vienu atkārtotu pārbaudi bez papildu maksas.
04 Cik maksā tests atbilstoši OWASP metodoloģijai?
Cenu nosaka tvērums un sarežģītība: lietotņu skaits, lietotāju lomas, API galapunktu skaits, integrācijas un tas, vai vērtējam arī atbilstoši kādam ASVS līmenim. Lietotne ar divām lomām izmaksā būtiski mazāk nekā platforma ar desmitiem integrāciju. Pēc īsas sarunas par tvērumu sagatavojam fiksētu piedāvājumu, kas jūs ne pie kā nesaista.
05 Vai tests ir drošs produkcijas vidē?
Jā. Procedūras veidojam tā, lai ikdienas darbību tās traucētu pēc iespējas mazāk, un riskantākos soļus saskaņojam iepriekš. Strādājam ar rakstisku atļauju un iepriekš fiksētā tvērumā, no kura neizejam. Ja ir atsevišķa testa vide, strādājam tajā.
