Žiniatinklio programos yra organizacijos langas į pasaulį: e. parduotuvės, klientų savitarnos, vidinės sistemos ir programėlių API pasiekiamos iš interneto, dažnai bet kuriam norinčiam. Todėl jos yra vienas dažniausių atakų taikinių. Didžioji dalis žiniatinklio pažeidžiamumų kartojasi metai iš metų, nes kyla iš tų pačių projektavimo ir programavimo klaidų. Šioje temoje susipažinsime su OWASP Top 10, kuris apibendrina svarbiausias žiniatinklio programų rizikas, ir su principais, padedančiais jų išvengti.
Kas yra OWASP Top 10
OWASP (angl. Open Worldwide Application Security Project) yra ne pelno bendruomenė, kurianti nemokamus programų saugumo standartus, įrankius ir mokymo medžiagą. Žinomiausias jos darbas yra OWASP Top 10: dažniausiai pasitaikančių ir pavojingiausių žiniatinklio programų rizikų sąrašas, atnaujinamas maždaug kas trejus ketverius metus pagal realius duomenis iš tūkstančių programų ir saugumo specialistų apklausas.
Naujausia, 2025 m., sąrašo versija apima šias kategorijas:
Netinkama prieigos kontrolė
Saugumo konfigūracijos klaidos
Programinės įrangos tiekimo grandinės spragos
Kriptografijos klaidos
Injekcijos
Nesaugus projektavimas
Autentifikacijos klaidos
Programinės įrangos ar duomenų vientisumo pažeidimai
Saugumo registravimo ir įspėjimų trūkumai
Netinkamas išimtinių situacijų valdymas
OWASP Top 10 nėra išsamus standartas, o informavimo dokumentas: jis parodo, kur dažniausiai klystama. Išsamesniam programų patikrinimui OWASP siūlo ASVS (angl. Application Security Verification Standard) standartą. Aptarkime svarbiausias kategorijas.
Netinkama prieigos kontrolė
Ši kategorija jau kelerius metus yra sąrašo viršuje. Ji apima atvejus, kai naudotojas gali pasiekti duomenis ar funkcijas, kurių neturėtų. Klasikinis pavyzdys: prisijungęs klientas mato savo sąskaitą adresu, kuriame yra jos numeris, ir, pakeitęs numerį, pamato kito kliento sąskaitą. Tokia spraga vadinama nesaugia tiesiogine objekto nuoroda (angl. IDOR). Kiti pavyzdžiai yra administravimo puslapiai, kurie tik paslėpti nuo meniu, bet neapsaugoti, ir API, kuris tikrina, ar naudotojas prisijungęs, bet netikrina, ar jam leidžiama atlikti konkretų veiksmą.
Apsauga: prieigos teisės visada tikrinamos serverio pusėje kiekvienai užklausai, numatytai viskas draudžiama, o leidžiama tik tai, kas aiškiai suteikta. Naršyklėje paslėptas mygtukas nėra apsauga, nes užklausą galima išsiųsti ir be jo.
Injekcijos
Injekcija įvyksta, kai naudotojo įvesti duomenys perduodami interpretatoriui, pavyzdžiui, duomenų bazei ar operacinei sistemai, ir interpretuojami kaip komanda. Žinomiausia rūšis yra SQL injekcija: jei programa užklausą duomenų bazei sudaro tiesiog sujungdama tekstą su naudotojo įvestimi, specialiai suformuota įvestis gali pakeisti užklausos logiką ir atskleisti ar sugadinti duomenis.
Į šią kategoriją taip pat patenka XSS (angl. Cross-Site Scripting): kai programa naudotojo įvestį be apdorojimo įterpia į puslapį, kitų lankytojų naršyklėse gali būti įvykdytas užpuoliko kodas, pavyzdžiui, pavagiantis jų sesijas.
Apsauga yra aiški ir patikrinta: duomenų bazės užklausoms naudojamos parametrizuotos užklausos, kurios griežtai atskiria komandą nuo duomenų, išvedami duomenys koduojami pagal kontekstą, o šiuolaikinės sistemos dažnai tai daro automatiškai. Papildomai taikoma įvesties patikra ir turinio saugumo politika (angl. Content Security Policy), ribojanti, kokius scenarijus naršyklė gali vykdyti.
Saugumo konfigūracijos klaidos
Net saugiai parašyta programa gali tapti pažeidžiama dėl netinkamų nustatymų: paliktų numatytųjų slaptažodžių, įjungto derinimo režimo, kuris klaidos atveju parodo vidinę informaciją, nereikalingų funkcijų, trūkstamų saugumo antraščių ar viešai prieinamų debesijos saugyklų. Apsauga yra standartizuotas, automatizuotas ir pakartojamas diegimo procesas su sustiprinta konfigūracija bei reguliarus jos tikrinimas.
Programinės įrangos tiekimo grandinės spragos
Šiuolaikinės programos didžiąja dalimi sudarytos iš trečiųjų šalių bibliotekų ir komponentų. Jei viename jų randamas pažeidžiamumas arba jis tyčia užkrečiamas, pažeidžiamos tampa visos jį naudojančios programos. 2021 m. „Log4j“ bibliotekos pažeidžiamumas, vadinamas „Log4Shell“, palietė milijonus sistemų būtent dėl to, kad ši biblioteka buvo naudojama beveik visur.
Apsauga: organizacija turi žinoti, kokius komponentus naudoja. Tam sudaromas programinės įrangos komponentų sąrašas (angl. Software Bill of Materials, SBOM), o priklausomybių analizės (angl. Software Composition Analysis, SCA) įrankiai automatiškai praneša apie pažeidžiamas versijas. Komponentai imami tik iš patikimų šaltinių, o jų atnaujinimas yra nuolatinis procesas.
Kriptografijos ir autentifikacijos klaidos
Kriptografijos klaidos apima jautrių duomenų perdavimą be šifravimo, pasenusius algoritmus ir slaptažodžių saugojimą netinkamu būdu. Slaptažodžiams saugoti naudojamos specialiai tam sukurtos lėtos maišos funkcijos, tokios kaip bcrypt ar Argon2, o ne bendrosios paskirties algoritmai.
Autentifikacijos klaidos apima silpnų slaptažodžių leidimą, apsaugos nuo slaptažodžių spėjimo trūkumą, netinkamą sesijų valdymą, pavyzdžiui, sesijos, kuri nepasibaigia atsijungus, ir kelių veiksnių autentifikacijos nebuvimą.
Nesaugus projektavimas
Ši kategorija primena, kad ne visos spragos atsiranda programuojant. Kai kurios įdiegiamos dar projektavimo etape: pavyzdžiui, slaptažodžio atkūrimo procesas, pasikliaujantis atsakymais į lengvai sužinomus klausimus, arba e. parduotuvė, neribojanti, kiek kartų galima pritaikyti nuolaidos kodą. Tokių klaidų negalima ištaisyti vien geresniu kodu. Apsauga yra grėsmių modeliavimas ir saugumo reikalavimai jau projektuojant.
Registravimas ir išimtinių situacijų valdymas
Jei programa neregistruoja prisijungimų, prieigos klaidų ir svarbių veiksmų, ataka gali vykti mėnesius, ir niekas jos nepastebės. Žurnalai turi būti siunčiami į centrinę sistemą, o kritiniai įvykiai turi kelti įspėjimus.
Paskutinė kategorija apima atvejus, kai programa netinkamai elgiasi įvykus klaidai: parodo naudotojui vidinę informaciją, pavyzdžiui, duomenų bazės struktūrą, arba klaidos atveju „atsidaro“ ir praleidžia užklausą be patikros. Saugus principas yra saugus gedimas (angl. fail securely): klaidos atveju veiksmas atmetamas, o naudotojui rodomas bendras pranešimas.
Saugus programinės įrangos kūrimas
Saugumas veiksmingiausias tada, kai integruojamas į visą programinės įrangos kūrimo ciklą, o ne tikrinamas tik prieš paleidimą. Šis požiūris vadinamas saugumo perkėlimu į pradžią (angl. shift left), o jį įgyvendinantis procesas dažnai vadinamas DevSecOps.
Praktikoje naudojami keli automatizuoto tikrinimo tipai. SAST (statinė analizė) tikrina programos kodą neįvykdžius jo. DAST (dinaminė analizė) testuoja veikiančią programą iš išorės, kaip tai darytų užpuolikas. SCA tikrina trečiųjų šalių komponentus. Taip pat naudojami slaptų duomenų skeneriai, kurie aptinka į kodą per klaidą įrašytus slaptažodžius ir API raktus. Automatizuotus įrankius papildo kodo peržiūros ir periodiniai skverbties testai.
Iš interneto pasiekiamas programas papildomai saugo žiniatinklio programų ugniasienė (angl. Web Application Firewall, WAF), kuri filtruoja žinomus atakų šablonus. Tačiau WAF yra papildomas sluoksnis, o ne pakaitalas saugiam kodui.
Svarbiausios temos išvados
OWASP Top 10 apibendrina dažniausias žiniatinklio programų rizikas, o 2025 m. versijos viršuje yra netinkama prieigos kontrolė, saugumo konfigūracijos klaidos ir tiekimo grandinės spragos. Prieigos teisės tikrinamos serverio pusėje kiekvienai užklausai, injekcijos sustabdomos parametrizuotomis užklausomis ir išvesties kodavimu, o tiekimo grandinę padeda valdyti SBOM ir SCA. Kai kurios spragos atsiranda dar projektuojant, todėl reikalingas grėsmių modeliavimas. Saugumas veiksmingiausias, kai integruojamas į visą kūrimo ciklą su SAST, DAST ir SCA tikrinimu. Kitoje temoje nagrinėsime, kaip organizacijos sistemingai valdo pažeidžiamumus.
Savikontrolės klausimai
1. Kodėl administravimo mygtuko paslėpimas naršyklėje nėra prieigos kontrolė?
2. Kodėl parametrizuotos užklausos apsaugo nuo SQL injekcijos?
3. Kokią pamoką apie tiekimo grandinės riziką suteikė „Log4Shell“ atvejis ir kaip SBOM padeda ją valdyti?
4. Kodėl nesaugaus projektavimo klaidų neįmanoma ištaisyti vien geresniu kodu?
5. Kuo skiriasi SAST ir DAST tikrinimas ir kodėl jie naudojami kartu?
Visos pamokos
