Web saugumo mechanizmai
Didžioji dauguma Web aplikacijų palaiko funkciškai panašius saugumo mechanizmus. Juos skirstyti siūloma į:
- Vartotojo teisių į programos duomenis ir funkcionalumą valdymas, siekiant apsaugoti nuo neautorizuotos prieigos.
- Vartotojo įvesties valdymas, siekiant užkirsti kelią specialiai žalingai suformuluotiems įvesties šablonams, kurie galėtų nepageidautinai paveikti sistemą.
- Tiesioginis reagavimas į atakas ar dažnus jų šablonus.
- Sistemos būsenos sekimas.
Vartotojo teisių valdymas
Vartotojo teisių valdymą paprastai sudaro autentifikacija, sesijų palaikymas ir prieigos kontrolės. Šie trys komponentai sudaro fundamentalų bendro Web aplikacijos
saugumo pamatą.
Autentifikacija Web aplikacijai suteikia pasitikėjimo faktorių, paprastai tokiu būdu vartotojui, sistemoje įrodančiam savo tapatybę yra priskiriamos papildomos teisės. Tradiciškai daugelyje Web aplikacijų naudojamas vartotojo vardo ir slaptažodžio autentifikacijos modelis. Sistemos, reikalaujančios didesnio saugumo lygio, neretai naudoja papildomus laukelius ir daugiapakopes autentifikacijas (multistage login). Reikėtų atkreipti dėmesį, kad autentifikacijos sistemos dažnai palaiko papildomas funkcijas, tokias kaip automatinė registracija, slaptažodžio keitimas/atkūrimas, paskyros atstatymas. Šiose funkcijose neretai pasitaiko įvairių pažeidžiamumų. Paprastam pavyzdžiui pateikti siūloma atkreipti dėmesį į 2012 m. lapkričio mėnesį paviešintą populiarios pokalbių tarnybos Skype pažeidžiamumą[1]. Pažeidžiamumo šaknys glūdėjo būtent slaptažodžio atkūrimo funkcijoje, kurią išnaudoti galėdavo bet kuris, žinantis prie jau priregistruoto Skype vartotojo paskyros susietą elektroninio pašto adresą.
Kitas žingsnis įvykdžius autentifikaciją reikalauja nuoseklaus vartotojo prieigos valdymo. Šioje pakopoje naudojami sesijų valdymo mechanizmai, leidžiantys sistemai identifikuoti jau autentifikuotus vartotojus. Tradiciškai kiekvienas vartotojas iš Web aplikacijos gauna savo privačią sesiją, kuriai identifikuoti naudojamas prieigos raktas (session token). Sesijų saugumas yra stipriai susietas su prieigos rakto saugumu, kuris turi būti unikalus, saugiai sugeneruotas bei perduodamas.
Prieigos kontrolė valdo konkrečių vartotojų ar jų grupių teises pasiekti nustatytus resursus. Dėl sudėtingų prieigos kontrolės mechanizmų šio komponento spragos neretai kyla iš neapgalvotų prielaidų apie galimus vartotojų veiksmus ir yra išnaudojamos norint gauti priėjimą prie apsaugotos informacijos.
Įvesties valdymas
Didžioji dalis Web aplikacijų pažeidžiamumų išnaudojama žalingai formuluojant įvestį. Tokiu atveju siekiama pakreipti aplikacijos veikimą nelaukta kryptimi. Vienas pagrindinių Web aplikacijos saugumo uždavinių yra saugus įvesties apdorojimas (input validation). Įvesties pažeidžiamumai Web aplikacijoje gali slėptis visur, todėl šiai užduočiai derėtų skirti ypač daug dėmesio.
Neretai programuotojai kreipia dėmesį tik į akivaizdžius naršyklėje vartotojo pateikiamus įvesties duomenis, ignoruodami subtilesnes vietas, tokias kaip sausainėliuose (cookies) esanti informacija; paslėpti HTML formų laukai, kurių vartotojas plika akimi paprastai nemato, bet gali modifikuoti; HTTP antraštės (aplikacijos dažnai apdoroja „Referer“ ir „User-Agent“ antraštes) ir pan. Žalingos įvesties blokavimo technikos kartais gali būti apeinamos naudojant tam tikras įvesties variacijas.
Pavyzdžiui, „<scr<script>ipt>“ nerekursyvaus filtro atveju siekiant išnaudoti XSS pažeidžiamumus, taip pat NULL byte atakos[2], URL koduočių naudojimas ir t.t. Tokiu
atveju yra išnaudojami apsauginių mechanizmų pažeidžiamumai.
Įvesties apdorojimui paprastai naudojama apvalymo technika (sanitization) užtikrinanti, kad potencialiai žalinga įvestis būtų pakeista ar atitinkamai perkoduojama prieš ją apdorojant. Pavyzdžiui, prieš apdorojant vartotojo įvestą HTML kodą, HTML gairės yra perkoduojamos specialia koduote, kad vėliau saugiai galėtų būti atvaizduojamos. Taip tradiciškai saugojamasi nuo XSS (Cross-Site Scripting) atakų.
Į įvesties saugumo problemą dažnai siūloma žiūrėti naudojant „pasitikėjimo ribos“ modelį (trust boundary)[3]. Šiame modelyje išskiriami konkretūs programos etapai, kuriuose pakinta duomenų ar programos vykdymo pasitikėjimo lygis. Duomenų pasitikėjimo riba yra etapas, kuriame duomenys sistemą pasiekia iš galimai nepatikimo šaltinio. Pasitikėjimo ribos pažeidimas paprastai nurodo pažeidžiamumą, kurio metu programa pasitiki ir laisvai naudoja prieš tai pro pasitikėjimo ribą praėjusius nepatikrintus duomenis. Taikant šį modelį, kiekvienas Web aplikacijos komponentas privalo patikrinti gaunamą įvestį, darydamas prielaidą apie jos potencialią žalą. Kandidatai į tokius komponentus gali būti: autentifikacijos sistema, apdorojanti vartotojo prisijungimo duomenis; DB sąveikos modulis, gaunantis dinamiškas SQL užklausas; SOAP/XML komunikacijos servisai; sesijų palaikymo mechanizmas apdorojantis sausainėlius ir pan.
Reagavimas į atakas
Kuriant bei administruojant Web sistemą labai svarbu atitinkamai reaguoti į galimas jos atakas. Aplikacijos veikime iškilusios nenumatytos klaidos gali būti pirmas perspėjimas apie galimą ataką ar su ja susijusius ketinimus. Suinteresuoti asmenys dažnai specialiai siekia iššaukti šias klaidas sistemose, norėdami gauti daugiau informacijos apie galimus pažeidžiamumus. Būtent dėl to labai svarbu, reaguojant į tokias klaidas, pateikti kuo mažiau konkrečios informacijos vartotojui. Kartais pasitaiko atvejų, kuomet programuotojai tiesiog pamiršta išjungti Web karkasų (Web Frameworks) ar bibliotekų derinimo rėžimą (debugging mode), kurio metu iškilus nenumatytoms klaidoms, paprastai pateikiama kuo daugiau informacijos apie sistemą, dažnai net interaktyviai. Efektyvus reagavimas į klaidas dažniausiai veikia kartu su aplikacijos žurnalo mechanizmu (logging) siekiant informuoti administratorius apie šiuos įvykius. Be viso to, aplikacijoms, kurių saugumas yra kritiškai svarbus, į žurnalus siūloma registruoti kuo daugiau papildomos informacijos, susijusios su svarbiais moduliais (autentifikacija, finansų valdymas, minėtų saugumo mechanizmų veikla ir t.t). Šie žurnalai privalo būti apsaugoti ir jokiu būdu nepaviešinti. Kai kuriose sistemose pagal nustatytas taisykles administratoriai apie kritines klaidas ar anomalijas yra įspėjami automatiškai. Tam tikri įspėjimai gali būti gaunami ir iš kitų sistemų, pvz. IDS, ugniasienių. Rezultate gali būti įgyvendinami tiesioginiai reagavimų į atakas mechanizmai, pvz. blokuojami užpuolikų adresai, naudojami laiko limitai prieigai prie kritinių sistemos modulių. Efektyviam reagavimui į atakas užtikrinti šie mechanizmai turėtų būti įgyvendinami ir pačioje Web aplikacijoje.
Sistemos būsenos sekimas
Beveik kiekviena Web sistema turi būti valdoma bei administruojama. Dažniausiai šį funkcionalumą savo ruožtu įgyvendina pati Web aplikacija, leisdama administratoriams valdyti vidinius sistemos duomenis, atlikti diagnostiką bei keisti svarbius nustatymus. Atsakingas administratorius turėtų reguliariai stebėti sistemą ir išaiškinti visas galimai su neautorizuota veikla susijusias anomalijas bei jų priežastis. Įtartini ar neteisingai suformuluoti įrašai duomenų bazėje, naujos vartotojų paskyros, pakeistos prieigos teisės gali būti rimtas įspėjimas apie su įsilaužimu į sistemą susijusius veiksmus. Vertėtų paminėti, kad būtent administraciniame sistemos modulyje neretai randama įvairių kritinių pažeidžiamumų, suteikiančių aukštesnes privilegijas („privilege escalation“[4] tipo pažeidžiamumai).