Prije otprilike godinu dana, mi u DataLineu smo lansirali za pretraživanje i analizu ranjivosti u IT aplikacijama. Usluga je bazirana na Qualys cloud rješenju o čijem radu . Tokom godinu dana rada sa rješenjem, izvršili smo 291 skeniranje za različite stranice i prikupili statističke podatke o uobičajenim ranjivostima u web aplikacijama.
U članku ispod pokazat ću vam koje se točno rupe u sigurnosti web stranice kriju iza različitih nivoa kritičnosti. Pogledajmo koje ranjivosti skener posebno često pronalazi, zašto se one mogu pojaviti i kako se zaštititi.
Qualys sve ranjivosti web aplikacija dijeli na tri nivoa kritičnosti: nisku, srednju i visoku. Ako pogledate distribuciju po "ozbiljnosti", čini se da nije sve tako loše. Postoji nekoliko ranjivosti sa visokim nivoom kritičnosti, uglavnom sve su nekritične:
Ali nekritičan ne znači bezopasan. Oni također mogu uzrokovati ozbiljnu štetu.
Najveće „nekritične“ ranjivosti
- Ranjivosti mješovitog sadržaja.
Standard za sigurnost web stranice je prijenos podataka između klijenta i servera putem HTTPS protokola, koji podržava enkripciju i štiti informacije od presretanja.
Neki sajtovi koriste mešoviti sadržaj: Neki podaci se prenose putem nesigurnog HTTP protokola. Ovako se najčešće prenosi pasivni sadržaj – informacije koje utječu samo na prikaz stranice: slike, css stilovi. Ali ponekad se ovako prenosi aktivni sadržaj: skripte koje kontroliraju ponašanje stranice. U tom slučaju, pomoću posebnog softvera, možete analizirati informacije sa aktivnim sadržajem koji dolaze sa servera, modificirati svoje odgovore u hodu i učiniti da mašina radi na način koji nisu namjeravali njegovi kreatori.
Novije verzije pretraživača upozoravaju korisnike da web lokacije sa mešovitim sadržajem nisu bezbedne i blokiraju sadržaj. Programeri web stranica također primaju upozorenja pretraživača u konzoli. Na primjer, ovako to izgleda :
Zašto je to opasno: Napadači koriste nesiguran protokol za presretanje korisničkih informacija, zamjenu skripti i slanje zahtjeva na stranicu u njegovo ime. Čak i ako posjetitelj stranice nije unio podatke, to ga ne štiti od phishing – pribavljanje povjerljivih informacija lažnim metodama. Na primjer, koristeći skriptu, možete preusmjeriti korisnika na nesigurnu stranicu koja se maskira kao ona poznata korisniku. U nekim slučajevima zlonamjerna stranica izgleda čak i bolje od originala, a korisnik može sam ispuniti obrazac i dostaviti povjerljive podatke.Ono što web programer treba zapamtiti: Čak i ako je administrator stranice instalirao i konfigurirao SSL/TLS certifikat, ranjivost može nastati zbog ljudske greške. Na primjer, ako na jednoj od stranica stavite ne relativnu vezu, već apsolutnu vezu sa http, a osim toga niste podesili preusmjeravanja sa http na https.
Možete otkriti mješoviti sadržaj na web lokaciji pomoću pretraživača: pretražite izvorni kod stranice, pročitajte obavještenja na konzoli za programere. Međutim, programer će morati dugo i zamorno petljati s kodom. Možete ubrzati proces pomoću automatiziranih alata za analizu, na primjer: , besplatni Lighthouse softver ili plaćeni softver Screaming Frog SEO Spider.
Takođe, ranjivost može nastati zbog problema sa 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-mjesta 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 dozvoljava slanje kolačića u čistom tekstu. Komunikacija će biti dozvoljena samo ako se za slanje kolačića koristi siguran HTTPS protokol.
Oba atributa su navedena u svojstvima kolačića:
Set-Cookie: Secure; HttpOnlyZašto je to opasno: Ako programer stranice nije naveo ove atribute, napadač bi mogao presresti informacije korisnika iz kolačića i iskoristiti ih. Ako se kolačići koriste za autentifikaciju i autorizaciju, on će biti u mogućnosti da otme korisnikovu sesiju i obavlja radnje na stranici u njegovo ime.
Ono što web programer treba zapamtiti: Po pravilu, u popularnim okvirima ovi se atributi postavljaju automatski. Ali ipak provjerite konfiguraciju web servera i postavite zastavicu: Set-Cookie HttpOnly; Sigurno.
U ovom slučaju, atribut “HTTPOnly” će učiniti kolačiće nevidljivim za vaš vlastiti JavaScript.
- Ranjivosti zasnovane na putanji.
Skener prijavljuje takvu ranjivost ako pronađe javno dostupnu datoteku ili direktorij web stranice s potencijalno povjerljivim informacijama. Na primjer, detektuje pojedinačne konfiguracijske datoteke sistema ili pristup cijelom sistemu datoteka. Ova situacija je moguća ako su prava pristupa pogrešno postavljena na stranici.
Zašto je to opasno: Ako sistem datoteka "štrči", napadač može upasti u interfejs operativnog sistema i pokušati pronaći fascikle sa lozinkama ako su pohranjene u čistom tekstu (nemojte to raditi!). Ili možete ukrasti hešove lozinke i grubo forsirati lozinku, a također pokušati podići privilegije u sistemu i pomaknuti se dublje u infrastrukturu.
Ono što web programer treba zapamtiti: Ne zaboravite na prava pristupa i konfigurirajte platformu, web server, web aplikaciju tako da je nemoguće “pobjeći” iz web direktorija.
- Obrasci za unos osjetljivih podataka s uključenim automatskim popunjavanjem.
Ako korisnik često ispunjava obrasce na web stranicama, njihov preglednik pohranjuje ove informacije koristeći funkciju automatskog popunjavanja.
Obrasci na web stranicama mogu uključivati polja s osjetljivim informacijama, kao što su lozinke ili brojevi kreditnih kartica. Za takva polja vrijedi onemogućiti funkciju automatskog popunjavanja obrazaca na samoj web stranici.
Zašto je to opasno: Ako korisnikov pretraživač pohranjuje osjetljive informacije, napadač ih može presresti kasnije, na primjer putem phishinga. U suštini, web programer koji je zaboravio na ovu nijansu postavlja svoje korisnike.
Ono što web programer treba zapamtiti: U ovom slučaju imamo klasični sukob: pogodnost protiv sigurnosti. Ako web programer razmišlja o korisničkom iskustvu, on može svjesno odabrati autocomplete. Na primjer, ako je važno pratiti – preporuke za pristupačnost sadržaja korisnicima sa invaliditetom.
Za većinu pretraživača možete onemogućiti autodovršavanje atributom autocompete="off", na primjer:
<body> <form action="/bs/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 se zaobilazi pomoću JavaScripta, može se pronaći varijanta recepta .
- Zaglavlje X-Frame-Options nije postavljeno u kodu lokacije.
Ovo zaglavlje utiče na oznake okvira, iframea, ugradnje ili objekta. Uz njegovu pomoć možete u potpunosti zabraniti ugrađivanje vaše stranice u okvir. Da biste to učinili, morate navesti vrijednost X-Frame-Options: deny. Ili možete odrediti X-Frame-Options: sameorigin, tada će ugrađivanje u iframe biti dostupno samo na vašoj domeni.
Zašto je to opasno: Odsustvo takvog zaglavlja može se koristiti na zlonamjernim stranicama za clickjacking. Za ovaj napad, napadač kreira prozirni okvir na vrhu dugmadi i prevari korisnika. Na primjer: prevaranti uokviruju stranice društvenih mreža na web stranici. Korisnik misli da je kliknuo dugme na ovoj stranici. Umjesto toga, klik se presreće i korisnikov zahtjev se šalje društvenoj mreži na kojoj je aktivna sesija. Na ovaj način napadači šalju neželjenu poštu u ime korisnika ili stječu pretplatnike i lajkove.
Ako ne onemogućite ovu funkciju, napadač može postaviti dugme vaše aplikacije na zlonamjernu stranicu. Možda će biti zainteresovan za vaš program preporuka ili vaše korisnike.
Ono što web programer treba zapamtiti: Ranjivost se može pojaviti ako je X-Frame-Options sa konfliktnom vrijednošću postavljena na web server ili balansator opterećenja. U ovom slučaju, server i balanser će jednostavno prepisati zaglavlje, budući da imaju veći prioritet u poređenju sa pozadinskim kodom.
Vrijednosti zabrane i iste izvorne vrijednosti zaglavlja X-Frame-Options ometat će rad Yandex web preglednika. Da biste omogućili korištenje iframe-ova za web preglednik, morate napisati posebno 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 relativne veze poput href="/bs/somefolder/styles.css/" koriste za pristup datotekama stilova. 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 stila. Dobit ćete zahtjev poput badsite.ru/…/somefolder/styles.css/, koji može izvršiti zlonamjerne radnje pod krinkom stila.
Zašto je to opasno: Prevarant bi mogao iskoristiti ovu ranjivost ako pronađe još jednu sigurnosnu rupu. Kao rezultat toga, moguće je ukrasti korisničke podatke iz kolačića ili tokena.
Ono što web programer treba zapamtiti: Postavite zaglavlje X-Content-Type-Options na: nosniff. U ovom slučaju, pretraživač će provjeriti tip sadržaja za stilove. Ako tip nije tekst/css, pretraživač će blokirati zahtjev.
Kritične ranjivosti
- Stranica sa poljem za lozinku se prenosi sa servera preko nesigurnog kanala (HTML obrazac koji sadrži polje(a) za lozinku se servira preko HTTP-a).
Odgovor servera preko nešifrovanog kanala je ranjiv na napade "Čovjek u sredini". Napadač može presresti promet i zaglaviti se između klijenta i servera dok stranica putuje od servera do klijenta.
Zašto je to opasno: Prevarant će moći zamijeniti stranicu i poslati korisniku obrazac za povjerljive podatke, koji će ići na server napadača.
Ono što web programer treba zapamtiti: Neke web lokacije šalju korisnicima jednokratni kod putem e-pošte/telefona umjesto lozinke. U ovom slučaju, ranjivost nije toliko kritična, ali mehanizam će zakomplikovati živote korisnika.
- Slanje obrasca sa prijavom i lozinkom preko nesigurnog kanala (obrazac za prijavu se ne šalje putem HTTPS-a).
U tom slučaju, obrazac sa prijavom i lozinkom se šalje od korisnika na server preko nešifrovanog kanala.
Zašto je to opasno: Za razliku od prethodnog slučaja, ovo je već kritična ranjivost. Lakše je presresti osjetljive podatke jer ne morate čak ni pisati kod da biste to učinili.
- Korišćenje JavaScript biblioteka sa poznatim ranjivostima.
Tokom skeniranja, najčešće korištena biblioteka bio je jQuery sa velikim brojem verzija. Svaka verzija ima barem jednu, ili čak više, poznatih ranjivosti. Uticaj može biti veoma različit u zavisnosti od prirode ranjivosti.
Zašto je to opasno: Postoje eksploatacije za poznate ranjivosti, na primjer:
Ono što web programer treba zapamtiti: Redovno se vraćajte u ciklus: potražite poznate ranjivosti - popravite - provjerite. Ako koristite naslijeđene biblioteke namjerno, na primjer za podršku starijim pretraživačima ili da uštedite novac, potražite priliku da popravite poznatu ranjivost. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), ili cross-site scripting, je napad na web aplikaciju koji rezultira unoš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 web-mjesta za obavljanje zlonamjernih radnji.Pohranjeni XSS opasnije, jer je skripta ugrađena na server i izvršava se svaki put kada se napadnuta stranica otvori u pretraživaču.
Reflected XSS lakše za izvođenje jer se zlonamjerna skripta može ubaciti u HTTP zahtjev. Aplikacija će primiti HTTP zahtjev, neće potvrditi podatke, pakovat će ih i odmah poslati. Ako napadač presreće saobraćaj i ubaci skriptu kao
<script>/*+что+то+плохое+*/</script>tada će se poslati zlonamjerni zahtjev u ime klijenta.
Upečatljiv primjer XSS: js sniffera koji simuliraju stranice za unos CVC-a, datuma isteka kartice i tako dalje.
Ono što web programer treba zapamtiti: U zaglavlju Content-Security-Policy, koristite atribut script-src da prisilite pretraživač klijenta da preuzima i izvršava samo kod iz pouzdanog izvora. Na primjer, script-src 'self' stavlja sve skripte samo s naše stranice.
Najbolja praksa je Inline kod: dozvolite samo inline javascript koristeći vrijednost nesiguran inline. Ova vrijednost dozvoljava korištenje inline js/css, ali ne zabranjuje uključivanje js datoteka. U kombinaciji sa script-src 'self' onemogućavamo izvršavanje eksternih skripti.Obavezno prijavite sve koristeći report-uri i pogledajte pokušaje da se to implementira na stranicu.
- SQL injekcije.
Ranjivost ukazuje na mogućnost ubrizgavanja SQL koda u web stranicu koja direktno pristupa bazi podataka web stranice. SQL injekcija je moguća ako se podaci od korisnika ne pregledaju: ne provjerava se ispravnost i odmah se koristi u upitu. Na primjer, ovo se događa ako obrazac na web stranici ne provjerava da li se unos podudara s tipom podataka.Zašto je to opasno: Ako napadač unese SQL upit u ovaj obrazac, može srušiti bazu podataka ili otkriti povjerljive informacije.
Ono što web programer treba zapamtiti: Ne vjerujte onome što dolazi iz pretraživača. Morate se zaštititi i na strani klijenta i na strani servera.
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 serveru. Također se preporučuje korištenje parametriziranih upita baze podataka na poslužitelju.
Odredite gdje se tačno odvija interakcija s bazom podataka na web aplikaciji.
Interakcija se događa kada primimo bilo koju informaciju: zahtjev sa ID-om (promjena id-a), kreiranje novog korisnika, novi komentar ili nove unose u bazi podataka. Ovdje se mogu pojaviti SQL injekcije. Čak i ako izbrišemo zapis iz baze podataka, SQL injekcija je moguća.
Opšte preporuke
Nemojte ponovo izmišljati točak - koristite provjerene okvire. Po pravilu, popularni okviri su 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 Javu - Spring MVC.
Pratite ažuriranja dobavljača i redovno ažurirajte. Pronaći će ranjivost, zatim napisati eksploataciju, učiniti je javno dostupnim i sve će se ponoviti. Pretplatite se na ažuriranja stabilnih verzija od dobavljača softvera.
Provjerite prava pristupa. Na strani servera, uvijek tretirajte svoj kod kao da ga je, od prvog do posljednjeg slova, napisao vaš najomraženiji neprijatelj, koji želi da razbije vaš sajt, naruši integritet vaših podataka. Štaviše, ponekad je to istina.
Koristite klonove, testne lokacije, a zatim ih koristite za proizvodnju. Ovo će pomoći, prije svega, da se izbjegnu greške i greš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 sa i integrirati izvještaje sa skenera ranjivosti sa njim. Na primjer, DataLine koristi Qualys i FortiWeb kao skup usluga.
izvor: www.habr.com