Insecure Design

Šta je nesigurni dizajn?

---

Nesigurni dizajn predstavlja nedostatak integracije sigurnosnih mehanizama tokom razvojnog procesa aplikacije. Razni spektar problema može da se javi kao posljedica slabog dizajna, koji ne uzima u obzir sigurnost. Neki od jednostavnijih problema mogu biti zanemarivanje vremena i novca koji je potrebno uložiti u razvijanje sigurne aplikacije, pa sve do nemarnog dizajna. Teži previdi mogu ostaviti aplikaciju nezaštićenu, sa mogućnošću kompromitovanja čitave aplikacije i otkrivanja podataka. Konkretni nedostaci, koje čine dizajn nesigurnim su: nedostatak validacije podataka, nedovoljna autentifikacija i autorizacija, nesiguran način skladištenja podataka, nesigurna komunikacija, nedostatak evidentiranja i praćena akcija u aplikaciji itd. Ova kategorija je nova u OWASP-ovoj listi Top 10 ranjivosti i uključena je 2021. Greške, koje su nastale u dizajniranju, zahtjevaju težak i skup proces popravke. U ovoj vrsti ranjivosti i kada je sve implementirano kako treba, ne dovodi do poboljšanja sigurnost jer je samo rješenje neadekvatno.

---

Opis problema (Neadekvatan dizajn Singl Sign-On mehanizma)

SSO (Single Sign-On) je mehanizam za autentifikaciju koji omogućava da se korisnik identifikuje na više aplikacija korištenjem jednog seta kredencijala. Kada se korisnik uloguje u jednu aplikaciju, automatski ima pristup i drugim povezanim aplikacijama bez potrebe da opet unosi kredencijale.

DocumentSystem se sastoji od dvije aplikacije, jedna služi za upravljanje dokumentima a druga za upravljanje korsnicima. Administrator sistema jedini ima pravo da pristupi obe aplikacije, dok administrator dokumenata i klijent imaju pravo samo da pristupe aplikaciji za upravljanje dokumenata. Da bi se olakšao rad administratoru sistema omogućen je Single Sign-On pristup aplikaciji za rad sa dokumentima i aplikaciji za rad sa klijentima. Način na koji je implementiran Single Sign-On odstupa od preporučene prakse i ima određene nedostatke. Napravljena je pomoćna web aplikacija čije local storage skladište je dijeljeno, tj. njemu imaju pristup aplikacija za upravljanje dokumentima i aplikacija za upravljanje klijentima, što je prikazano na Slici 1. Na Slici 2. i 3. prikazano je kako izgleda local storage od pomoćne aplikacije iz perspektive aplikacije za dokumente i aplikacije za rad sa klijentima, respektivno. Pomoćna aplikacija koristi port 4402, dok aplikacija za dokumente koristi port 4200 a aplikacija za rad sa klijentima 4401. U local storage-u pomoćne aplikacije se čuvaju informacije o korisniku i JWT tokenu, koje omogućavaju da se mogu nesmetano koristiti aplikacije i korisiti njeni servisi.

Slika 1.

Slika 2.

Slika 3.

Način funkcionisanja je sledeći, kada se administrator sistema prijavi na aplikaciju za dokumente ili se prijavi na aplikaciju za rad sa klijentima tada se u local storage pomoćne aplikacije upisuju informacije o administratoru sistema, tj. korisniku i JWT token. Na taj način ako administrator sistema hoće da koristi drugu aplikaciju na kojoj nije prijavljen može da joj pristupi bez ponovnog unosa kredencijala, jer će aplikacija vidjeti da se u dijeljenom local storag-u već nalaze informacije o korisniku i da je autentifikovan u povezanoj aplikaciji. Pošto je korišten local storage, nakon što se korisnik izloguje iz jedne od aplikacija potrebno je da se podaci obrišu ručno.

Implementacija Single Sign-On mehanizma bez kontaktiranja serverske strane, uvodi bezbjednosne rizike. Napadač može da izvrši krađu podataka koji se čuvaju na klijentskoj strani na više načina. Neki od njih su XSS (Cross-Site Scripting) napadi, maliciozne ekstenzije u pregledaču, fizički pristup uređaju, na osnovu pogrešnih bezbjednosnih konfiguracija itd.XSS napadi ubacuju maliciozne skripte u web aplikaciju i one mogu da pristupe i skladištu na korisničkoj strani, ukoliko je aplikacija podložna njima. Kada korisnik instalira malicioznu ekstenziju u pregledač, ona može imati pristup podacima skladištenim u local storage-u za bilo koju web stranicu kojoj korisnik pristupi. Ako se napadač nađe u blizini računara korisnika, moguće je da fizički dobije pristup podacima u local storag-u. Takođe, pogrešne bezbjednosne konfiguracije kao što je pretjerano popustljive CORS (Cross-Origin Resource Sharing) politike dijeljenja resursa sa više izvora, mogu izložiti podatke čuvane u lokalnom skladištu neovlaštenim domenima. Kada je napadač dobio JWT token koristeći neki od navedenih načina ima mogućnost da koristi endpointe koji pripadaju i aplikaciji za upravljanje dokumentima i aplikaciji za upravljanje klijentima. Prilikom opisa ranjivosti Broken Access Control u Problemu 2. navedeno je kako maliciozni korisnik može da šalje zahtjeve direktno na serversku stranu na odgovarajući endpoint koristeći JWT token u Postman aplikaciji.

Posljedice problema

Posljedice ovakvog načina implementacije Single Sign-On mehanizma jesu veća mogućnost krađe JWT tokena i podataka o korisniku, koji se nalaze u lokalnom skladištu pomoćne aplikacije. Nakon što je maliciozni korisnik ukrao JWT token administratora sistema, može da vrši sve aktivnosti koje je imao i administrator sistema unutar obe aplikacije.

Rješenja problema

Rješenje problema obuhvata različit način implementiranja Single Sign-On mehanizma, koji će uključivati i serversku stranu, a ne samo klijentsku. Rješenje koje će biti predstavljeno korisitće server za autentifikaciju kao mehanizam za izdavanje JWT tokena i vođenje računa o Single Sign-On-u. Potrebno je izabrati protokol za izvođenje SSO-a, neki od standardnih koji se često koriste su OAuth2 i OpenID.

OAuth2 (Open Authorization) je standardni dizajn koji omogućava pristup resursima host-ovanim od strane druge web aplikacije u ime korisnika. To je protokol za autorizaciju, a ne autentifikaciju. Kao takav, dizajniran je prvenstveno kao sredstvo za odobravanje pristupa skupu resursa, kao što su udaljeni API-ji ili korisnički podaci. Funkcioniše tako što koristi tokene za pristup, tj. Access tokene, koji predstavljaju ovlašćenje za pristup resursima u ime krajnjeg korisnika. OAuth2 nema defenisan format pristupnog tokena koji se koristi, ali često je u upotrebi JWT token. Na taj način izdavaocima tokena je omogućeno da uključe i podatke o korisniku u sam token. Preporučljivo je da tokeni za pristup imaju rok trajanja. OpenID Connect jeste sloj iznad oAuth2 protokola koji obezbjeđuje autentifikaciju. Omogućava third-party (trećih strana) aplikacijama da verifikuju identitet krajnjeg korisnika i da dobiju osnovne informacije o profilu korisnika. OIDC koristi JWT tokene. Njegova uloga je da obezbijedi jedan login za više web stranica.

Potrebno je postaviti centralizovani server za autentifikaciju, koji će se brinuti o autentifikaciji korisnika i izdavanju tokena. Neki od popularnijih koji se koriste su Keyclak, AuthO i Okta. Sa serverske strane potrebno je integrisati OAuth2 i OpenID Connect klijentske biblioteke da bi se mogla ostvariti komunikacija sa serverom za autentifikaciju. Sa frontend strane svaka od web aplikacija treba, takođe, da koristi odgovarajuće OAuth2 i OpenID Connect biblioteke. Kada korisnik pokušava da pristupi jednoj od aplikacija, biće redirektovani ka serveru za autentifikaciju. Nakon što se uspješno izvrši autentifikacija server za autentifikaciju izdaje token klijentu i dodijeljuje mu client id i client secret. Server koji se nalazi na backend-u validira token dobijen sa frontend-a, tako što komunicira sa autentifikacionim serverom. Poslije provjere i potvrde tokena, server za autentifikaciju obezbjeđuje korisničke podatke. Kada korisnik hoće da koristi drugu aplikaciju, zatražuje token za pristup autentifikacionom serveru (koji sada ima ulogu i autorizacionog servera). Klijent dostavlja client id i client secret za identifikaciju uz zahtjev i još traženi opseg i endpoint URI na koji treba posalti token za pristup. Server za autentifikaciju autentifikuje klijenta i provjerava da li ima tražena prava, koja su navedena u zahtjevu. Server sa resursima je u interakciji sa serverom za autentifikaciju da bi se odobrio pristup klijentu. Nakon toga, ako je sve uspješno prošlo, autentifikacioni server redirektovan je nazad ka klijentu i obezbjeđuje mu pristupni token. Sada sa tim tokenom klijent može da pristupi serveru na backend-u, koji posjeduje resurse.

Umjesto tokena za pristup autentifikacioni (autorizacioni) server može da izdaje takođe i autorizacione kodove ili refresh tokene. To zavisi od potreba aplikacija. Kada se koristi autorazicioni kod server za autentifikaciju vraća kod za jednu upotrebu, na osnovu kojeg se onda klijent dobija pristupni token. Sličnu logiku posjeduje i korištenje refresh tokena, gdje se na osnovu njih dobijaju pristupni tokeni.

Da bi se izbjegao nesiguran dizajn preporučuje se upotreba najboljih praksi tokom razvojnog ciklusa aplikacija. Odstupanja i samostalna implementacija već poznatih i provjerenih rješenja, može dovesti do mnogo propusta i bezbjednosnih rizika.