Tīmekļa lietotņu un API ielaušanās testēšana
Lietotņu ielaušanās testi jeb pentesti ir kontrolēti uzbrukumi jūsu programmatūrai. Tīmekļa lietotnēs, mobilajās lietotnēs un API meklējam izmantojamas ievainojamības, pirms tās atrod kāds, kas par savu ierašanos nebrīdina. Kas atrasts pārbaudē, vēlāk nekļūst par datu noplūdi, sodu vai zaudētu klientu.
Testējam tīmekļa, mobilās, darbvirsmas un hibrīda lietotnes kopā ar API un pirmkodu. Testēšana ir manuāla; automatizētus rīkus pieslēdzam tur, kur tie tiešām paātrina darbu. Scenārijus veidojam atbilstoši OWASP WSTG un OWASP Top 10, mobilajām lietotnēm – atbilstoši OWASP MASVS.
Darba beigās saņemat tehnisku ziņojumu: ko atradām, kā to atkārtot, cik liels ir risks un ar kādām izmaiņām to novērst.
Mums uzticas
Kas ir lietotņu ielaušanās testēšana un pret ko tā pasargā?
Pārbaude ir kontrolēts uzbrukums: strādājam iepriekš saskaņotā tvērumā un ar rakstisku atļauju. Ziņojumā nenonāk skenera izdruka – ko atrodam, to arī izmantojam un parādām, cik tālu uzbrucējs ar to var nokļūt.
Vislielāko labumu pārbaude dod pirms jaunas versijas palaišanas vai uzreiz pēc lielām izmaiņām, taču tā noder arī tad, ja pierādījumus prasa klients, apdrošinātājs vai iepirkuma nolikums. Tirgus šo pašu darbu sauc dažādi: gan par lietotņu drošības testēšanu, gan par ielaušanās testiem, gan vienkārši par pentestu. Rezultātu nosaka nevis nosaukums, bet tas, kurš darbu veic.
Pieredze
Ikdienā veicam ielaušanās testus, Red Team uzbrukumu simulācijas un pirmkoda analīzi. Testē cilvēks; rīks tikai palīdz.
Caurskatāmība
Jebkurā brīdī zināt, kurā posmā esam un ko tieši pārbaudām. Tvērumu un termiņus saskaņojam sākumā, nevis darba gaitā.
Sadarbība
Runājam tieši ar izstrādātājiem, ne tikai ar projekta vadītāju. Ziņojumu var likt lietā jau nākamajā dienā.
Profesionalitāte
Testēšana neiziet ārpus saskaņotā tvēruma, un par visu redzēto ievērojam konfidencialitāti. Metodika ir publiska: OWASP WSTG un ASVS.
Testēšanas gaita
Kā notiek tīmekļa lietotņu ielaušanās tests?
Sākam ar mērķu un tvēruma saskaņošanu. Tālāk seko izlūkošana, vispirms pasīvā un pēc tam aktīvā. Katru aizdomīgo vietu pārbaudām praksē, un, ko izmantot neizdodas, tas ziņojumā nenonāk: labošanai nododam tikai pārbaudītus konstatējumus.
Tvērums un mērķi
Vienojamies, kura lietotne, kuri API un kuras lietotāju lomas ietilpst pārbaudē.
Izlūkošana un analīze
Veicam pasīvus un aktīvus testus, koncentrējoties uz reāliem uzbrukuma ceļiem.
Izmantojamības pārbaude
Katru konstatējumu izmēģinām praksē un pierakstām soļus, kā to atkārtot.
Ziņojums
Nododam konstatējumus, kas sakārtoti pēc riska, un konkrētus novēršanas soļus.
Tvērums
Kādas lietotnes un API testējam?
Pārbaudām visu lietotni – no saskarnes pārlūkā līdz API, kas strādā aiz tās. Katram slānim ir savas tipiskās vājās vietas, un testus pielāgojam tieši tām.
Tīmekļa lietotnes
Pārbaudām autentifikāciju, piekļuves tiesības, injekcijas, sesiju pārvaldību un servera konfigurāciju.
Mobilās lietotnes
Skatāmies, kas paliek ierīcē, kā notiek šifrēšana un ko atļauj aizmugursistēma. Mēraukla ir OWASP MASVS.
API
Galapunktos pārbaudām autorizāciju, datu apstrādi un biznesa loģiku. Nopietnākās kļūdas visbiežāk slēpjas tieši šeit, aiz saskarnes.
Darbvirsmas lietotnes
Skatāmies, kādi sensitīvi dati paliek datorā, ar kādām tiesībām lietotne darbojas un ko tā sūta uz serveri.
Pirmkoda audits
Statiskā analīze kopā ar manuālu koda pārlasīšanu atklāj vāju validāciju un tādas loģikas kļūdas, līdz kurām no ārpuses ceļa nav.
Metodika
Ko dod OWASP WSTG un ASVS?
OWASP Top 10 ir biežāko tīmekļa ievainojamību saraksts, nevis testēšanas plāns. No tā ņemam riska secību, bet faktisko pārklājumu nosaka OWASP Web Security Testing Guide (WSTG): tas testu pa testam apraksta, ko tīmekļa lietotnē pārbaudīt – no konfigurācijas un identitātes pārvaldības līdz sesijām, ievaddatiem un biznesa loģikai.
OWASP Application Security Verification Standard (ASVS) papildina WSTG ar prasību līmeņiem: L1 ir bāzes līmenis publiskai lietotnei, L2 – lietotnēm ar sensitīviem datiem, L3 – kritiskām sistēmām. Pirms darba vienojamies, pēc kura līmeņa vērtēt, un tad ziņojumā redzat ne tikai atsevišķas kļūdas, bet arī to, cik tālu lietotne ir no izvēlētā līmeņa.
API testēšanā balstāmies arī uz OWASP API Security Top 10, jo tur dominē citas kļūdas nekā pārlūkā: autorizācijas apiešana objektu līmenī, pārāk plaša datu atgriešana un neierobežots resursu patēriņš. Ja ir pieejama OpenAPI specifikācija, to pārņemam, taču uz to nepaļaujamies – vājākie parasti ir tieši nedokumentētie galapunkti.
OWASP nav standarts, ko varētu sertificēt, un neviens par to neizsniedz apliecinājumu. Tā ir atklāta metodika, kuru uztur pati nozare, un tieši tāpēc tā der par kopīgu valodu: gan izstrādātājs, gan pasūtītāja drošības komanda saprot, uz ko ziņojumā ir atsauce.
Salīdzinājums
Ielaušanās tests vai pirmkoda audits?
Viens otru neaizstāj. Ielaušanās tests uzbrūk strādājošai lietotnei, savukārt pirmkoda audits atrod to, kas kodā ir nepareizi, vēl pirms palaišanas.
| Kritērijs | Ielaušanās tests | Pirmkoda audits |
|---|---|---|
| Uzmanības centrā | Strādājoša lietotne, tās konfigurācija un dati. | Loģikas un drošības kļūdas kodā. |
| Metodika | Manuāla testēšana ar reāliem uzbrukuma paņēmieniem. | Statiskā analīze un manuāla koda pārlasīšana. |
| Kad | Pēc palaišanas un pēc katrām būtiskām izmaiņām. | Izstrādes laikā, vēl pirms palaišanas. |
| Rezultāts | Ziņojums ar faktisko ietekmi un novēršanas prioritātēm. | Konstatējumi koda līmenī ar ieteiktajiem labojumiem. |
Neesat pārliecināti, kāda testu kombinācija der jūsu lietotnei? Rakstiet mums.
Klientu atsauksmes
Ko par mums saka klienti
Biežāk uzdotie jautājumi
01 Cik ilgi notiek ielaušanās tests?
Tas ir atkarīgs no tvēruma. Nelielai tīmekļa lietotnei parasti pietiek ar 3–5 dienām, sarežģītai sistēmai ar daudzām lomām un integrācijām vajag 1–3 nedēļas. Precīzu laika grafiku un tvērumu pēc pirmās sarunas fiksējam rakstiski.
02 Cik maksā lietotnes ielaušanās tests?
Cenu nosaka tvērums un sarežģītība: lietotņu skaits, lietotāju lomas, API galapunktu skaits, integrācijas un tas, vai testējam arī pirmkodu. Lietotne ar divām lomām un dažiem galapunktiem 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.
03 Cik bieži atkārtot ielaušanās testu?
Vismaz reizi gadā, kā arī pēc katrām izmaiņām, kas maina uzbrukuma virsmu: jauna versija, jauns API, pāreja uz mākoni vai jauna integrācija. Nacionālās kiberdrošības likuma (NKDL) subjektiem regulāras IKT infrastruktūras drošības pārbaudes paredz pats likums, un to kārtību nosaka Ministru kabineta noteikumi Nr. 397. HAXORIS ir Slovākijas uzņēmums, kas veic tehnisku drošības testēšanu, nevis valsts uzraudzības procedūras.
04 Vai testa laikā lietotne var apstāties?
Nē. Produkcijas vidē neveicam testus, kas varētu izraisīt darbības pārtraukumu, un riskantākos soļus saskaņojam iepriekš. Ja ir atsevišķa testa vide, strādājam tajā; ja nav, lielākas slodzes testus veicam apkopes laikā.
05 Ko saņemat pēc testa?
Ziņojumu: kopsavilkumu vadībai, tehnisku aprakstu par katru konstatējumu, soļus tā atkārtošanai, riska novērtējumu un konkrētus novēršanas ieteikumus. Rezultātus pārrunājam noslēguma sanāksmē kopā ar jūsu komandu, un pēc labojumiem varam veikt atkārtotu pārbaudi.
