Smrtnimi grehi varnosti spletne strani: kaj smo izvedeli iz statistike skenerja ranljivosti v enem letu

Približno pred letom dni smo v DataLine zagnali servis storitev za iskanje in analizo ranljivosti v IT-aplikacijah. Temelji na oblačni rešitvi Qualys, o kateri smo že poročali. V enem letu delovanja rešitve smo izvedli 291 skeniranj za različne spletne strani in zbrali statistiko o pogostih ranljivostih v spletnih aplikacijah. 

V spodnjem članku bom pokazal, katere varnostne luknje na spletnih mestih se skrivajo za različnimi ravnmi kritičnosti. Poglejmo, katere ranljivosti je skener odkrival še posebej pogosto, zakaj se lahko pojavijo in kako se zaščititi. 

Vse ranljivosti spletnih aplikacij Qualys razdeli na tri ravni kritičnosti: nizka, srednja in visoka. Če pogledamo porazdelitev po 'težavnosti', se zdi, da vse ni tako slabo. Ranljivosti z visoko stopnjo kritičnosti je malo, večinoma so vse nekritične: 

Toda nekritične ne pomenijo brezopasne. Tudi te lahko povzročijo resno škodo. 

Najbolj pogoste 'nekritične' ranljivosti

1. Ranljivosti, povezane s mešano vsebino.

   Standard varnosti spletnih strani predvideva prenos podatkov med klientom in strežnikom po protokolu HTTPS, ki omogoča šifriranje in ščiti informacije pred prestrezanjem. 

   Nekatere spletne strani uporabljajo mešano vsebino: prenašajo del podatkov prek nezavarovanega protokola HTTP. Pogosto tako prenašajo pasivno vsebino – informacije, ki vplivajo le na prikaz spletne strani: slike, css slogi. Toda včasih se tako prenaša tudi aktivna vsebina: skripti, ki upravljajo vedenje spletne strani. V tem primeru lahko s posebnim programjem analiziramo informacije, ki prihajajo od strežnika z aktivno vsebino, spreminjamo odgovore v realnem času in prisilimo napravo, da deluje tako, kot ni bilo zamišljeno s strani njenih ustvarjalcev. 

   Brazorji novejših različic opozarjajo uporabnike, da so spletne strani z mešano vsebino nevarne, in blokirajo vsebino. Tudi razvijalci spletnih strani prejemajo opozorila od brskalnika v konzoli. Tako to izgleda v Firefox: 

   
   
   Kaj je nevarno: Zlorabniki uporabljajo nezavarovan protokol za prestrezanje informacij o uporabniku, zamenjavo skript in pošiljanje zahtevkov na spletno stran v njegovem imenu. Tudi če obiskovalec spletne strani ni vnesel podatkov, ga to ne ščiti pred phishingom – izluščanje občutljivih informacij s prevarantskimi metodami. Na primer, z uporabo skripta lahko uporabnika preusmerite na nezavarovano spletno mesto, ki se prikazuje kot znano uporabniku. V nekaterih primerih lahko zlonamerno spletno mesto izgleda celo boljše od izvirnika, uporabnik pa sam lahko izpolni obrazec in posreduje občutljive podatke. 

   Kaj mora vedeti spletni razvijalec: Tudi če je skrbnik spletne strani namestil in konfiguriral SSL/TLS certifikat, lahko ranljivost nastane zaradi človeškega faktorja. Na primer, če je na eni od strani postavljena absolutna povezava z http, namesto relativne, in dodatno niso nastavljeni preusmeritve z http na https. 

   Z mešanimi vsebinami na spletni strani lahko odkrijemo s pomočjo brskalnika: iskali bomo v izvorni kodi strani, brali obvestila v konzoli razvijalca. Kljub temu bo razvijalec moral dolgotrajno in mučno 'kopati' v kodi. Postopek lahko pospešite z avtomatiziranimi analitičnimi orodji, kot so: SSL Check, brezplačno orodje Lighthouse ali plačano programsko opremo Screaming Frog SEO Spider.

   Tudi ranljivost lahko nastane zaradi težav s starim kodo – kodo, ki je podedovana. Na primer, če se del strani generira po starem predlogu, kjer ni upoštevan prehod spletnih strani na https.    

2. Piškotki brez oznak „HTTPOnly“ in „secure“.

   Oznaka „HTTPOnly“ ščiti piškotke pred obdelavo s skripti, ki jih zlonamerni igralci uporabljajo za krajo uporabniških podatkov. Oznaka „secure“ preprečuje prenos piškotkov v odprti obliki. Izmenjava podatkov bo dovoljena, le če se piškotki pošiljajo preko varnega protokola HTTPS. 

   Obe oznaki sta zapisana v lastnostih piškotkov:

   Set-Cookie: Secure; HttpOnly

   Kaj je nevarno: Če razvijalec spletne strani teh oznak ni navedel, lahko zlonamerni igralec ujame uporabniške informacije iz piškotkov in jih izkoristi. Če se piškotki uporabljajo za avtentikacijo in avtorizacijo, lahko prevzame uporabniško sejo in izvede dejanja na spletnem mestu v imenu uporabnika. 

   Kaj mora vedeti spletni razvijalec: Običajno ti oznaki v priljubljenih okvirih nastavi avtomatsko. Vseeno pa preverite konfiguracijo spletnega strežnika in nastavite oznako: Set-Cookie HttpOnly; Secure.

   Oznaka „HTTPOnly“ bo tudi naredila piškotke nevidne za vaš lasten JavaScript.  

3. Ranljivosti na podlagi poti.

   Skener prijavljuje ovu ranjivost kada pronađe javno dostupnu datoteku ili direktorij veb sajta sa potencijalno poverljivim informacijama. Na primer, otkriva pojedinačne datoteke sa konfiguracijom sistema ili pristup celoj datotečnoj sistemu. Ova situacija može nastati ako su prava pristupa na sajtu pogrešno postavljena.

   Kaj je nevarno: Ako je datotečni sistem 'izložen napolje', napadač može da pristupi interfejsu operativnog sistema i pokuša da pronađe fascikle sa lozinkama, ako se čuvaju u otvorenom obliku (nikako to ne radite!). Takođe, može ukrasti heširane lozinke i pokušati da pogodi lozinku, kao i da pokuša da podigne privilegije u sistemu i napreduje duboko u infrastrukturu.  

   Kaj mora vedeti spletni razvijalec: Ne zaboravite na prava pristupa i konfigurišite platformu, veb server i veb aplikaciju tako da ne bude moguće 'pobegnuti' iz veb direktorijuma.

4. Forme za unos poverljivih podataka sa uključenom funkcijom automatskog popunjavanja.

   Ako korisnik često popunjava forme na veb sajtovima, njegov pregledač čuva ove informacije pomoću funkcije automatskog popunjavanja. 

   Forme na veb sajtovima mogu uključivati polja sa poverljivim informacijama, na primer, lozinke ili brojeve kreditnih kartica. Za takva polja trebalo bi na samom sajtu onemogućiti funkciju automatskog popunjavanja forma. 

   Kaj je nevarno: Ako pregledač korisnika sačuva poverljive informacije, napadač ih može preuzeti kasnije, na primer, putem fišinga. U suštini, veb programer koji zaboravi na ovu nijansu postavlja svoje korisnike u rizik. 

   Kaj mora vedeti spletni razvijalec: U ovom slučaju imamo klasičan sukob: udobnost vs bezbednost. Ako veb programer razmišlja o udobnosti korisnika, može svesno izabrati automatsko popunjavanje. Na primer, ako je važno da se prati Web Content Accessibility Guidelines – smernice za dostupnost sadržaja za korisnike sa ograničenim sposobnostima. 

   Za većinu pregledača, automatsko popunjavanje može se onemogućiti atributom autocomplete='off', na primer:

    <body>
       <form action="/sl/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit">
         <div>
           <input type="text" placeholder="Ime">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Priimek" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Številka kreditne kartice">
         </div>
         <input type="submit">
       <input type="hidden" name="trp-form-language" value="sl"/></form>
     </body>

   Ali za Chrome to neće funkcionisati. Ovo se zaobilazi pomoću JavaScript-a, a recept za rešenje možete pronaći ovde. 

5. U kodu sajta nije postavljen header X-Frame-Options. 

   Ta naslov vpliva na oznake frame, iframe, embed ali object. Z njim lahko popolnoma prepoveste vgradnjo svoje spletne strani znotraj okvira. To lahko storite z navedbo vrednosti X-Frame-Options: deny. Lahko pa navedete X-Frame-Options: sameorigin, takrat bo vgradnja v iframe na voljo samo na vaši domeni.

   Kaj je nevarno: Odsotnost takega naslova lahko izkoristijo zlonamerne spletne strani za klikdžeking. Pri takšni napadi zlonamerne osebe ustvarijo prozoren okvir nad gumbi in pretentajo uporabnika. Na primer: goljufi postavijo v okvir stran s socialnimi omrežji. Uporabnik misli, da kliče na gumb na tej spletni strani. Namesto tega se klik ujame in pošlje zahtevo uporabnika na socialno omrežje, kjer ima aktivno sejo. Tako zlonamerne osebe širijo spam v imenu uporabnika ali povečujejo število naročnikov in všečkov. 

   Če ne prepoveste te možnosti, lahko zlonamerna oseba postavi gumb vaše aplikacije na zlonamerno spletno stran. Morda bo zainteresiran za vaš referenčni program ali za vaše uporabnike.  

   Kaj mora vedeti spletni razvijalec: Ranljivost se lahko pojavi, če je na spletnem strežniku ali ravnotežju obremenitve nastavljena X-Frame-Options z nasprotujočo vrednostjo. V tem primeru strežnik in ravnotežnik bremen postavita naslov znova, saj imata višjo prioriteto v primerjavi s kodo backend dela.  

   Vrednosti deny in sameorigin naslova X-Frame-Options bodo ovirale delovanje spletnega vizorja Yandex. Da bi omogočili uporabo iframe za spletni vizor, je potrebno v nastavitvah napisati posebno pravilo. Na primer, za nginx lahko nastavite tako:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. Ranljivosti PRSSI (uvoz slogov, relativno glede na pot).  

   To je ranljivost v stilih spletne strani. Pojavi se, če se za dostop do datotek slogov uporabljajo relativne povezave v slogu href="/somefolder/styles.css/". Zlonamerna oseba bo to izkoristila, če najde način za preusmeritev uporabnika na zlonamerno stran. Stran bo v svoj URL vstavila relativno povezavo in posnemala dostop do slogov. Tako bo nastala zahteva, podobna badsite.ru/.../somefolder/styles.css/, ki lahko pod krinko stila izvaja zlonamerne dejavnosti. 

   Kaj je nevarno: Prevarant može iskoristiti ovu ranjivost ako pronađe još jednu sigurnosnu rupu. Kao rezultat, tako se mogu ukrasti korisnički podaci iz kolačića ili tokena.

   Kaj mora vedeti spletni razvijalec: Postavite zaglavlje X-Content-Type-Options: nosniff. U tom slučaju, pregledač će proveriti tip sadržaja za stilove. Ako se tip razlikuje od text/css, pregledač će blokirati zahtev.

Kritične ranjivosti

1. Stranica sa poljem za lozinku se prenosi sa servera preko nezaštićenog kanala (HTML forma koja sadrži polje za lozinku se isporučuje putem HTTP).

   Odgovor sa servera preko nešifrovanog kanala je ranjiv na napade tipa 'Čovek u sredini'. Napadač može presresti saobraćaj i ubaciti se između klijenta i servera dok stranica ide od servera do klijenta. 

   Kaj je nevarno: Prevarant može zameniti stranicu i poslati korisniku obrazac za poverljive podatke koji će otići na server napadača. 

   Kaj mora vedeti spletni razvijalec: Neki sajtovi umesto lozinke šalju korisnicima jednokratni kod na e-mail/telefon. U ovom slučaju ranjivost nije tako kritična, ali mehanizam će otežati život korisnicima.

2. Slanje forme sa loginom i lozinkom preko nezaštićenog kanala (Forma za prijavu nije poslata putem HTTPS-a).

   U tom slučaju, od korisnika se na server preko nešifrovanog kanala šalje forma sa loginom i lozinkom.

   Kaj je nevarno: Za razliku od prethodnog slučaja, ovo je već kritična ranjivost. Lakše je presresti poverljive podatke, jer ni ne treba pisati kod za to. 

3. Korišćenje JavaScript biblioteka sa poznatim ranjivostima.

   Tokom skeniranja, najviše korišćena biblioteka postala je jQuery sa širokim spektrom verzija. U svakoj od verzija postoji barem jedna, a ponekad i više poznatih ranjivosti. Uticaj može biti raznolik – zavisi od prirode ranjivosti.

   Kaj je nevarno: Za poznate ranjivosti postoje eksploatacije, na primer:

   
   
   Kaj mora vedeti spletni razvijalec: Redovno se vraćajte u ciklus: pretraga poznatih ranjivosti – otklanjanje – provere. Ako svesno koristite zastarele biblioteke, na primer za podršku starim pregledačima ili zbog uštede budžeta, tražite mogućnosti za otklanjanje poznate ranjivosti. 

4. Međuskriptski napadi (XSS). 
   Cross-Site Scripting (XSS), ali medsebojni skripti, so napadi na spletno aplikacijo, pri katerih se v bazi podatkov pojavi zlonamerna vsebina. Če Qualys odkrije to ranljivost, to pomeni, da lahko potencialni napadalec v kodo spletne strani vnese svojo js-skripto za izvajanje zlonamernih dejanj.

   Shranjeni XSS (Stored XSS) so bolj nevarni, saj se skripta vnese na strežniku in se izvaja vsakič ob odprtju napadene strani v brskalniku.

   Odsekani XSS (Reflected XSS) je lažje izvesti, saj lahko zlonamerna skripta vnese v HTTP-zahtevo. Aplikacija prejme HTTP-zahtevo, ne preveri podatkov, jih zapakira in takoj pošlje. Če napadalec prestreže promet in vnese skripto oblike

   <script>/*+что+то+плохое+*/</script> 

   se bo od odjemalca odšlo zlonamerno zahtevo.

   Odstoten primer XSS: js-snifferji, ki posnemajo strani za vnos CVC, datuma veljavnosti kartice in podobno. 

   Kaj mora vedeti spletni razvijalec: V naslovu Content-Security-Policy uporabite atribut script-src, da brskalnik odjemalca naloži in izvaja le kodo z zaupanja vrednega vira. Na primer, script-src 'self' daje na seznam vseh skriptov le z naše spletne strani. 
   Najboljša praksa je uporaba Inline kode: dovolite le inline javascript s pomočjo vrednosti unsafe-inline. Takšna vrednost dovoli uporabo inline js/css, vendar ne prepoveduje povezovanja js-dokumentov. V kombinaciji s script-src 'self' prepovedujemo izvajanje zunanjih scenarijev.

   Zagotovo beležite vse s pomočjo report-uri in spremljajte poskuse vnosa na spletno stran.

5. SQL-injekcije.
   Ranljivost pomeni možnost vnosa SQL kode na spletno stran, ki se neposredno obrača na bazo podatkov spletne strani. SQL-injekcija je mogoča, če se podatki od uporabnika ne izolirajo: se ne preverjajo za pravilnost in se takoj uporabijo v poizvedbi. Na primer, tako se zgodi, če obrazec na spletni strani ne preveri skladnosti vnosa s tipom podatkov. 

   Kaj je nevarno: Če napadalec vnese SQL-poizvedbo v tak obrazec, lahko uniči bazo podatkov ali razkrije zaupne informacije. 

   Kaj mora vedeti spletni razvijalec: Ne zaupajte tistemu, kar prihaja iz brskalnika. Zaščititi se je treba tako na strani odjemalca kot na strani strežnika. 

   Na strani odjemalca napišite preverjanje polj s pomočjo JavaScript. 

   Vgrajene funkcije v priljubljenih okvirih prav tako pomagajo pri skrivanju sumljivih znakov na strežniku. Na strežniku je prav tako priporočljivo uporabljati parametizirane poizvedbe za baze podatkov.

   Določite, kje natančno prihaja do interakcije z bazo podatkov v spletnem predlogi. 

   Interakcija nastane, ko pridobimo kakršne koli informacije: poizvedba z id (sprememba id), ustvarjanje novega uporabnika, nov komentar – novi vnosi v bazo. Tukaj lahko pride do sql-injekcij. Tudi ko izbrišemo vnos iz baze, je možna sql-injekcija.

Splošna priporočila

Ne izmišljajte kolesa – uporabite preverjene okvire. Na splošno so priljubljeni okviri bolj varni. Za .NET so to ASP.NET MVC in ASP.NET Core, za Python – Django ali Flask, za Ruby – Ruby on Rails, za PHP – Symfony, Laravel, Yii, za JavaScript – Node.JS - Express.js, za Java – Spring MVC.

Spremljajte posodobitve ponudnika in redno posodabljajte. Ranljivost bodo našli, nato написали эксплойт, objavili v javnosti in vse se bo znova ponovilo. Naročite se na posodobitve do stabilnih različic ponudnika programske opreme.

Preverite pravice dostopa. S strani strežnika vedno ravnajte s svojim kodo, kot da je vsa, od prve do zadnje črke, napisana z roko vašega najhujšega sovražnika, ki želi uničiti vašo spletno mesto in kršiti celovitost vaših podatkov. Še posebej, ker je včasih to res tako.

Uporabite klone, testne platforme in šele nato prenesite na produkcijo. To bo pomagalo, najprej, da se izognete napakam in zameram v produktivnem okolju: produktivna okolja prinašajo denar, vsaka zaustavitev produktivnega okolja je kritična. Pri dodajanju, popravljanju ali zapiranju kakšne težave je treba dela izvajati v testnem okolju, nato preveriti funkcionalnost in ugotovljene ranljivosti ter šele nato načrtovati dela v produktivnem okolju. 

Zaščitite spletno aplikacijo s pomočjo Web Application Firewall in integrirajte z njim poročila od skenerja ranljivosti. Na primer, pri DataLine uporabljamo Qualys in FortiWeb kot povezavo storitev.

Izvor: habr.com