Bezbednost custom CMS-a: autentikacija, autorizacija i hardening

Bezbedan custom CMS mora da odgovori na tri odvojena pitanja: ko je korisnik, šta taj korisnik sme da radi i kako se sistem štiti kada aplikacija, nalog ili infrastruktura dođu pod pritisak. Zato login stranica sama po sebi nije bezbednosna strategija.

Praktična procena bezbednosti custom CMS-a obuhvata autentikaciju, upravljanje sesijama, autorizaciju po resursu i akciji, validaciju podataka, zaštitu administratorskog interfejsa, bezbedno rukovanje fajlovima, logovanje i hardening produkcionog okruženja. Ove odluke treba doneti tokom modelovanja sistema, a ne tek pred objavljivanje sajta. Ako razmatrate širu arhitekturu i način izrade, custom CMS rešenje treba posmatrati kao kombinaciju poslovnih pravila, uredničkog procesa i bezbednosnih kontrola.

Autentikacija: dokazivanje identiteta korisnika

Autentikacija potvrđuje da je osoba zaista vlasnik naloga. U CMS-u se najčešće odnosi na prijavu korisničkim imenom ili e-mail adresom i lozinkom, ali može uključiti i federisani login, jednokratne kodove ili višefaktorsku autentikaciju.

Lozinke i pokušaji prijave

• Lozinke se ne čuvaju kao čist tekst, već kao neobrnuti hash uz odgovarajuću, savremenu password-hashing strategiju.
• Poruke o grešci ne bi trebalo da otkrivaju da li određeni e-mail postoji u sistemu.
• Potrebno je ograničiti učestale neuspešne pokušaje prijave i pratiti neuobičajene obrasce.
• Promena lozinke, reset naloga i promena privilegija zahtevaju dodatnu proveru i pažljivo upravljanje sesijama.

Ograničavanje pokušaja ne znači nužno jednu fiksnu granicu koja važi za sve situacije. Implementacija treba da uzme u obzir korisničko iskustvo, rizik od automatizovanih pokušaja i mogućnost da napadač zloupotrebi mehanizam za uskraćivanje pristupa legitimnom korisniku.

Višefaktorska autentikacija i administratorski nalozi

Administratorski i drugi privilegovani nalozi imaju veći uticaj na sadržaj, korisnike i konfiguraciju, pa zaslužuju strožiji nivo zaštite. MFA može biti naročito važan za takve naloge, kao i za CMS koji obrađuje osetljive podatke ili omogućava objavljivanje sadržaja bez dodatne kontrole.

Prilikom uvođenja MFA treba definisati šta se dešava kada korisnik izgubi drugi faktor, ko može da pokrene oporavak naloga i kako se taj događaj proverava. Rezervni kodovi i proces oporavka ne smeju postati slabija zamena za osnovnu autentikaciju.

Sesije: šta se dešava posle uspešnog logina

Posle prijave aplikacija mora bezbedno da poveže naredne zahteve sa korisničkim nalogom. To podrazumeva pažljivo upravljanje session tokenima i kolačićima, a ne samo proveru da li je korisnik jednom uneo ispravnu lozinku.

• Sesija treba da bude zaštićena od pristupa kroz klijentski JavaScript kada za to nema opravdanja, kao i od slanja preko nebezbedne veze.
• Trajanje sesije treba uskladiti sa rizikom i vrstom naloga. Dugotrajna sesija može biti praktična, ali povećava posledice ukradenog tokena.
• Odjava, promena lozinke i neke promene privilegija treba da mogu da invalidiraju postojeće sesije.
• Posle uspešne prijave potrebno je sprečiti zamenu identiteta sesije, odnosno session fixation scenarije.

Detalji zavise od tehnologije i načina na koji je CMS izgrađen. Zato se pravila za sesije ne smeju kopirati mehanički iz drugog projekta bez provere ponašanja frameworka, reverse proxy-ja i autentikacionog sloja.

Autorizacija: šta korisnik sme da vidi i menja

Autorizacija dolazi posle autentikacije. Ona odlučuje da li konkretan korisnik ima pravo da izvrši konkretnu radnju nad konkretnim resursom. U custom CMS-u nije dovoljno proveriti samo da li je neko ulogovan ili da li pripada grupi „editor“.

Provera uloge nije dovoljna

Primer: urednik može da menja članke u jednoj sekciji, ali ne i korisničke naloge, sistemsku konfiguraciju ili sadržaj druge organizacione jedinice. Zbog toga provera mora da obuhvati najmanje:

• identitet korisnika;
• ulogu ili skup dozvola;
• resurs nad kojim se radi;
• konkretnu akciju, kao što su čitanje, kreiranje, izmena, slanje na review, objavljivanje ili brisanje;
• kontekst, na primer pripadnost brendu, jeziku, timu ili organizacionoj jedinici.

Dozvolu treba proveravati na serverskoj strani za svaki relevantan zahtev. Sakrivanje dugmeta u administratorskom interfejsu poboljšava iskustvo, ali nije zamena za serversku kontrolu: korisnik može direktno poslati zahtev ka endpointu.

Za detaljniji model uloga pogledajte vodič Uloge i dozvole u CMS-u: kako organizovati editor, reviewer i administrator pristup. Bezbednost ovde zavisi od toga da li su dozvole vezane za stvarne poslovne odgovornosti, a ne samo za nekoliko širokih naziva rola.

Editorial workflow kao bezbednosna kontrola

Workflow draft–review–approval nije samo organizaciona pogodnost. On može da smanji rizik od nenamerne objave netačnog, neproverenog ili kompromitovanog sadržaja. Na primer, editor može da pripremi promenu, reviewer da je proveri, a samo određena uloga da je objavi.

Takav proces ima smisla samo ako se kontrole primenjuju na serverskoj strani i ako se beleži ko je izvršio promenu. Više o tome kako se statusi i odgovornosti modeluju nalazi se u tekstu Editorial workflow: draft, review i approval u custom CMS-u.

Validacija podataka i zaštita poslovne logike

Svi podaci koji stižu od korisnika, browsera, API klijenta ili spoljnog servisa treba da se tretiraju kao nepouzdani dok se ne provere. Validacija nije samo provera tipa polja u browseru. Serverska strana mora da proveri format, dužinu, dozvoljene vrednosti, odnose između polja i pravo korisnika da taj podatak menja.

• Strukturna validacija: da li je vrednost očekivanog tipa i formata.
• Ograničenja: maksimalna dužina teksta, dozvoljeni statusi, opseg brojeva i veličina zahteva.
• Kontekstualno prikazivanje: korisnički tekst treba pravilno obraditi kada se prikazuje u HTML-u, atributu, URL-u ili drugom izlaznom kontekstu.
• Poslovna pravila: validno polje ne znači automatski da je dozvoljena i sama operacija.

Posebnu pažnju zahtevaju rich-text editori, HTML sadržaj i uvoz podataka. Ako CMS dozvoljava formatiranje, treba definisati dozvoljene elemente i atribute, a ne prepustiti sanitizaciju slučajnom ponašanju browsera ili plugina.

Model podataka utiče i na bezbednost: jasna struktura olakšava kontrolu vlasništva, statusa i dozvola nad sadržajem. Zato je korisno prvo razraditi content model u custom CMS-u, pre nego što se krenе u izradu formi i administratorskih ekrana.

Fajlovi, medija biblioteka i importi

Upload fajlova je čest izvor rizika jer povezuje korisnički unos, skladištenje i često javno prikazivanje sadržaja. Bezbedniji dizajn ne oslanja se samo na ekstenziju fajla koju je poslao browser.

• Ograničite dozvoljene tipove, veličinu i broj fajlova.
• Proverite sadržaj i format fajla na serverskoj strani.
• Razmotrite skladištenje izvan izvršnog web prostora i korišćenje nasumičnih imena.
• Definišite ko može da otprema, menja, briše i javno objavljuje fajlove.
• Za dokumente i slike razdvojite pravo pristupa mediji biblioteci od prava javnog prikaza.

CSV, XML, JSON i drugi importi takođe zahtevaju ograničenja veličine, validaciju strukture i kontrolu dozvola. Import koji je dozvoljen administratoru ne mora biti dostupan editoru.

Hardening aplikacije i produkcionog okruženja

Hardening je smanjivanje nepotrebne izloženosti sistema. Obuhvata aplikaciju, server, bazu, mrežu, deployment proces i administratorske uređaje. Nije jednokratan korak, već skup provera koje se ponavljaju kada se menjaju zavisnosti, konfiguracija ili infrastruktura.

Aplikacioni i HTTP sloj

• Produkcija ne treba da prikazuje detaljne stack trace poruke, tajne ključeve ili interne putanje korisniku.
• Administratorski endpointi treba da budu iza odgovarajuće autentikacije i autorizacije, uz HTTPS.
• Bezbednosni HTTP headeri treba da budu podešeni u skladu sa aplikacijom, uključujući pravila za učitavanje resursa i ponašanje browsera.
• CSRF zaštita je relevantna za state-changing zahteve koji koriste browser sesiju.
• CORS pravila treba ograničiti na stvarno potrebne origin-e, metode i zaglavlja.
• Zavisnosti, framework i CMS komponente treba držati pod kontrolom kroz zaključane verzije, pregled izmena i plan ažuriranja.

Preterano restriktivna konfiguracija može pokvariti legitimne integracije, dok preširoka pravila povećavaju napadnu površinu. Zbog toga svaki header i mrežno pravilo treba testirati u realnom deployment okruženju.

Baza, tajne i infrastruktura

• Aplikacioni nalog baze treba da ima samo dozvole koje su mu potrebne.
• Lozinke, API ključevi i tokeni ne treba da budu u repozitorijumu ili javnom frontend kodu.
• Backup mora biti zaštićen, testiran kroz kontrolisani restore i obuhvaćen pravilima pristupa.
• Administrativni pristup serveru treba ograničiti i evidentirati, a nepotrebne servise i portove ukloniti ili zatvoriti.
• Deployment treba da bude ponovljiv, sa jasnim razlikama između development, staging i production okruženja.

Hardening nije zamena za bezbedan kod. Zaključan server neće sprečiti korisnika sa preširokom dozvolom da obriše sadržaj, niti će rešiti propust u kontroli pristupa.

Logovi, monitoring i reagovanje

CMS treba da beleži događaje koji su važni za istragu i upravljanje: neuspešne i neuobičajene prijave, promene uloga, reset lozinke, objavljivanje, brisanje, promene konfiguracije i pristup osetljivim podacima. Log treba da sadrži dovoljno konteksta za razumevanje događaja, ali ne i lozinke, session tokene ili nepotrebne lične podatke.

Definišite ko pregleda alarme, koliko dugo se logovi čuvaju i šta se radi kada se uoči sumnjiva aktivnost. Bez plana reagovanja, logovanje često ostane samo skladište poruka koje niko ne proverava.

Kako proveriti bezbednost pre objave

Pre produkcije napravite kontrolnu listu zasnovanu na riziku, a ne samo na vizuelnom pregledu login ekrana:

1. Testirajte matrica uloga: svaki tip korisnika treba da može samo dozvoljene akcije nad dozvoljenim resursima.
2. Proverite direktne API zahteve, ne samo ponašanje interfejsa.
3. Prođite kroz reset lozinke, odjavu, istek sesije, promenu uloge i deaktivaciju naloga.
4. Testirajte validaciju, rich text, upload i import sa nevalidnim i graničnim vrednostima.
5. Pregledajte produkcione tajne, error poruke, HTTPS, backup i administratorske pristupe.
6. Dokumentujte poznate rizike, preostale izuzetke i odgovornu osobu za ažuriranja.

OWASP ASVS može poslužiti kao referentni okvir za proveru kontrola, dok njihove praktične cheat sheet smernice pomažu pri detaljima autentikacije, autorizacije, sesija, validacije i upload funkcionalnosti. Nije potrebno slepo kopirati jednu listu: zahteve treba prilagoditi podacima, korisnicima i poslovnim posledicama konkretnog CMS-a.

Šta je dobar bezbednosni zahtev za custom CMS?

Dobar zahtev je proverljiv. Umesto „CMS mora biti bezbedan“, napišite: „editor ne može da objavi sadržaj bez odobrenja reviewera“, „deaktiviran korisnik ne može da koristi postojeću sesiju“ ili „upload prihvata samo definisane tipove i veličine, uz serversku proveru“. Takve formulacije povezuju poslovnu odluku sa implementacijom i testom.

Ako je projekat deo šire izrade sajta, bezbednosne zahteve treba uključiti u specifikaciju, procenu obima i plan održavanja. Sledeći korak nije dodavanje još jedne zaštite nasumično, već mapiranje korisničkih uloga, resursa, tokova objave i najskupljih mogućih grešaka. Tek tada se može odlučiti koje kontrole moraju biti ugrađene u sam CMS, a koje pripadaju infrastrukturi i operativnom procesu.