Umbes aasta tagasi käivitasime DataLine'is IT-rakenduste haavatavuste otsimiseks ja analüüsimiseks. Teenus põhineb Qualys pilvelahendusel, mille toimimise kohta . Aasta jooksul, mil lahendusega töötasime, tegime erinevate saitide jaoks 291 skannimist ja kogusime statistikat veebirakenduste levinumate turvaaukude kohta.
Allolevas artiklis näitan teile täpselt, millised augud veebisaidi turvalisuses on erinevate kriitilisuse tasemete taga peidus. Vaatame, milliseid turvaauke skanner eriti sageli leidis, miks need tekkida võivad ja kuidas end kaitsta.
Qualys jagab kõik veebirakenduste haavatavused kolmeks kriitilisuse tasemeks: madal, keskmine ja kõrge. Kui vaadata jaotust “raskusastme” järgi, siis tundub, et kõik polegi nii hull. Kõrge kriitilisuse tasemega turvaauke on vähe, enamasti on kõik mittekriitilised:
Kuid kriitikavaba ei tähenda kahjutut. Need võivad põhjustada ka tõsist kahju.
Peamised "mittekriitilised" haavatavused
- Sega sisuga haavatavused.
Veebisaidi turvalisuse standard on andmete edastamine kliendi ja serveri vahel HTTPS-protokolli kaudu, mis toetab krüptimist ja kaitseb teavet pealtkuulamise eest.
Mõned saidid kasutavad segatud sisu: Osa andmeid edastatakse ebaturvalise HTTP-protokolli kaudu. Nii edastatakse seda kõige sagedamini passiivne sisu – teave, mis mõjutab ainult saidi kuvamist: pildid, css-stiilid. Kuid mõnikord edastatakse see nii aktiivne sisu: skriptid, mis juhivad saidi käitumist. Sel juhul saab spetsiaalse tarkvara abil analüüsida serverist tuleva aktiivse sisuga infot, käigupealt oma vastuseid muuta ja masinat tööle panna viisil, mis pole selle loojate poolt ette nähtud.
Brauserite uuemad versioonid hoiatavad kasutajaid, et segasisuga saidid ei ole turvalised ja blokeerivad sisu. Veebilehtede arendajad saavad konsoolis ka brauseri hoiatusi. Näiteks see näeb välja selline :
Miks see ohtlik on?: ründajad kasutavad kasutajateabe pealtkuulamiseks, skriptide asendamiseks ja tema nimel saidile päringute saatmiseks ebaturvalist protokolli. Isegi kui saidi külastaja andmeid ei sisestanud, ei kaitse see teda selle eest andmepüügi – konfidentsiaalse teabe hankimine pettuse teel. Näiteks saate skripti kasutades suunata kasutaja ümber ebaturvalisele saidile, mis maskeerub kasutajale tuttavaks. Mõnel juhul näeb pahatahtlik sait isegi parem välja kui originaal ning kasutaja saab ise vormi täita ja konfidentsiaalseid andmeid esitada.Mida peaks veebiarendaja meeles pidama: isegi kui saidi administraator on installinud ja konfigureerinud SSL/TLS-sertifikaadi, võib inimliku vea tõttu tekkida haavatavus. Näiteks kui panite ühele lehele mitte suhtelise lingi, vaid absoluutse lingi http-st ja lisaks ei seadistanud te ümbersuunamisi http-lt https-i.
Saate tuvastada saidil segatud sisu brauseri abil: otsige lehe lähtekoodi, lugege arendajakonsoolis teateid. Arendaja peab aga koodiga pikalt ja tüütult nokitsema. Protsessi saate kiirendada näiteks automatiseeritud analüüsitööriistadega: , tasuta Lighthouse tarkvara või tasuline tarkvara Screaming Frog SEO Spider.
Samuti võib haavatavus tekkida probleemide tõttu pärandkoodiga – päriliku koodiga. Näiteks kui mõned lehed on loodud vana malli abil, mis ei võta arvesse saitide üleminekut https-ile.
- Küpsised ilma lipukeste "HTTOnly" ja "Secure"ta.
Atribuut "HTTOnly" kaitseb küpsiseid skriptide töötlemise eest, mida ründajad kasutavad kasutajaandmete varastamiseks. "Turvaline" lipp ei luba küpsiseid selge tekstina saata. Side on lubatud ainult siis, kui küpsiste saatmiseks kasutatakse turvalist HTTPS-protokolli.
Mõlemad atribuudid on määratud küpsise atribuutides:
Set-Cookie: Secure; HttpOnlyMiks see ohtlik on?: kui saidi arendaja ei määranud neid atribuute, võib ründaja küpsisest kasutaja teabe kinni püüda ja seda ära kasutada. Kui autentimiseks ja autoriseerimiseks kasutatakse küpsiseid, saab ta kasutaja seansi kaaperdada ja tema nimel saidil toiminguid teha.
Mida peaks veebiarendaja meeles pidama: Reeglina määratakse populaarsetes raamistikes need atribuudid automaatselt. Kuid siiski kontrollige veebiserveri konfiguratsiooni ja määrake lipp: Set-Cookie HttpOnly; Turvaline.
Sel juhul muudab atribuut „HTTOnly” küpsised teie enda JavaScripti jaoks nähtamatuks.
- Teepõhised haavatavused.
Skänner teatab sellisest haavatavusest, kui leiab potentsiaalselt konfidentsiaalset teavet sisaldava avalikult juurdepääsetava faili või veebisaidi kataloogi. Näiteks tuvastab see üksikuid süsteemi konfiguratsioonifaile või juurdepääsu kogu failisüsteemile. See olukord on võimalik, kui juurdepääsuõigused on saidil valesti seadistatud.
Miks see ohtlik on?: Kui failisüsteem "torkab välja", võib ründaja sattuda operatsioonisüsteemi liidesesse ja proovida leida paroolidega kaustu, kui need on salvestatud selge tekstina (ärge tehke seda!). Või võite varastada parooliräsi ja parooli jõhkralt sundida ning samuti proovida süsteemis privileege tõsta ja infrastruktuuri sügavamale liikuda.
Mida peaks veebiarendaja meeles pidama: Ärge unustage juurdepääsuõigusi ja konfigureerige platvorm, veebiserver, veebirakendus nii, et veebikataloogist pole võimalik "põgeneda".
- Vormid tundlike andmete sisestamiseks, kui automaatne täitmine on lubatud.
Kui kasutaja täidab veebisaitidel sageli vorme, salvestab tema brauser selle teabe automaatse täitmise funktsiooni abil.
Veebisaitidel olevad vormid võivad sisaldada tundlikku teavet (nt paroole või krediitkaardinumbreid) sisaldavaid välju. Selliste väljade puhul tasub saidil endal vormide automaatse täitmise funktsioon keelata.
Miks see ohtlik on?: kui kasutaja brauser salvestab tundlikku teavet, saab ründaja selle hiljem kinni püüda, näiteks andmepüügi kaudu. Sisuliselt seadistab selle nüansi unustanud veebiarendaja oma kasutajaid.
Mida peaks veebiarendaja meeles pidama: Sel juhul on meil klassikaline konflikt: mugavus vs turvalisus. Kui veebiarendaja mõtleb kasutajakogemusele, võib ta teadlikult valida automaatse täitmise. Näiteks kui on oluline järgida – soovitused sisule puuetega kasutajatele juurdepääsetavaks.
Enamiku brauserite puhul saate automaatse täitmise atribuudiga autocompete="off" keelata, näiteks:
<body> <form action="/et/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>Kuid see ei tööta Chrome'i jaoks. Sellest saab mööda JavaScripti abil, retsepti variandi leiate .
- Päis X-Frame-Options ei ole saidi koodis määratud.
See päis mõjutab raami, iframe, manustamise või objekti silte. Selle abiga saate täielikult keelata saidi manustamise raami sisse. Selleks tuleb määrata väärtus X-Frame-Options: deny. Või võite määrata X-Frame-Options: sameorigin, siis on iframe'i manustamine saadaval ainult teie domeenis.
Miks see ohtlik on?: Sellise päise puudumist saab kasutada pahatahtlikel saitidel klõpsamine. Selle rünnaku jaoks loob ründaja nuppude peale läbipaistva raami ja petab kasutajat. Näiteks: petturid raamivad veebisaidi sotsiaalvõrgustike lehti. Kasutaja arvab, et klõpsab sellel saidil nuppu. Selle asemel püütakse klikk kinni ja kasutaja päring saadetakse sotsiaalvõrgustikku, kus on aktiivne seanss. Nii saadavad ründajad kasutaja nimel rämpsposti või saavad tellijaid ja meeldimisi.
Kui te seda funktsiooni ei keela, võib ründaja paigutada teie rakenduse nupu pahatahtlikule saidile. Ta võib olla huvitatud teie soovitusprogrammist või teie kasutajatest.
Mida peaks veebiarendaja meeles pidama: haavatavus võib ilmneda, kui veebiserveris või koormuse tasakaalustajas on seadistatud vastuolulise väärtusega X-Frame-Options. Sel juhul kirjutavad server ja tasakaalustaja lihtsalt päise ümber, kuna neil on taustakoodiga võrreldes kõrgem prioriteet.
Päise X-Frame-Options keelamise ja sama päritolu väärtused häirivad Yandexi veebivaaturi tööd. Et lubada veebivaaturis iframe’ide kasutamist, tuleb seadistustesse kirjutada eraldi reegel. Näiteks nginxi jaoks saate selle konfigureerida järgmiselt:
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) haavatavused.
See on haavatavus saidi stiilis. See juhtub siis, kui laadifailidele juurdepääsuks kasutatakse suhtelisi linke, nagu href="/et/somefolder/styles.css/". Ründaja kasutab seda ära, kui leiab viisi, kuidas kasutaja pahatahtlikule lehele ümber suunata. Leht lisab oma URL-i suhtelise lingi ja simuleerib stiilikutset. Saate taotluse nagu badsite.ru/…/somefolder/styles.css/, mis võib stiili varjus sooritada pahatahtlikke toiminguid.
Miks see ohtlik on?: Pettur võib seda haavatavust ära kasutada, kui leiab uue turvaaugu. Selle tulemusena on võimalik varastada kasutajaandmeid küpsistest või žetoonidest.
Mida peaks veebiarendaja meeles pidama: määrake X-Content-Type-Options päises: nosniff. Sel juhul kontrollib brauser stiilide sisutüüpe. Kui tüüp on muu kui text/css, blokeerib brauser päringu.
Kriitilised haavatavused
- Parooliväljaga leht edastatakse serverist ebaturvalise kanali kaudu (paroolivälja(sid) sisaldav HTML-vorm edastatakse HTTP kaudu).
Serveri vastus krüptimata kanali kaudu on haavatav rünnakute "Mees keskel" suhtes. Ründaja võib liiklust kinni pidada ja kiiluda kliendi ja serveri vahele, kui leht liigub serverist kliendini.
Miks see ohtlik on?: Pettur saab lehe asendada ja saata kasutajale konfidentsiaalsete andmete vormi, mis saadetakse ründaja serverisse.
Mida peaks veebiarendaja meeles pidama: mõned saidid saadavad kasutajatele parooli asemel ühekordse koodi meili/telefoni teel. Sel juhul pole haavatavus nii kriitiline, kuid mehhanism muudab kasutajate elu keeruliseks.
- Vormi saatmine sisselogimise ja parooliga ebaturvalise kanali kaudu (sisselogimisvormi ei saadeta HTTPS-i kaudu).
Sel juhul saadetakse kasutajalt krüptimata kanali kaudu serverisse vorm koos sisselogimise ja parooliga.
Miks see ohtlik on?: Erinevalt eelmisest juhtumist on see juba kriitiline haavatavus. Tundlike andmete pealtkuulamine on lihtsam, sest selleks ei pea te isegi koodi kirjutama.
- Tuntud haavatavustega JavaScripti teekide kasutamine.
Skaneerimise ajal oli enim kasutatud teek jQuery suure hulga versioonidega. Igal versioonil on vähemalt üks või isegi mitu teadaolevat turvaauku. Sõltuvalt haavatavuse olemusest võib mõju olla väga erinev.
Miks see ohtlik on?: teadaolevate haavatavuste jaoks on ärakasutamine, näiteks:
Mida peaks veebiarendaja meeles pidama: naaske regulaarselt tsüklisse: otsige teadaolevaid turvaauke - parandage - kontrollige. Kui kasutate pärandteeke tahtlikult, näiteks vanemate brauserite toetamiseks või raha säästmiseks, otsige võimalust teadaoleva haavatavuse parandamiseks. - Saididevaheline skriptimine (XSS).
Cross-Site Scripting (XSS) ehk saitidevaheline skriptimine on rünnak veebirakenduse vastu, mille tulemusel sisestatakse andmebaasi pahavara. Kui Qualys sellise haavatavuse leiab, tähendab see, et potentsiaalne ründaja saab või on juba pahatahtlike toimingute tegemiseks saidi koodi sisestanud oma js-skripti.Salvestatud XSS ohtlikum, kuna skript on serverisse manustatud ja käivitatakse iga kord, kui rünnatud leht brauseris avatakse.
Peegeldunud XSS lihtsam teostada, kuna HTTP-päringusse saab sisestada pahatahtliku skripti. Rakendus saab HTTP päringu, ei valideeri andmeid, pakendab need ja saadab kohe. Kui ründaja peatab liikluse ja lisab skripti nagu
<script>/*+что+то+плохое+*/</script>siis saadetakse kliendi nimel pahatahtlik päring.
Silmatorkav näide XSS-ist: js-nuusutajad, mis simuleerivad lehti CVC, kaardi aegumiskuupäeva ja nii edasi sisestamiseks.
Mida peaks veebiarendaja meeles pidama: Kasutage päises Content-Security-Policy atribuuti script-src, et sundida kliendibrauserit alla laadima ja käivitama ainult usaldusväärsest allikast pärinevat koodi. Näiteks lisab script-src 'self' kõik meie saidi skriptid lubatud loendisse.
Parim tava on tekstisisene kood: lubage ainult tekstisisene javascript, mis kasutab unsafe-inline väärtust. See väärtus lubab kasutada tekstisiseseid js/css-i, kuid ei keela js-failide kaasamist. Koos script-src 'self'-ga keelame väliste skriptide täitmise.Logige kindlasti kõik report-uri abil sisse ja vaadake katseid seda saidile rakendada.
- SQL-i süstid.
Haavatavus viitab võimalusele süstida SQL-koodi veebisaidile, mis pääseb otse veebisaidi andmebaasi. SQL-i sisestamine on võimalik, kui kasutaja andmeid ei sõeluta: nende õigsust ei kontrollita ja seda kasutatakse kohe päringus. Näiteks juhtub see siis, kui veebisaidi vorm ei kontrolli, kas sisend vastab andmetüübile.Miks see ohtlik on?: kui ründaja sisestab sellele vormile SQL-päringu, võib ta andmebaasi kokku kukkuda või avaldada konfidentsiaalset teavet.
Mida peaks veebiarendaja meeles pidama: Ärge usaldage seda, mis brauserist tuleb. Peate end kaitsma nii kliendi kui ka serveri poolel.
Kliendi poolel kirjutage JavaScripti abil välja valideerimine.
Populaarsete raamistike sisseehitatud funktsioonid aitavad ka serveris kahtlastest tegelastest põgeneda. Samuti on soovitatav serveris kasutada parameetritega andmebaasipäringuid.
Määrake täpselt, kus veebirakenduses andmebaasiga suhtlemine toimub.
Interaktsioon toimub siis, kui saame mistahes infot: päring id-ga (id muutmine), uue kasutaja loomine, uus kommentaar või uued kanded andmebaasi. Siin võivad tekkida SQL-i süstid. Isegi kui kustutame kirje andmebaasist, on SQL-i süstimine võimalik.
Üldised soovitused
Ärge leiutage jalgratast uuesti – kasutage tõestatud raamistikke. Reeglina on populaarsed raamistikud turvalisemad. NET jaoks - ASP.NET MVC ja ASP.NET Core, Python jaoks - Django või Flask, Ruby jaoks - Ruby on Rails, PHP jaoks - Symfony, Laravel, Yii, JavaScripti jaoks - Node.JS-Express.js, Java jaoks - Kevad MVC.
Jälgige tarnija värskendusi ja värskendage neid regulaarselt. Nad leiavad haavatavuse, kirjutavad siis ärakasutamise, teevad selle avalikult kättesaadavaks ja kõik kordub. Tellige tarkvaratootja stabiilsete versioonide värskendused.
Kontrollige juurdepääsuõigusi. Serveri poolel käsitlege oma koodi alati nii, nagu oleks selle esimesest kuni viimase täheni kirjutanud teie vihatuim vaenlane, kes soovib teie saiti murda ja teie andmete terviklikkust rikkuda. Pealegi on see mõnikord tõsi.
Kasutage kloone, testimiskohti ja seejärel kasutage neid tootmiseks. See aitab esiteks vältida vigu ja vigu tootlikus keskkonnas: produktiivne keskkond toob raha, lihtne produktiivne keskkond on kriitiline. Iga probleemi lisamisel, parandamisel või sulgemisel tasub töötada testkeskkonnas, seejärel kontrollida leitud funktsionaalsust ja nõrku kohti ning seejärel planeerida tootmiskeskkonnaga töötamist.
Kaitske oma veebirakendust ja integreerida sellega haavatavuse skanneri aruanded. Näiteks DataLine kasutab Qualysi ja FortiWebi teenuste kogumina.
Allikas: www.habr.com