Veebirakenduse turvatestimine: mis jääb skannerist märkamata?
Veebirakenduse pentest vaatab, kas päris kasutaja saab rakendust kasutada viisil, mida omanik ei kavandanud. E-poes tähendab see näiteks kliendiandmete, tellimuste ja haldusõiguste kaitset, mitte ainult kodulehe tehniliste päiste kontrolli.
Mida veebirakenduse turvatestimine näitab?
Veebirakenduse pentest (inglise keeles web application penetration testing) hindab kokkulepitud rakenduse voogusid ja ligipääse: sisselogimist, kasutajarolle, seansse, sisendeid ja äriloogikat. Testija ühendab automatiseeritud kontrollid käsitsi tehtud kasutusvoogude ja õiguste kontrolliga. Tulemus kehtib kokkulepitud ulatuses ega tõenda, et rakenduses vigu pole.
Mida veebirakenduse pentestis kontrollida?
Veebileht ei ole ainult brauseris nähtav kasutajaliides. Brauser ja frontend saadavad päringuid backendile, mis peab ise kontrollima identiteeti ja õigusi. Nuppu peita või URL-i kasutajale mitte näidata ei piisa, kui server lubab sama toimingu päringuga siiski teha. Seepärast tuleb vaadata kogu kokkulepitud rakenduse konteksti.
- Sisselogimine ja konto taastamine: kas autentimine, parooli muutmine ja väljalogimine toimivad ootuspäraselt?
- Rollid ja objektide ligipääs: kas tavakasutaja näeb ainult enda tellimusi ja andmeid, administraator aga ainult talle määratud õigustega?
- Seansid: kas seansi identifikaator vahetub sisselogimisel, aegub ja kaotab kehtivuse väljalogimisel?
- Sisend ja konfiguratsioon: kuidas käsitletakse vorme, faile ja erimärke; kas rakendus avaldab tarbetut tehnilist infot või ebaturvalisi seadistusi?
- Äriloogika: kas samme saab vahele jätta, toimingut korrata või muuta teise konto kontekstis?
E-poe puhul võib ulatus hõlmata registreerumist, ostukorvi, tellimuse vaatamist ja tühistamist, kupongi kasutamist ning haldusvaadet. Pane kirja, millised kliendi- ja haldajarollid, domeenid ning keskkonnad on sees. API eraldi ulatuse juhendi leiad API turvatestimise juhendist.
Testimine on mõistlik enne avalikku käivitamist ning pärast olulist muudatust, näiteks uut sisselogimisviisi, maksevoogu, rollisüsteemi või suuremat versiooniuuendust. See ei asenda arenduse käigus tehtavat turvalist koodi- ja konfiguratsioonitööd.
Mille poolest erinevad XSS, SQL-süst ja CSRF?
- XSS (cross-site scripting) on olukord, kus rakendus lubab ebausaldusväärsel sisul muutuda kasutaja brauseris käivitatavaks skriptiks. Sisendi valideerimine, kontekstipõhine väljundi kodeerimine ja rakenduse käitumine vajavad eri kontrollpunkte.
- SQL-süst (SQL injection) tekib, kui ebausaldusväärne sisend mõjutab andmebaasipäringu struktuuri. Oluline on kontrollida sisendi käsitlemist ja päringu koostamist; pelgalt vormi piirangust brauseris ei piisa.
- CSRF (cross-site request forgery) puhul võib väline leht panna kasutaja brauseri saatma autentitud toimingu, mida kasutaja ei kavatsenud teha. See erineb XSS-ist ja nõuab rakenduse toimingute ning seansikaitse eraldi hindamist.
OWASP WSTG 4.2 sisendite testimise jaotis käsitleb XSS-i ja SQL-süsti; seansihalduse jaotis sisaldab CSRF-i. Need on riskide selgitused, mitte vaikimisi lubatud ründed ega kogu metoodika katmise lubadus. Kontrollid ja ohutud näidisandmed valitakse kirjaliku ulatuse järgi.
Ettevalmistuse kontrollnimekiri
Hea ulatus vähendab kõrvalmõjusid ning aitab kontrollida sinu ärile olulisi kasutusvooge. Enne töö algust leppige kirjalikult kokku siht, ajavahemik, lubatud tegevused, välistused ja kontaktisik katkestuse korral.
- Testkeskkond: võimalusel tootmisele sarnane testkeskkond, mille versioon ja domeenid on teada. Tootmise testimisel leppige eriti täpselt kokku piirid ja ohutu ajavahemik.
- Kontod ja rollid: looge testkontod tavakasutajale, teisele kasutajale ja vajadusel haldajale. Ärge saatke päris kasutajate paroole.
- Sünteetilised andmed: tehke näidistellimused. Maksevoogude jaoks kasutage makseteenuse testkeskkonda, mitte päris kaardinumbreid ega päris ostu.
- Isikuandmed: eemaldage või maskeerige mittevajalik pärisandmestik; määrake tundliku leiu turvalise jagamise viis.
- Piirid ja sõltuvused: nimetage välistatud domeenid, kolmandate osapoolte teenused, keelatud toimingud ning koormus- ja kättesaadavustestide piirangud. Teenust häirivat tegevust ei tehta vaikimisi.
- Taaste: määrake tehniline kontakt, varukoopia või taastamisplaan ning viis testimise peatamiseks.
Siht, mahud, ajakava, load ja kordustest kinnitatakse kirjalikult. Tallinnas tegutseva Tehisabiline OÜ teenust kirjeldab pentestimise leht; laiemat hindamist küberauditi ulatus.
Veebilehe skanner, pentest või audit?
| Meetod | Mida annab? | Mida üksi ei kata? |
|---|---|---|
| Veebiskanner | Automatiseeritud päringutega leiab osa tuntud mustritest, päise- ja konfiguratsiooniprobleemidest ning teadaolevatest nõrkustest. | Ei mõista usaldusväärselt ärireegleid ega tõenda kasutajatevaheliste piiride õigsust. Võib anda valehäireid või vigu märkamata jätta. |
| Autenditud pentest | Testija kasutab kokkulepitud kontosid ja kontrollib käsitsi rakenduse vooge, rollide eraldamist ja valitud tehnilisi riske. | Kehtib kokkulepitud ulatuse ja aja kohta; ei tõenda kõigi vigade puudumist. |
| Küberaudit | Laiem ülevaade kokkulepitud tehnilistest ja korralduslikest kontrollidest ning parandusprioriteetidest. | Ei tähenda kõigi süsteemide aktiivset ründetestimist; ulatus lepitakse eraldi kokku. |
Skanner sobib korduvaks esmakontrolliks; pentest lisab kasutajakonteksti ja inimese tõlgenduse. Küberaudit sobib, kui vajad rakendusest laiemat turvaseisu ja parandusplaani.
Ohutu näide: tellimuse vaatamine
Testkeskkonnas on kaks sünteetilist tavakasutajat, A ja B, kummalgi näidistellimus. Omaniku loaga testija logib sisse kontoga A ja kontrollib A enda tellimuse vaatamist. Seejärel kontrollib ta kokkulepitud mahus, kas A saab vaadata B näidistellimust.
Oodatud tulemus: server keeldub B tellimuse andmeid väljastamast, kuigi päring on autentitud. Tõendisse märgitakse roll, päring ja saladustest puhastatud vastus; päris isikuandmeid ei kopeerita. Kui ligipääs avaneb, peatatakse edasine andmete uurimine ja leid edastatakse kokkulepitud kontaktile. Ka haldustoimingute rollipiire kontrollitakse ainult kokkulepitud sünteetiliste objektidega.
Näide on väljamõeldud õiguste kontroll, mitte luba testida päris klientide andmeid, makseid või muid süsteeme. Ulatuseta katseid ei tehta.
Mida raportist ja kordustestist oodata?
Kasulik raport seob leiu mõjutatud voo ja riskiga, kirjeldab kontrollitud tingimusi ning annab paranduse soovituse. Olulised leiud vaatab üle inimene, kes hindab nende tegelikkust ja mõju; üks automaatne skannerihoiatus pole veel kinnitatud haavatavus. Pärast parandusi saab eraldi kokku leppida kordustesti, mis kontrollib konkreetsete leidude lahendamist.
Testi tulemus on aja- ja ulatuspiiranguga hinnang. See ei taga turvalisust ega hõlma automaatselt iga kasutaja, keskkonna, sõltuvuse või OWASP kontrolli täielikku katvust. Testi ulatus, hind, ajavahemik, load ja kordustest lepitakse kirjalikult kokku.
Allikad ja raamistik
OWASP Web Security Testing Guide 4.2 sissejuhatus selgitab ulatuse ja piirangute tähtsust ning seda, miks skannerist üksi ei piisa; WSTG 4.2 testikategooriad hõlmavad muu hulgas autentimist, autoriseerimist, seansse, sisendit, konfiguratsiooni ja äriloogikat. Juhend aitab planeerida kontrolle, kuid konkreetse töö ulatus määratakse eraldi ega tähenda automaatset täielikku WSTG vastavust.
Kas vajad rakenduse üldise turvatesti asemel API-spetsiifilist vaadet? Loe API turvatestimise juhendit. Teenuse ulatuse arutamiseks kirjuta [email protected] või tutvu Tehisabiline OÜ-ga.
Arutame sinu rakenduse ulatuse läbi
Kirjelda veebirakendust, kasutajarolle ja testkeskkonda. Lepime enne töö algust kirjalikult kokku sihi, loa ja piirid.
Võta ühendust