Prije otprilike godinu dana, mi u DataLineu pokrenuli smo za pretraživanje i analizu ranjivosti u IT aplikacijama. Usluga se temelji na Qualys cloud rješenju o čijem radu . Tijekom godinu dana rada s rješenjem proveli smo 291 skeniranje različitih stranica i prikupili statistiku o uobičajenim ranjivostima u web aplikacijama.
U članku u nastavku pokazat ću vam koje se točno rupe u sigurnosti web stranice kriju iza različitih razina kritičnosti. Pogledajmo koje je ranjivosti skener posebno često pronalazio, zašto bi se mogle pojaviti i kako se zaštititi.
Qualys sve ranjivosti web aplikacija dijeli na tri razine kritičnosti: nisku, srednju i visoku. Ako pogledate raspodjelu po "težini", čini se da sve nije tako loše. Malo je ranjivosti s visokom razinom kritičnosti, uglavnom sve nisu kritične:
Ali nekritično ne znači i bezopasno. Također mogu uzrokovati ozbiljne štete.
Glavne "nekritične" ranjivosti
- Ranjivosti mješovitog sadržaja.
Standard za sigurnost web stranice je prijenos podataka između klijenta i poslužitelja putem HTTPS protokola, koji podržava enkripciju i štiti informacije od presretanja.
Neke stranice koriste mješoviti sadržaj: Neki podaci se prenose preko nesigurnog HTTP protokola. Tako se najčešće prenosi pasivni sadržaj – informacije koje utječu samo na prikaz stranice: slike, css stilovi. Ali ponekad se tako prenosi aktivni sadržaj: skripte koje kontroliraju ponašanje stranice. U ovom slučaju, pomoću posebnog softvera, možete analizirati informacije s aktivnim sadržajem koji dolaze s poslužitelja, modificirati svoje odgovore u hodu i učiniti da stroj radi na način koji nisu zamislili njegovi kreatori.
Novije verzije preglednika upozoravaju korisnike da stranice s mješovitim sadržajem nisu sigurne i blokiraju sadržaj. Programeri web stranica također primaju upozorenja preglednika u konzoli. Na primjer, ovako to izgleda u :
Zašto je opasno?: Napadači koriste nesiguran protokol za presretanje korisničkih podataka, zamjenu skripti i slanje zahtjeva stranici u njegovo ime. Čak i ako posjetitelj stranice nije unio podatke, to ga ne štiti od phishing – dobivanje povjerljivih informacija korištenjem prijevarnih metoda. Na primjer, pomoću skripte možete preusmjeriti korisnika na nesigurno mjesto koje se maskira kao ono poznato korisniku. U nekim slučajevima zlonamjerna stranica izgleda čak i bolje od originala, a korisnik može sam ispuniti obrazac i poslati povjerljive podatke.Što bi web programer trebao zapamtiti: Čak i ako je administrator stranice instalirao i konfigurirao SSL/TLS certifikat, ranjivost može nastati zbog ljudske pogreške. Na primjer, ako na jednoj od stranica niste stavili relativnu vezu, već apsolutnu vezu s http-a, a uz to niste postavili preusmjeravanja s http na https.
Mješoviti sadržaj na web mjestu možete otkriti pomoću preglednika: pretražite izvorni kod stranice, pročitajte obavijesti na konzoli za razvojne programere. Međutim, programer će se morati petljati s kodom dugo i zamorno. Možete ubrzati proces pomoću automatiziranih alata za analizu, na primjer: , besplatni Lighthouse softver ili plaćeni softver Screaming Frog SEO Spider.
Također, ranjivost može nastati zbog problema s naslijeđenim kodom - kodom koji je naslijeđen. Na primjer, ako su neke stranice generirane pomoću starog predloška, koji ne uzima u obzir prijelaz web stranica na https.
- Kolačići bez oznaka "HTTPOnly" i "secure".
Atribut "HTTPOnly" štiti kolačiće od obrade skriptama koje napadači koriste za krađu korisničkih podataka. Oznaka "sigurno" ne dopušta slanje kolačića u čistom tekstu. Komunikacija će biti dopuštena samo ako se za slanje kolačića koristi sigurni HTTPS protokol.
Oba atributa navedena su u svojstvima kolačića:
Set-Cookie: Secure; HttpOnlyZašto je opasno?: Ako razvojni programer web-mjesta nije odredio te atribute, napadač bi mogao presresti korisničke informacije iz kolačića i iskoristiti ih. Ako se kolačići koriste za autentifikaciju i autorizaciju, on će moći preoteti korisnikovu sesiju i obavljati radnje na stranici u njegovo ime.
Što bi web programer trebao zapamtiti: U pravilu, u popularnim okvirima ovi se atributi postavljaju automatski. Ali svejedno provjerite konfiguraciju web poslužitelja i postavite oznaku: Set-Cookie HttpOnly; Siguran.
U ovom slučaju, atribut "HTTPOnly" učinit će kolačiće nevidljivima za vaš JavaScript.
- Ranjivosti temeljene na putu.
Skener prijavljuje takvu ranjivost ako pronađe javno dostupnu datoteku ili imenik web stranice s potencijalno povjerljivim informacijama. Na primjer, otkriva pojedinačne konfiguracijske datoteke sustava ili pristup cijelom datotečnom sustavu. Ova situacija je moguća ako su prava pristupa netočno postavljena na stranici.
Zašto je opasno?: Ako datotečni sustav "strši", napadač može upasti u sučelje operativnog sustava i pokušati pronaći mape s lozinkama ako su pohranjene u čistom tekstu (nemojte to činiti!). Ili možete ukrasti hash lozinke i brutalno forsirati lozinku, a također pokušati podići privilegije u sustavu i ići dublje u infrastrukturu.
Što bi web programer trebao zapamtiti: Ne zaboravite na prava pristupa i konfigurirajte platformu, web poslužitelj, web aplikaciju tako da je nemoguće “pobjeći” iz web imenika.
- Obrasci za unos osjetljivih podataka s uključenim automatskim popunjavanjem.
Ako korisnik često ispunjava obrasce na web stranicama, njegov preglednik pohranjuje te podatke pomoću značajke automatskog popunjavanja.
Obrasci na web stranicama mogu sadržavati polja s osjetljivim podacima, kao što su lozinke ili brojevi kreditnih kartica. Za takva polja vrijedi onemogućiti funkciju automatskog popunjavanja obrazaca na samom mjestu.
Zašto je opasno?: Ako korisnikov preglednik pohranjuje osjetljive informacije, napadač ih kasnije može presresti, primjerice putem krađe identiteta. U biti, web programer koji je zaboravio na ovu nijansu postavlja svoje korisnike.
Što bi web programer trebao zapamtiti: U ovom slučaju imamo klasični sukob: praktičnost protiv sigurnosti. Ako web programer razmišlja o korisničkom iskustvu, može svjesno odabrati automatsko dovršavanje. Na primjer, ako je važno slijediti – preporuke za pristupačnost sadržaja korisnicima s invaliditetom.
Za većinu preglednika možete onemogućiti automatsko dovršavanje s atributom autocompete="off", na primjer:
<body> <form action="/hr/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Ali to neće raditi za Chrome. Ovo je zaobiđeno pomoću JavaScripta, može se pronaći varijanta recepta .
- Zaglavlje X-Frame-Options nije postavljeno u kodu stranice.
Ovo zaglavlje utječe na oznake okvira, iframea, ugradnje ili objekata. Uz njegovu pomoć možete u potpunosti zabraniti ugradnju svoje stranice unutar okvira. Da biste to učinili, trebate navesti vrijednost X-Frame-Options: deny. Ili možete navesti X-Frame-Options: sameorigin, tada će ugradnja u iframe biti dostupna samo na vašoj domeni.
Zašto je opasno?: Nedostatak takvog zaglavlja može se koristiti na zlonamjernim web-mjestima za clickjacking. Za ovaj napad, napadač stvara prozirni okvir na vrhu gumba i prevari korisnika. Na primjer: prevaranti uokviruju stranice društvenih mreža na web stranici. Korisnik misli da klikne gumb na ovoj stranici. Umjesto toga, klik se presreće i zahtjev korisnika šalje društvenoj mreži na kojoj postoji aktivna sesija. Na taj način napadači šalju neželjenu poštu u ime korisnika ili dobivaju pretplatnike i lajkove.
Ako ne onemogućite ovu značajku, napadač može postaviti gumb vaše aplikacije na zlonamjerno mjesto. Možda ga zanima vaš program preporuke ili vaši korisnici.
Što bi web programer trebao zapamtiti: Ranjivost se može pojaviti ako su X-Frame-Options s proturječnom vrijednošću postavljene na web poslužitelju ili balanseru opterećenja. U tom će slučaju poslužitelj i balanser jednostavno prepisati zaglavlje, budući da imaju veći prioritet u usporedbi s pozadinskim kodom.
Vrijednosti deny i sameorigin zaglavlja X-Frame-Options ometat će rad Yandex web preglednika. Da biste dopustili korištenje iframesa za web preglednik, morate napisati zasebno pravilo u postavkama. Na primjer, za nginx možete ga konfigurirati ovako:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI (path-relative stylesheet import) ranjivosti.
Ovo je ranjivost u stilu stranice. To se događa ako se za pristup datotekama stilova koriste relativne veze poput href="/hr/somefolder/styles.css/". Napadač će to iskoristiti ako pronađe način da preusmjeri korisnika na zlonamjernu stranicu. Stranica će umetnuti relativnu vezu u svoj url i simulirati poziv stilova. Dobit ćete zahtjev poput badsite.ru/…/somefolder/styles.css/, koji može izvesti zlonamjerne radnje pod krinkom stila.
Zašto je opasno?: Prevarant bi mogao iskoristiti ovu ranjivost ako pronađe drugu sigurnosnu rupu. Kao rezultat toga, moguće je ukrasti korisničke podatke iz kolačića ili tokena.
Što bi web programer trebao zapamtiti: Postavite zaglavlje X-Content-Type-Options na: nosniff. U tom će slučaju preglednik provjeriti vrstu sadržaja za stilove. Ako je vrsta različita od text/css, preglednik će blokirati zahtjev.
Kritične ranjivosti
- Stranica s poljem za zaporku prenosi se s poslužitelja preko nesigurnog kanala (HTML obrazac koji sadrži polje(a) za zaporku poslužuje se preko HTTP-a).
Odgovor poslužitelja preko nešifriranog kanala ranjiv je na napade "Čovjek u sredini". Napadač može presresti promet i uglaviti se između klijenta i poslužitelja dok stranica putuje od poslužitelja do klijenta.
Zašto je opasno?: Prevarant će moći zamijeniti stranicu i poslati korisniku obrazac za povjerljive podatke, koji će ići na poslužitelj napadača.
Što bi web programer trebao zapamtiti: Neke stranice šalju korisnicima jednokratni kod putem e-pošte/telefona umjesto lozinke. U ovom slučaju, ranjivost nije toliko kritična, ali mehanizam će komplicirati živote korisnika.
- Slanje obrasca s prijavom i lozinkom preko nesigurnog kanala (obrazac za prijavu nije poslan putem HTTPS-a).
U tom slučaju, obrazac s prijavom i lozinkom šalje se od korisnika do poslužitelja putem nešifriranog kanala.
Zašto je opasno?: Za razliku od prethodnog slučaja, ovo je već kritična ranjivost. Lakše je presresti osjetljive podatke jer za to ne morate čak ni napisati kod.
- Korištenje JavaScript biblioteka s poznatim propustima.
Tijekom skeniranja najkorištenija biblioteka bila je jQuery s velikim brojem verzija. Svaka verzija ima barem jednu ili čak više poznatih ranjivosti. Utjecaj može biti vrlo različit ovisno o prirodi ranjivosti.
Zašto je opasno?: Postoje iskorištavanja za poznate ranjivosti, na primjer:
Što bi web programer trebao zapamtiti: Redovito se vraćajte na ciklus: traženje poznatih ranjivosti - popravak - provjera. Ako namjerno koristite naslijeđene biblioteke, na primjer za podršku starijim preglednicima ili za uštedu novca, potražite priliku da popravite poznatu ranjivost. - Cross-site skriptiranje (XSS).
Cross-Site Scripting (XSS) ili cross-site scripting je napad na web aplikaciju koji rezultira uvođenjem zlonamjernog softvera u bazu podataka. Ako Qualys pronađe takvu ranjivost, to znači da potencijalni napadač može ili je već uveo vlastitu js skriptu u kod stranice za izvođenje zlonamjernih radnji.Pohranjeni XSS opasniji jer je skripta ugrađena na poslužitelj i izvršava se svaki put kada se napadnuta stranica otvori u pregledniku.
Odraženi XSS lakše izvesti jer se zlonamjerna skripta može ubaciti u HTTP zahtjev. Aplikacija će primiti HTTP zahtjev, neće potvrditi podatke, zapakirat će ih i odmah poslati. Ako napadač presretne promet i ubaci skriptu poput
<script>/*+что+то+плохое+*/</script>tada će zlonamjerni zahtjev biti poslan u ime klijenta.
Upečatljiv primjer XSS-a: js snifferi koji simuliraju stranice za unos CVC-a, datuma isteka kartice i tako dalje.
Što bi web programer trebao zapamtiti: U zaglavlju Content-Security-Policy upotrijebite atribut script-src da natjerate preglednik klijenta da preuzima i izvršava samo kod iz pouzdanog izvora. Na primjer, script-src 'self' stavlja na popis dopuštenih samo sve skripte s naše stranice.
Najbolja praksa je Inline kod: dopustite samo ugrađeni javascript koristeći unsafe-inline vrijednost. Ova vrijednost dopušta upotrebu ugrađenog js/css, ali ne zabranjuje uključivanje js datoteka. U kombinaciji sa script-src 'self' onemogućujemo izvršavanje vanjskih skripti.Obavezno zabilježite sve koristeći report-uri i pogledajte pokušaje implementacije na stranicu.
- SQL injekcije.
Ranjivost ukazuje na mogućnost ubacivanja SQL koda u web stranicu koja izravno pristupa bazi podataka web stranice. SQL injekcija je moguća ako podaci od korisnika nisu pregledani: ne provjerava se njihova ispravnost i odmah se koriste u upitu. Na primjer, to se događa ako obrazac na web stranici ne provjerava podudara li se unos s vrstom podataka.Zašto je opasno?: Ako napadač unese SQL upit u ovaj obrazac, može srušiti bazu podataka ili otkriti povjerljive informacije.
Što bi web programer trebao zapamtiti: Ne vjerujte onome što dolazi iz preglednika. Morate se zaštititi i na strani klijenta i na strani poslužitelja.
Na strani klijenta, napišite provjeru valjanosti polja koristeći JavaScript.
Ugrađene funkcije u popularnim okvirima također pomažu u izbjegavanju sumnjivih znakova na poslužitelju. Također se preporučuje korištenje parametariziranih upita baze podataka na poslužitelju.
Odredite gdje se točno odvija interakcija s bazom podataka na web aplikaciji.
Interakcija se događa kada primimo bilo koju informaciju: zahtjev s ID-om (promjena ID-a), kreiranje novog korisnika, novi komentar ili novi unosi u bazu. Ovdje se mogu pojaviti SQL injekcije. Čak i ako izbrišemo zapis iz baze podataka, SQL injekcija je moguća.
Opće preporuke
Nemojte ponovno izumiti kotač - koristite provjerene okvire. U pravilu su popularni okviri sigurniji. Za .NET - ASP.NET MVC i ASP.NET Core, za Python - Django ili Flask, za Ruby - Ruby on Rails, za PHP - Symfony, Laravel, Yii, za JavaScript - Node.JS-Express.js, za Java - Proljetni MVC.
Pratite ažuriranja dobavljača i redovito ažurirajte. Pronaći će ranjivost, zatim napisati exploit, učiniti ga javno dostupnim i sve će se ponoviti. Pretplatite se na ažuriranja stabilnih verzija od dobavljača softvera.
Provjerite dopuštenja. Na serverskoj strani uvijek tretirajte svoj kod kao da ga je, od prvog do zadnjeg slova, napisao vaš najomraženiji neprijatelj, koji želi slomiti vašu stranicu, narušiti integritet vaših podataka. Štoviše, ponekad je to istina.
Koristite klonove, testna mjesta, a zatim ih upotrijebite za proizvodnju. To će pomoći, prvo, da se izbjegnu greške i pogreške u produktivnom okruženju: produktivno okruženje donosi novac, jednostavno produktivno okruženje je kritično. Prilikom dodavanja, popravljanja ili zatvaranja bilo kojeg problema, vrijedi raditi u testnom okruženju, zatim provjeriti funkcionalnost i pronađene ranjivosti, a zatim planirati rad s proizvodnim okruženjem.
Zaštitite svoju web aplikaciju s i s njim integrirati izvješća iz skenera ranjivosti. Na primjer, DataLine koristi Qualys i FortiWeb kao paket usluga.
Izvor: www.habr.com