Veebisaidi turvalisuse surmapatud: mida oleme õppinud haavatavuste skaneerimise statistika aastast

Umbes aasta tagasi käivitasime DataLine'is teenus IT-rakendustes haavatavuste otsimise ja analüüsi jaoks. Teenuse aluseks on pilvelahendus Qualys, mille töödest oleme juba rääkinud . Aasta jooksul lahendusega viisime läbi 291 skaneerimist erinevatele veebilehtedele ja kogusime statistikat levinud haavatavuste kohta veebirakendustes.Alljärgnevas artiklis näitan, millised turvaugud veebilehtede taga peituvad erinevate kriitilisuse tasemete taga. Vaatame, milliseid haavatavusi skanner leidis eriti sageli, miks need võivad tekkida ja kuidas end kaitsta. 

Kõiki veebirakenduste haavatavusi jagab Qualys kolmele kriitilisuse tasemele: madal, keskmine ja kõrge. Kui vaadata jaotust 'tõsiduse' järgi, näib, et kõik ei ole sugugi nii hull. Kõrge kriitilisuse tasemega haavatavusi on vähe, enamik on mitte-kriitilised: 

Kuid mitte-kriitilised ei tähenda kahjutud. Need võivad samuti tekitada tõsiseid kahjustusi. 

Top 'mitte-kriitilised' haavatavused 

Sega sisu seotud haavatavused.

1. Veebilehtede turvastandardi kohaselt peaks andmete vahetamine kliendi ja serveri vahel toimuma HTTPS-protokolli kaudu, mis toetab krüpteerimist ja kaitseb teavet pealtkuulamise eest.

   Mõned veebilehed kasutavad 

   segatud sisu : edastavad osa andmeid kaitsmata HTTP-protokolli kaudu. Tihti edastatakse niipassiivne sisu - teave, mis mõjutab ainult veebilehe visualiseerimist: pildid, css-stiilid. Kuid mõnikord edastatakse nii ka aktiivne sisu : skriptid, mis juhivad veebilehe käitumist. Sellisel juhul saab spetsiaalse tarkvara abil analüüsida serverilt tulevat teavet aktiivse sisuga, muuta oma vastuseid reaalajas ja sunnivad masinat töötama nii, nagu selle loojad ei kavandanud.Uute versioonide brauserid hoiatavad kasutajaid, et segatud sisuga veebilehed ei ole turvalised ja blokeerivad sisu. Ka veebilehtede arendajad saavad brauserist konsoolis hoiatusi. Näiteks näeb see välja 

   Millised on ohud Firefox: 

   
   
   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see tedaandmete mahamüümise eest kalastamise eest – konfidentsiaalse teabe vargus petuskeemide kaudu. Näiteks saab skripti abil kasutaja suunata ohtlikule saidile, mis varjub kasutajale tuttava all. Mõnel juhul näeb pahatahtlik sait isegi parem välja kui originaal, ja kasutaja võib ise täita vormi ning edastada konfidentsiaalsed andmed. 

   Mida peab veebiarendaja meeles pidama: Isegi kui saidi administraator on paigaldanud ja konfigureerinud SSL/TLS-sertifikaadi, võib haavatavus ilmneda inimfaktori tõttu. Näiteks kui mõnel lehel on kasutatud absoluutseid linke http kaudu, mitte suhtelisi, ja lisaks ei ole seadistatud suunamisi http-lt https-ile. 

   Segatud sisu tuvastamine saidil on võimalik brauseri abil: otsida lehe lähtekoodist või lugeda arendaja konsoolist teateid. Siiski peab arendaja pikalt ja vaevata koodis kaevama. Protsessi saab kiirendada automatiseeritud analüüsivahendite abil, näiteks: SSL Check, tasuta tarkvara Lighthouse või tasuline programm Screaming Frog SEO Spider.

   Samuti võib haavatavus ilmneda legacy-koodi probleemide tõttu – koodi, mis on jäänud pärandina. Näiteks kui osa lehti genereeritakse vanade mallide järgi, mis ei arvesta saidi üleminekut https-ile.    

2. Küpsised ilma „HTTPOnly“ ja „secure“ liputa.

   Atribuut „HTTPOnly“ kaitseb küpsiseid skriptide töötlemise eest, mida pahatahtlikud isikud kasutavad kasutajaandmete vargusteks. Lipp „secure“ ei luba küpsiseid edastada avatud kujul. Andmevahetus on lubatud ainult siis, kui küpsiste edastamiseks kasutatakse kaitstud protokolli HTTPS. 

   Mõlemad atribuudid määratakse küpsiste omadustes:

   Set-Cookie: Secure; HttpOnly

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Kui saidi arendaja ei ole neid atribuute määranud, võib pahatahtlik isik küpsistest kasutaja teavet haarata ja seda kasutada. Kui küpsiseid kasutatakse autentimiseks ja autoriseerimiseks, saab ta kasutaja seansi varastada ja teha toiminguid saidil tema nimel. 

   Mida peab veebiarendaja meeles pidama: Reeglina määratakse need atribuudid populaarsetes raamistikes automaatselt. Kuid siiski kontrollige veebiserveri konfiguratsiooni ja seadistage lipp: Set-Cookie HttpOnly; Secure.

   Samal ajal muudab atribuut „HTTPOnly“ küpsised nähtamatuks ka teie enda JavaScriptile.  

3. Path-Based Vulnerabilities („rada põhinevad“ haavatavused).

   Skanner teatab sellisest haavatavusest, kui leiab avalikult ligipääsetava faili või veebisaidi kausta, kus võib olla potentsiaalselt konfidentsiaalne teave. Näiteks tuvastab see eraldi süsteemi konfiguratsioonifailid või juurdepääsu kogu failisüsteemile. Selline olukord võib tekkida, kui veebisaidil on vale ligipääsuõiguste seadistamine.

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Kui failisüsteem "paistab välja", võivad pahatahtlikud isikud pääseda operatsioonisüsteemi liidesesse ja proovida leida kaustu, kus on hoitud paroole, kui need on avatud kujul (ärge tehke seda!). Või on võimalik varastada paroolide räsimärgid ja proovida parooli välja nuputada, samuti püüda tõsta privileege süsteemis ja edasiviia infrastruktuuri.  

   Mida peab veebiarendaja meeles pidama: Ärge unustage ligipääsuõigusi ja seadistage platvorm, veebiserver ja veebirakendus nii, et ei saaks "põgeneda" veebikaustast.

4. Konfidentsiaalsete andmete sisestamise vormid koos automaatse täitmise funktsiooniga.

   Kui kasutaja täidab sagedasti veebilehtedel vorme, salvestab tema brauser selle teabe automaatse täitmise funktsiooni abil. 

   Veebilehtedel olevad vormid võivad sisaldada konfidentsiaalse teabe välju, näiteks paroole või krediitkaardinumbrid. Selliste väljade puhul tuleks veebisaidil automaatse täitmise funktsioon välja lülitada. 

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Kui kasutaja brauser salvestab konfidentsiaalset teavet, võivad pahatahtlikud isikud selle hiljem näiteks kalapüügi abil hankida. Tegelikult paneb veebiarendaja, kes seda nüanssi unustab, oma kasutajad ohtu. 

   Mida peab veebiarendaja meeles pidama: Sel juhul seisame silmitsi klassikalise konfliktiga: mugavus vs turvalisus. Kui veebiarendaja mõtleb kasutaja mugavusele, võib ta teadlikult valida automaatse täitmise. Näiteks kui on oluline järgida Veebisisu kergesti ligipääsetavuse juhised – soovitused, kuidas tagada sisu ligipääsetavus liikuvate piirangutega kasutajatele. 

   Enamikus brauserites saab automaatse täitmise välja lülitada atribuudiga autocompete="off", näiteks:

    <body>
       <form action="/et/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit">
         <div>
           <input type="text" placeholder="Eesnimi">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Perekonnanimi" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Krediitkaardi number">
         </div>
         <input type="submit">
       <input type="hidden" name="trp-form-language" value="et"/></form>
     </body>

   Aga Chrome'is see ei tööta. Seda ümbersõitu tehakse JavaScriptiga, retsepti variandi leiate siin. 

5. Veebisaidi koodis ei ole määratud pealkirja X-Frame-Options. 

   See pealkiri mõjutab frame, iframe, embed või object silte. Selle abil saab täielikult keelata oma saidi integreerimise frami sisse. Selleks tuleb määrata väärtus X-Frame-Options: deny. Või võib määrata X-Frame-Options: sameorigin, siis on iframe integreerimine lubatud ainult teie domeenis.

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Sellise pealkirja puudumist saab kasutada pahatahtlikes saitides klikivarguste. Sellise rünnaku puhul loob kurjategija läbipaistva frami nuppude kohal ja petab kasutajat. Näiteks: petised paigutavad frami saidile sotsiaalmeedia lehti. Kasutaja arvab, et klõpsab sellel saidil nuppudel. Tegelikult püütakse klikk kinni ja saadetakse kasutaja päring sotsiaalmeediasse, kus on aktiivne sessioon. Nii saadavad kurjategijad rämpsposti kasutaja nimel või suurendavad tellijaid ja meeldimisi. 

   Kui seda võimalust ei keelata, võib kurjategija paigutada teie rakenduse nupu pahatahtlikule saidile. Ta võib olla huvitatud teie suunamisprogrammist või teie kasutajatest.  

   Mida peab veebiarendaja meeles pidama: Haavatavus võib ilmneda, kui X-Frame-Options on konflikti väärtusega määratud veebiserverisse või koormuse tasakaalustajasse. Sellisel juhul lihtsalt server ja koormuse tasakaalustaja kirjutavad pealkirja üle, kuna neil on kõrgem prioriteet võrreldes tagasiside koodiga.  

   X-Frame-Options väärtused deny ja sameorigin segavad Yandexi veebivaatleja tööd. Iframe'i kasutamise lubamiseks veebivaatleja jaoks tuleb kirjutada seades eraldi reegel. Näiteks nginx-i jaoks saab seadistada selliselt:

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

6. PRSSI (Path-relative stylesheet import) haavatavused.  

   See on haavatavus saidi stiilides. See tekib, kui stiilifailide juurde pääsemiseks kasutatakse suhtelisi linke nagu href="/somefolder/styles.css/". Kurjategija kasutab seda ära, kui leiab viisi, kuidas suunata kasutaja pahatahtlikule lehele. Leht paneb oma url-i suhtelise lingi ja imiteerib stilide juurde pääsemist. Saame päringu nagu badsite.ru/.../somefolder/styles.css/, mis stiiline näiliselt võib teha pahatahtlikke tegusid. 

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Petukate võib seda haavatavust kasutada, kui ta leiab veel ühe turvaaugu. Selle tulemuseks on võimalik varastada kasutajaandmeid küpsistest või token'itest.

   Mida peab veebiarendaja meeles pidama: Seadke pealkiri X-Content-Type-Options: nosniff. Sellisel juhul kontrollib brauser sisu tüüpi stiilide jaoks. Kui tüüp erineb text/css-st, blokeerib brauser päringu.

Kriitilised haavatavused

1. Paroolivälja sisaldav leht edastatakse serverist kaitsmata kanali kaudu (HTML vorm, mis sisaldab parooli välju, edastatakse HTTP kaudu).

   Serveri vastus kaitsmata kanalil on haavatav rünnakute, nagu 'Man in the middle', suhtes. Ründaja võib liikluse kinni püüda ja süstida end kliendi ja serveri vahele, kui leht liigub serverist kliendile. 

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Petukate võib lehte küsida ja saata kasutajale vormi konfidentsiaalsete andmete jaoks, mis edastatakse ründaja serverisse. 

   Mida peab veebiarendaja meeles pidama: Mõned saidid saadavad kasutajatele parooli asemel ühekordse koodi e-posti/telefoni teel. Sellisel juhul ei ole haavatavus nii kriitiline, kuid mehhanism raskendab kasutajate elu.

2. Sisselogimisvormi edastamine kaitsmata kanali kaudu (Login Form Is Not Submitted Via HTTPS).

   Selle juhtumi korral saadetakse kasutajalt serverisse kaitsmata kanali kaudu vorm sisselogimise ja parooli jaoks.

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Erinevalt eelmisest juhtumist on see juba kriitiline haavatavus. Konfidentsiaalsete andmete püüdmine on lihtsam, kuna selleks pole isegi vajalik koodi kirjutamine. 

3. JavaScript'i teekide kasutamine, kus on teadaolevaid haavatavusi.

   Skaneerimise ajal on enimkasutatud teegiks saanud jQuery, millel on lai versioonide spekter. Igas versioonis on vähemalt üks, kui mitte rohkem, teadaolevat haavatavust. Mõju võib olla väga erinev – see sõltub haavatavuse olemusest.

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Teadaolevate haavatavuste jaoks on olemas eksploidid, näiteks:

   
   
   Mida peab veebiarendaja meeles pidama: Tagasi tulge regulaarselt tsüklisse: teadaolevate haavatavuste otsimine – kõrvaldamine – kontrollimine. Kui kasutate tahtlikult vananenud teeke, näiteks vanade brauserite toe või eelarve kokkuhoiu jaoks, otsige võimalust kõrvaldada teadaolev haavatavus. 

4. Kcross-site scripting (XSS). 
   Cross-Site Scripting (XSS) ehk ristveebi skriptid on rünnakud veebirakendusele, mille tulemuseks on andmebaasi ilmumine pahatahtlikku koodi. Kui Qualys tuvastab sellise haavatavuse, võib potentsiaalne ründaja sisestada või on juba sisestanud oma js-skripti saidi koodi pahatahtlike toimingute teostamiseks.

   Salvestatud XSS (Stored XSS) on ohtlikumad, kuna skript paigutatakse serverisse ja käivitatakse iga kord, kui ründatud lehte brauseris avatakse.

   Peegeldatud XSS (Reflected XSS) on lihtsamini teostatav, kuna pahatahtlikku skripti saab sisestada HTTP-päringusse. Rakendus saab HTTP-päringu, ei kontrolli andmeid, pakib need kokku ja saadab kohe edasi. Kui ründaja tabab liiklust ja lisab skripti kujul

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

   , väljub pahatahtlik päring kliendi nimel.

   Silmapaistev näide XSS-ist: js-snifferid, mis imiteerivad lehti CVC, kaardi aegumistähtaja ja muu sarnase sisestamiseks. 

   Mida peab veebiarendaja meeles pidama: Content-Security-Policy päises kasutage script-src atribuuti, et kliendi brauser laadiks ja käivitaks koodi ainult usaldusväärsest allikast. Näiteks script-src 'self' lubab ainult meie saidilt pärinevaid skripte. 
   Parim praktika on Inline code: lubage ainult inline javascript väärtusega unsafe-inline. See väärtus lubab inline js/css kasutamist, kuid ei keela js-failide ühendamist. Koos script-src 'self' külge keeldume väliste skriptide käivitamisest.

   Veenduge, et logite kõik report-uri abil ja jälgige saidi sissetungi katseid.

5. SQL-injektsioonid.
   Haavatavus viitab SQL koodi sisestamise võimalusele, mis pöördub otse saidi andmebaasi. SQL-injektsioon on võimalik, kui kasutaja andmeid ei filtreerita: neid ei kontrollita õiguse ja kohe kasutatakse päringus. Näiteks juhtub see, kui saidi vorm ei kontrolli sisendi vastavust andmetüübile. 

   : Kurjategijad kasutavad kaitsmata protokolli, et pealt kuulata kasutaja teavet, asendada skripte ja saata saidile päringuid selle nimel. Isegi kui veebilehe külastaja ei sisestanud andmeid, ei kaitse see teda: Kui ründaja sisestab sellesse vormi SQL-päringu, võib ta andmebaasi kokku kukutada või konfidentsiaalset teavet avaldada. 

   Mida peab veebiarendaja meeles pidama: Ärge usaldage seda, mis tuleb brauserist. Kaitseks peab olema nii kliendi kui ka serveri poolel. 

   Kliendi poolel kirjutage väljade kontrollimiseks JavaScript. 

   Populaarsed raamistike sisseehitatud funktsioonid aitavad samuti serveris kahtlasi märke ekraanida. Serveris on soovitatav kasutada ka parameetritega päringuid andmebaasidele.

   Määrake, kus täpselt toimub andmebaasiga interaktsioon veebirakenduses. 

   Interaktsioon toimub, kui saame mingit teavet: päring id (id vahetus), uue kasutaja loomine, uus kommentaar – uued kirjed andmebaasis. Siin võivad esineda sql-injekte. Isegi kui eemaldame kirje andmebaasist, on sql-injektsioon võimalik.

General recommendations

Ärge leiutage ratast – kasutage tõestatud raamistikke.. Enamasti on populaarsed raamistike versioonid turvalisemad. .NET jaoks on see 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 Spring MVC.

Jälgige tarnija uuendusi ja uuendage regulaarselt.. Turvaauk avastatakse, seejärel kirjutatakse selle jaoks eksploit, levitatakse avalikult ja kõik kordub. Liituge stabiilsete versioonide uuendustega tarkvara tarnijalt.

Kontrollige juurdepääsuõigusi.. Serveri poolt vaadates suhelge oma koodiga nii, nagu oleks kogu see, esimesest kuni viimase täheni, kirjutatud teie kõige vihatum vaenlane, kes soovib teie saiti purustada ja teie andmete terviklikkust rikkuda. Eriti kuna mõnikord on see tõesti nii.

Kasutage kloone, testplaasid ja seejärel rakendage need tootmisse.. See aitab, esiteks, vältida võimalikke vigu ja probleeme tootmiskeskkonnas: tootmiskeskkond teenib raha, tootmiskeskkonna seiskamine on kriitiline. Probleemide lisamisel, parandamisel või sulgemisel on soovitatav töötada testkeskkonnas, seejärel kontrollida funktsionaalsust ja leitud haavatavusi ning alles seejärel planeerida tööd tootmiskeskkonnas. 

Kaitske veebirakendust Veebirakenduse tulemüüriga ja integreerige selle juurde haavatavuste skänneri raportid.. Näiteks DataLine'is kasutatakse teenuste sidumiseks Qualys ja FortiWeb.

Allikas: habr.com