Pred približno enim letom smo pri DataLine lansirali za iskanje in analizo ranljivosti v aplikacijah IT. Storitev temelji na oblačni rešitvi Qualys, o delovanju katere . V enem letu dela z rešitvijo smo izvedli 291 pregledov različnih spletnih mest in zbrali statistične podatke o pogostih ranljivostih v spletnih aplikacijah.
V spodnjem članku vam bom natančno pokazal, katere luknje v varnosti spletnih strani se skrivajo za različnimi stopnjami kritičnosti. Oglejmo si, katere ranljivosti je skener našel še posebej pogosto, zakaj se lahko pojavijo in kako se zaščititi.
Qualys vse ranljivosti spletnih aplikacij deli na tri stopnje kritičnosti: nizko, srednjo in visoko. Če pogledate porazdelitev po "resnosti", se zdi, da vse ni tako slabo. Malo je ranljivosti z visoko stopnjo kritičnosti, večinoma vse niso kritične:
Toda nekritično ne pomeni neškodljivo. Lahko povzročijo tudi resno škodo.
Glavne "nekritične" ranljivosti
- Ranljivosti mešane vsebine.
Standard za varnost spletnega mesta je prenos podatkov med odjemalcem in strežnikom prek protokola HTTPS, ki podpira šifriranje in ščiti informacije pred prestrezanjem.
Nekatera spletna mesta uporabljajo mešana vsebina: Nekateri podatki se prenašajo prek nevarnega protokola HTTP. Tako se najpogosteje prenaša pasivne vsebine – informacije, ki vplivajo samo na prikaz spletnega mesta: slike, slogi css. Toda včasih se tako prenaša aktivne vsebine: skripte, ki nadzorujejo vedenje spletnega mesta. V tem primeru lahko s pomočjo posebne programske opreme analizirate informacije z aktivno vsebino, ki prihajajo s strežnika, sproti spreminjate svoje odzive in poskrbite, da stroj deluje tako, kot niso predvideli njegovi ustvarjalci.
Novejše različice brskalnikov opozarjajo uporabnike, da strani z mešano vsebino niso varne, in blokirajo vsebino. Razvijalci spletnih strani prejmejo tudi opozorila brskalnika v konzoli. Na primer, tako je videti v :
Zakaj je nevarno?: Napadalci uporabljajo nevaren protokol za prestrezanje uporabniških informacij, zamenjavo skriptov in pošiljanje zahtev spletnemu mestu v njegovem imenu. Tudi če obiskovalec strani ni vnesel podatkov, ga to ne ščiti pred lažno predstavljanje – pridobivanje zaupnih informacij z goljufivimi metodami. Na primer, s skriptom lahko preusmerite uporabnika na nevarno spletno mesto, ki se izda za uporabnika znanega. V nekaterih primerih je zlonamerna stran videti celo bolje kot izvirnik, uporabnik pa lahko sam izpolni obrazec in odda zaupne podatke.Česa si mora zapomniti spletni razvijalec: Tudi če je skrbnik mesta namestil in konfiguriral potrdilo SSL/TLS, lahko pride do ranljivosti zaradi človeške napake. Na primer, če na eno od strani niste postavili relativne povezave, ampak absolutno povezavo s http, poleg tega pa niste nastavili preusmeritev s http na https.
Z brskalnikom lahko zaznate mešano vsebino na spletnem mestu: poiščite izvorno kodo strani, preberite obvestila v konzoli za razvijalce. Vendar se bo moral razvijalec dolgo in dolgočasno ukvarjati s kodo. Postopek lahko pospešite z orodji za samodejno analizo, na primer: , brezplačna programska oprema Lighthouse ali plačljiva programska oprema Screaming Frog SEO Spider.
Ranljivost lahko nastane tudi zaradi težav z legacy-code – kodo, ki je bila podedovana. Na primer, če so nekatere strani ustvarjene s staro predlogo, ki ne upošteva prehoda spletnih mest na https.
- Piškotki brez zastavic "HTTPOnly" in "secure".
Atribut »HTTPOnly« ščiti piškotke pred obdelavo s skripti, ki jih napadalci uporabljajo za krajo uporabniških podatkov. Zastavica "varno" ne dovoljuje pošiljanja piškotkov v čistem besedilu. Komunikacija bo dovoljena samo, če se za pošiljanje piškotkov uporablja varen protokol HTTPS.
Oba atributa sta navedena v lastnostih piškotka:
Set-Cookie: Secure; HttpOnlyZakaj je nevarno?: Če razvijalec spletnega mesta ni določil teh atributov, bi lahko napadalec prestregel uporabnikove informacije iz piškotka in jih izkoristil. Če se piškotki uporabljajo za avtentikacijo in avtorizacijo, bo lahko ugrabil uporabnikovo sejo in izvajal dejanja na spletnem mestu v njegovem imenu.
Česa si mora zapomniti spletni razvijalec: Praviloma se v priljubljenih okvirih ti atributi nastavijo samodejno. A vseeno preverite konfiguracijo spletnega strežnika in nastavite zastavico: Set-Cookie HttpOnly; Varno.
V tem primeru bo atribut »HTTPOnly« naredil piškotke nevidne za vaš JavaScript.
- Ranljivosti na podlagi poti.
Optični bralnik sporoči takšno ranljivost, če najde javno dostopno datoteko ali imenik spletnega mesta s potencialno zaupnimi informacijami. Na primer, zazna posamezne konfiguracijske datoteke sistema ali dostop do celotnega datotečnega sistema. Ta situacija je možna, če so pravice dostopa na spletnem mestu nepravilno nastavljene.
Zakaj je nevarno?: Če datotečni sistem »štrli«, lahko napadalec pade v vmesnik operacijskega sistema in poskuša najti mape z gesli, če so shranjena v čistem besedilu (ne počnite tega!). Lahko pa ukradete zgoščene vrednosti gesel in geslo nasilno vsilite ter poskusite povečati privilegije v sistemu in se pomakniti globlje v infrastrukturo.
Česa si mora zapomniti spletni razvijalec: Ne pozabite na pravice dostopa in konfigurirajte platformo, spletni strežnik, spletno aplikacijo tako, da ne bo mogoče “pobegniti” iz spletnega imenika.
- Obrazci za vnos občutljivih podatkov z omogočenim samodejnim izpolnjevanjem.
Če uporabnik pogosto izpolnjuje obrazce na spletnih mestih, njegov brskalnik te podatke shrani s funkcijo samodejnega izpolnjevanja.
Obrazci na spletnih mestih lahko vključujejo polja z občutljivimi podatki, kot so gesla ali številke kreditnih kartic. Za takšna polja je vredno onemogočiti funkcijo samodejnega izpolnjevanja obrazcev na samem spletnem mestu.
Zakaj je nevarno?: Če brskalnik uporabnika shrani občutljive podatke, jih lahko napadalec pozneje prestreže, na primer z lažnim predstavljanjem. V bistvu spletni razvijalec, ki je pozabil na to nianso, nastavlja svoje uporabnike.
Česa si mora zapomniti spletni razvijalec: V tem primeru imamo klasičen konflikt: udobje proti varnosti. Če spletni razvijalec razmišlja o uporabniški izkušnji, lahko zavestno izbere samodokončanje. Na primer, če je pomembno slediti – priporočila za dostopnost vsebin za uporabnike invalide.
Za večino brskalnikov lahko onemogočite samodokončanje z atributom autocompete="off", na primer:
<body> <form action="/sl/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>Toda za Chrome ne bo delovalo. To se zaobide z uporabo JavaScripta, različico recepta je mogoče najti .
- Glava X-Frame-Options ni nastavljena v kodi mesta.
Ta glava vpliva na oznake okvirja, iframe, vdelave ali oznake predmeta. Z njegovo pomočjo lahko popolnoma prepovete vdelavo spletnega mesta v okvir. Če želite to narediti, morate podati vrednost X-Frame-Options: deny. Lahko pa določite X-Frame-Options: sameorigin, potem bo vdelava v iframe na voljo samo v vaši domeni.
Zakaj je nevarno?: Odsotnost takšne glave se lahko uporabi na zlonamernih spletnih mestih za clickjacking. Za ta napad napadalec ustvari prozoren okvir na vrhu gumbov in pretenta uporabnika. Na primer: goljufi uokvirijo strani družbenih omrežij na spletnem mestu. Uporabnik misli, da klikne gumb na tem mestu. Namesto tega se klik prestreže in uporabnikova zahteva se pošlje socialnemu omrežju, kjer je aktivna seja. Tako napadalci pošiljajo neželeno pošto v imenu uporabnika ali pridobivajo naročnike in všečke.
Če te funkcije ne onemogočite, lahko napadalec vaš gumb aplikacije postavi na zlonamerno mesto. Morda ga zanima vaš referenčni program ali vaši uporabniki.
Česa si mora zapomniti spletni razvijalec: Ranljivost se lahko pojavi, če so na spletnem strežniku ali uravnalniku obremenitve nastavljene možnosti X-Frame-Options z nasprotujočo si vrednostjo. V tem primeru bosta strežnik in balanser preprosto prepisala glavo, saj imata višjo prioriteto v primerjavi z zaledno kodo.
Vrednosti deny in sameorigin v glavi X-Frame-Options bodo motile delovanje spletnega pregledovalnika Yandex. Če želite omogočiti uporabo iframesov za spletni pregledovalnik, morate v nastavitvah napisati ločeno pravilo. Na primer, za nginx ga lahko konfigurirate takole:
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) ranljivosti.
To je ranljivost v slogu spletnega mesta. Do tega pride, če se za dostop do slogovnih datotek uporabljajo relativne povezave, kot je href="/sl/somefolder/styles.css/". Napadalec bo to izkoristil, če bo našel način, da preusmeri uporabnika na zlonamerno stran. Stran bo v svoj URL vstavila relativno povezavo in simulirala klic slogov. Prejeli boste zahtevo, kot je badsite.ru/…/somefolder/styles.css/, ki lahko izvaja zlonamerna dejanja pod krinko sloga.
Zakaj je nevarno?: Goljuf bi lahko izkoristil to ranljivost, če najde drugo varnostno luknjo. Posledično je možna kraja uporabniških podatkov iz piškotkov ali žetonov.
Česa si mora zapomniti spletni razvijalec: Nastavite glavo X-Content-Type-Options na: nosniff. V tem primeru bo brskalnik preveril vrsto vsebine za sloge. Če je vrsta drugačna od text/css, bo brskalnik blokiral zahtevo.
Kritične ranljivosti
- Stran s poljem za geslo se pošlje s strežnika po nevarnem kanalu (obrazec HTML, ki vsebuje polja za geslo, se postreže prek HTTP).
Odziv strežnika prek nešifriranega kanala je ranljiv za napade »Človek na sredini«. Napadalec lahko prestreže promet in se zagozdi med odjemalcem in strežnikom, ko stran potuje od strežnika do odjemalca.
Zakaj je nevarno?: Goljuf bo lahko zamenjal stran in uporabniku poslal obrazec za zaupne podatke, ki bo šel na napadalčev strežnik.
Česa si mora zapomniti spletni razvijalec: nekatera spletna mesta uporabnikom pošljejo enkratno kodo po e-pošti/telefonu namesto gesla. V tem primeru ranljivost ni tako kritična, vendar bo mehanizem zapletel življenja uporabnikov.
- Pošiljanje obrazca s prijavo in geslom po nevarnem kanalu (obrazec za prijavo ni poslan prek HTTPS).
V tem primeru se obrazec s prijavo in geslom pošlje od uporabnika do strežnika po nešifriranem kanalu.
Zakaj je nevarno?: Za razliko od prejšnjega primera je to že kritična ranljivost. Občutljive podatke je lažje prestreči, ker vam za to sploh ni treba napisati kode.
- Uporaba knjižnic JavaScript z znanimi ranljivostmi.
Med skeniranjem je bila najbolj uporabljena knjižnica jQuery z obsežnim številom različic. Vsaka različica ima vsaj eno ali celo več znanih ranljivosti. Vpliv je lahko zelo različen glede na naravo ranljivosti.
Zakaj je nevarno?: Obstajajo izkoriščanja znanih ranljivosti, na primer:
Česa si mora zapomniti spletni razvijalec: Redno se vračajte v cikel: poiščite znane ranljivosti - popravite - preverite. Če podedovane knjižnice namerno uporabljate, na primer za podporo starejšim brskalnikom ali za prihranek denarja, poiščite priložnost za odpravo znane ranljivosti. - Skriptiranje med spletnimi mesti (XSS).
Cross-Site Scripting (XSS) ali skriptiranje med spletnimi mesti je napad na spletno aplikacijo, ki povzroči vnos zlonamerne programske opreme v bazo podatkov. Če Qualys odkrije takšno ranljivost, to pomeni, da morebitni napadalec lahko ali je že uvedel lasten skript js v kodo spletnega mesta za izvajanje zlonamernih dejanj.Shranjen XSS bolj nevaren, saj je skript vdelan v strežnik in se izvede vsakič, ko se napadena stran odpre v brskalniku.
Odražen XSS lažje izvesti, saj se lahko zlonamerni skript vstavi v zahtevo HTTP. Aplikacija bo prejela zahtevo HTTP, ne bo preverila podatkov, jih bo zapakirala in takoj poslala. Če napadalec prestreže promet in vstavi skript, kot je
<script>/*+что+то+плохое+*/</script>potem bo zlonamerna zahteva poslana v imenu stranke.
Osupljiv primer XSS: js snifferji, ki simulirajo strani za vnos CVC, datuma veljavnosti kartice itd.
Česa si mora zapomniti spletni razvijalec: V glavi Content-Security-Policy uporabite atribut script-src, da odjemalski brskalnik prisilite, da prenese in izvede samo kodo iz zaupanja vrednega vira. Na primer, script-src 'self' doda na seznam dovoljenih samo vse skripte z našega mesta.
Najboljša praksa je vdelana koda: dovoli vgrajeni javascript samo z uporabo vrednosti unsafe-inline. Ta vrednost dovoljuje uporabo vgrajenega js/css, vendar ne prepoveduje vključitve datotek js. V kombinaciji s script-src 'self' onemogočimo izvajanje zunanjih skriptov.Prepričajte se, da vse zabeležite z uporabo report-uri in si oglejte poskuse implementacije na spletno mesto.
- SQL injekcije.
Ranljivost nakazuje možnost vbrizgavanja kode SQL v spletno mesto, ki neposredno dostopa do baze podatkov spletnega mesta. Vbrizgavanje SQL je možno, če podatki uporabnika niso pregledani: ne preveri se njihova pravilnost in se takoj uporabijo v poizvedbi. To se na primer zgodi, če obrazec na spletnem mestu ne preveri, ali se vnos ujema s tipom podatkov.Zakaj je nevarno?: Če napadalec v ta obrazec vnese poizvedbo SQL, lahko zruši bazo podatkov ali razkrije zaupne podatke.
Česa si mora zapomniti spletni razvijalec: Ne zaupajte temu, kar prihaja iz brskalnika. Zaščititi se morate tako na strani odjemalca kot na strani strežnika.
Na strani odjemalca napišite preverjanje polja s pomočjo JavaScripta.
Vgrajene funkcije v priljubljenih okvirih prav tako pomagajo ubežati sumljivim znakom na strežniku. Prav tako je priporočljiva uporaba parametriziranih poizvedb baze podatkov na strežniku.
Ugotovite, kje natanko poteka interakcija z bazo podatkov v spletni aplikaciji.
Do interakcije pride, ko prejmemo kakršnokoli informacijo: zahtevo z id-jem (sprememba id-ja), ustvarjanje novega uporabnika, nov komentar ali nove vnose v bazo. Tukaj lahko pride do vbrizgavanja SQL. Tudi če izbrišemo zapis iz baze, je SQL injekcija možna.
Splošna priporočila
Ne izumljajte kolesa na novo – uporabite preizkušena ogrodja. Priljubljena ogrodja so praviloma varnejša. Za .NET - 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 Javo - Pomladni MVC.
Sledite posodobitvam prodajalcev in jih redno posodabljajte. Našli bodo ranljivost, nato napisali exploit, ga javno objavili in vse se bo ponovilo. Naročite se na posodobitve stabilnih različic prodajalca programske opreme.
Preverite pravice dostopa. Na strani strežnika vedno obravnavajte svojo kodo, kot da jo je od prve do zadnje črke napisal vaš najbolj osovražen sovražnik, ki želi zlomiti vašo spletno stran, kršiti celovitost vaših podatkov. Še več, včasih je to res.
Uporabite klone, testna mesta in jih nato uporabite za proizvodnjo. To bo pomagalo, prvič, preprečiti napake in napake v produktivnem okolju: produktivno okolje prinaša denar, preprosto produktivno okolje je ključnega pomena. Pri dodajanju, popravljanju ali zapiranju katere koli težave je vredno delati v testnem okolju, nato preveriti najdene funkcionalnosti in ranljivosti ter nato načrtovati delo s produkcijskim okoljem.
Zaščitite svojo spletno aplikacijo z in z njim integrirati poročila pregledovalnika ranljivosti. DataLine na primer uporablja Qualys in FortiWeb kot paket storitev.
Vir: www.habr.com