Veebisaidi turvalisuse surmavad patud: mida me õppisime aasta jooksul haavatavuste skanneri statistikast

Umbes aasta tagasi alustasime DataLine'is teenus IT-rakenduste haavatavuste otsimiseks ja analüüsimiseks. Teenuse aluseks on Qualyse pilvelahendus, mille töö kohta oleme juba rääkinud. Aasta jooksul lahenduse kasutamisel skaneerisime 291 erinevat saiti ja kogusime statistikat levinud haavatavuste kohta veebirakendustes. 

Allolevas artiklis näitan, millised turvavead peidavad end erinevate kriitilisuse tasemete taga. Vaatame, milliseid haavatavusi skanner eriti sageli leidis, miks need võivad tekkida ja kuidas end kaitsta. 

Qualys jagab veebirakenduste haavatavused kolmele kriitilisuse tasemele: madal, keskmine ja kõrge. Kui vaadata „raskeuse” jaotust, tundub, et kõik pole nii hullud. Kõrge kriitilisuse taseme haavatavusi on vähe, enamik on mitte-kritilised: 

Kuid mitte-kritilised – ei tähenda ohutud. Need võivad samuti tekitada tõsist kahju. 

Tipp „mitte-kritilised” haavatavused

1. Segatud sisu seotud haavatavused.

   Veebisaitide tur标准 tähistab andmete edastust kliendi ja serveri vahel HTTPS-protokolli kaudu, mis toetab krüpteerimist ja kaitseb teavet pealtkuulamise eest. 

   Mõned veebisaidid kasutavad segatud sisu: edastavad osa andmeid kaitsmata HTTP-protokolli kaudu. Tihti edastatakse nii passiivset sisu – teavet, mis mõjutab ainult saidi kuvamist: pildid, CSS-stiilid. Kuid mõnikord edastatakse nii ka aktiivne sisu: skriptid, mis juhtivad saidi käitumist. Sellisel juhul on võimalus spetsiaalse tarkvara abil analüüsida serverist saabuvat teavet aktiivse sisuga, reaalajas oma vastuseid muuta ja sundida masinat toimima viisil, nagu selle loojad ei olnud ette näinud. 

   Uute versioonide brauserid hoiatavad kasutajaid, et segatud sisu sisaldavad saidid ei ole turvalised ja blokeerivad sisu. Veebiarendajad saavad ka brauseri konsoolilt teateid. Näiteks, nii see välja näeb Firefox: 

   
   
   Miks see on ohtlik: Kurikaalased kasutavad kaitsmata protokolli, et varastada kasutaja teavet, asendada skripte ja saata päringuid saidile tema nimel. Isegi kui saidi külastaja ei sisestanud andmeid, ei kaitse see teda phisingu – konfidentsiaalse teabe hankimine petuskeemide abil. Näiteks saab skripti abil suunata kasutaja ohtlikule veebisaidile, mis maskeerib end tuttava saidina. Teatud juhtudel näeb pahatahtlik sait isegi parem välja kui originaal, ning kasutaja võib ise täita vormi ja edastada konfidentsiaalsed andmed. 

   Mida peaks veebiarendaja meeles pidama: Isegi kui saidi administraator on installinud ja seadistanud SSL/TLS-sertifikaadi, võib haavatavus tekkida inimfaktori tõttu. Näiteks, kui mõnel lehel on kasutatud mitte suhtelist linki, vaid absoluutset http-ga linki, ja lisaks ei ole seadistatud suunamisi http-lt https-ile. 

   Segatud sisu avastamiseks veebilehelt saab kasutada brauserit: otsida lehe allikakoodist, lugeda arendaja konsooli teateid. Siiski peab arendaja pika ja tüütava koodiga tegelema. Protsessi saab kiirendada automatiseeritud analüüsivahenditega, näiteks: SSL Kontroll, avatud lähtekoodiga tarkvara Lighthouse või tasuline tarkvara Screaming Frog SEO Spider.

   Samuti võib haavatavus tekkida vanade koodide tõttu – koodist, mis on jäänud pärandiks. Näiteks, kui osa lehtedest genereeritakse vanast mallist, kus ei arvestata veebilehtede üleminekut HTTPS-ile.    

2. Küpsised ilma 'HTTPOnly' ja 'secure' lippudeta.

   Atribuut 'HTTPOnly' kaitseb küpsiseid skriptide eest, mida kurjategijad kasutavad kasutajate andmete varastamiseks. 'Secure' lipp ei luba küpsiste edastamist avatud kujul. Andmete vahetamine on lubatud ainult siis, kui küpsiste edastamiseks kasutatakse kaitstud protokolli HTTPS. 

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

   Set-Cookie: Secure; HttpOnly

   Miks see on ohtlik: Kui veebiarendaja ei ole neid atribuute määranud, võib kurjategija kasutada küpsiste kaudu kasutaja teavet ja seda kurjasti kasutada. Kui küpsiseid kasutatakse autentimiseks ja autoriseerimiseks, suudab ta varastada kasutaja sessiooni ja teha toiminguid saidil tema nimel. 

   Mida peaks veebiarendaja meeles pidama: Tüüpiliselt määratakse need atribuudid automaatselt populaarsetes raamistikes. Kuid kontrollige ikka veebiserveri konfiguratsiooni ja seadistage lipp: Set-Cookie HttpOnly; Secure.

   Selle atribuudiga «HTTPOnly» muutuvad küpsised nähtamatuks ka teie enda JavaScriptile.  

3. Path Based Vulnerabilities ("teepõhised" haavatavused).

   Skanner teatab sellisest haavatavusest, kui leiab avalikult ligipääsetava faili või katalooge saidil, kus võib olla potentsiaalselt konfidentsiaalset teavet. Näiteks tuvastab see eraldiseisvad failid süsteemi konfiguratsiooniga või pääsu tervikfailisüsteemile. Selline olukord võib tekkida, kui saidil on valesti määratud juurdepääsuõigused.

   Miks see on ohtlik: Kui failisüsteem „ulatuvalt välja”, võib ründaja pääseda operatsioonisüsteemi liidesesse ja proovida leida kaustasid, kus paroolid on avatud kujul talletatud (ärge tehke nii!). Samuti saab varastada paroolide räsi ja proovida neile parooli leida, samuti püüda tõsta oma õiguseid süsteemis ja liikuda sügavale infrastruktuuri.  

   Mida peaks veebiarendaja meeles pidama: Ärge unustage juurdepääsuõigusi ja seadistage platvorm, veebiserver ja veebirakendus nii, et ei oleks võimalik „põgeneda” veebikaustast.

4. Täpse andmete sisestamise vormid koos automaatse täitmise funktsiooniga.

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

   Veebisaitide vormid võivad sisaldada konfidentsiaalsete andmete välju, näiteks paroole või krediitkaardi numbreid. Selliste väljade jaoks on soovitatav veebisaidi tasemel automaatse täitmise funktsioon välja lülitada. 

   Miks see on ohtlik: Kui kasutaja brauser salvestab konfidentsiaalset teavet, võib ründaja selle hiljem haarata, näiteks phishingu kaudu. Sisuliselt sisestab veebiarendaja, kes unustab selle nüansi, oma kasutajad ohtu. 

   Mida peaks veebiarendaja meeles pidama: Sellisel juhul on meil klassikaline konflikt: 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 ligipääsetavuse suunised – juhised sisu ligipääsetavuse kohta liikikuvaegustega kasutajatele. 

   Enamiku brauserite puhul saab automaatset täitmist keelata atribuudiga autocomplete="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>

   Kuid Chrome'i puhul ei tööta see. Seda ületatakse JavaScripti abil, retsepti varianti saab leida siit. 

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 raami sisse. Selleks tuleb määrata väärtus X-Frame-Options: deny. Või võib määrata X-Frame-Options: sameorigin, siis on iframe'i integreerimine saadaval ainult teie domeenil.

   Miks see on ohtlik: Selline pealkiri võib olla kurjategijate poolt kasutatud kahjulikes veebisaitides, et klikkimise petmiseks. Selle rünnaku korral loob ründaja läbipaistva raami nuppude kohale, pettes kasutajat. Näiteks: petjad paigutavad raami sotsiaalmeedia lehtede kohale. Kasutaja arvab, et klikkib sellel saidil nupule. Sellest hoolimata haaratakse klikk ja saadetakse kasutaja päring sotsiaalmeediasse, kus tal on aktiivne sessioon. Nii saadavad kurjategijad rämpsposti kasutaja nimel või saavad järgijaid ja meeldimisi. 

   Kui seda võimalust ei blokeerida, võib ründaja paigutada teie rakenduse nupu kahjulikku veebisaidile. Ta võib olla huvitatud teie viidatud programmist või teie kasutajatest.  

   Mida peaks veebiarendaja meeles pidama: Turvaprobleem võib ilmneda, kui X-Frame-Options on vastuolulise väärtusega määratud veebiserveris või koormuse tasakaalus. Sellisel juhul kirjutab server ja koormuse tasakaalustaja lihtsalt pealkirja üle, kuna neil on kõrgem prioriteet võrreldes tagasiside koodiga.  

   X-Frame-Optionsi deny ja sameorigin väärtused takistavad Yandexi veebivaatleja tööd. Et lubada iframe'i kasutamine veebivaatlejas, tuleb seadistustes lisada eraldi reegel. Näiteks nginx'i puhul saab seadistada nii:

   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 kujul href="/somefolder/styles.css/". Kurjategija saab seda kasutada, kui leiab viisi, kuidas suunata kasutaja pahatahtlikule lehele. Leht asendab suhtelise lingi oma url-iga ja imiteerib stiilidele pöördumist. Tulemuseks on päring, nagu badsite.ru/…/somefolder/styles.css/, mis tegevuses võib kahjustada toimingut stiilina. 

   Miks see on ohtlik: Kurjategija saab seda haavatavust ära kasutada, kui leiab veel ühe turvauuenduse. Sel viisil on võimalik varastada kasutajaandmeid küpsistest või tokenitest.

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

Kriitilised haavatavused

1. Paroolivälja sisaldav leht edastatakse serverist kaitsmata kanalil (HTML vorm, mis sisaldab paroolivälja, edastatakse HTTP kaudu).

   Serverist tulev vastus mittešifreeritud kanali kaudu on haavatav keskmise inimese rünnakute suhtes. Ründaja võib peatada liiklust ja sekkuda kliendi ja serveri vahel, kui leht liigub serverist kliendile. 

   Miks see on ohtlik: Pettur saab lehte muuta ja saata kasutajale vormi konfidentsiaalsete andmete jaoks, mis saadetakse ründaja serverisse. 

   Mida peaks veebiarendaja meeles pidama: Mõned saidid saadavad kasutajatele kahekordsete autentimisülesannete asemel koodi e-posti või telefoni. Sellisel juhul pole haavatavus nii kriitiline, kuid mehhanism muudab kasutajate elu keeruliseks.

2. Sisselogimisvormi saatmine kaitsmata kanalil (Sisselogimisvorm ei edastata HTTPS-i kaudu).

   Sellisel juhul saadetakse brauserist serverisse mittešifreeritud kanali kaudu vorm, mis sisaldab sisselogimise ja parooli.

   Miks see on ohtlik: Erinevalt eelnevast juhtumist on see juba kriitiline haavatavus. Salajaste andmete pealtkuulamine on lihtsam, kuna selleks ei ole vaja isegi koodi kirjutada. 

3. JavaScripti raamatukogude kasutamine, kus on tuntud haavatavused.

   Seni läbi viidud skaneerimisel on kõige laialdasemalt kasutatud raamatukogu olnud jQuery koos ulatusliku versioonide kogumiga. Igas versioonis on vähemalt üks, sageli rohkem tuntud haavatavust. Mõju võib olla väga erinev – sõltub haavatavuse iseloomust.

   Miks see on ohtlik: Tuntud haavatavuste jaoks on olemas eksploidid, näiteks sellised:

   
   
   Mida peaks veebiarendaja meeles pidama: Tagasi pöördumine tsüklisse: tuntud haavatavuste otsimine – kõrvaldamine – kontrollimine on soovitatav. Kui kasutate teadlikult aegunud raamatukogasid, näiteks vanade brauserite toetamiseks või eelarve kokkuhoidmiseks, otsige võimalusi tuntud haavatavuse kõrvaldamiseks. 

4. Veebirakenduste ründed (XSS). 
   Cross-Site Scripting (XSS), ehk veebirakenduste ründed, on rünnakud, millega veebirakenduse andmebaasi lisatakse pahavara. Kui Qualys tuvastab sellise haavatavuse, tähendab see, et potentsiaalne ründaja võib olla tutvustanud või juba tutvustanud oma js-skripti saidi koodis pahatahtlike toimingute tegemiseks.

   Salvestatud XSS (Stored XSS) on ohtlikum, kuna skript sisestatakse serverisse ja täidetakse iga kord, kui ründatud lehte brauseris avatakse.

   Peegeldunud XSS (Reflected XSS) on lihtsam läbi viia, kuna pahatahtlikku skripti saab sisestada HTTP-päringusse. Rakendus saab HTTP-päringu, ei kontrolli andmeid, pakib need ja saadab kohe edasi. Kui ründaja püüab liiklust ja lisab skripti nagu

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

   siis saadetakse pahatahtlik päring kliendi nimel.

   Selge näide XSS-st: JS-snifferid, mis matkivad lehti CVC, kaardi kehtivuse ja muu sarnase sisu sisestamiseks. 

   Mida peaks veebiarendaja meeles pidama: Content-Security-Policy päises kasutage atribuut script-src, et kliendi brauser laadiks ja täidaks ainult usaldusväärsest allikast lähtuvat koodi. Näiteks script-src 'self' lubab kõik skriptid ainult meie saidilt. 
   Parim praktika on Inline-kood: lubage ainult inline-javascript väärtusega unsafe-inline. See väärtus võimaldab kasutada inline js/css, kuid ei keela js-failide laadimist. Kombineeritud script-src 'self' väärtusega keelame väliste skriptide täitmise.

   Logige kindlasti kõik report-uri abil ja jälgige veebisaidile sisselaskmisproovide tegemisi.

5. SQL-i süstekatsed.
   Võrgu haavatavus viitab võimalusele sisestada veebisaidile SQL-koodi, mis küsib andmeid otse saidi andmebaasist. SQL-i süstekatse võib toimuda, kui kasutaja sisendid ei ole kontrollitud: neid ei valideerita ja neid kasutatakse otse päringus. Näiteks juhtub nii, kui veebisaidi vorm ei kontrolli, kas sisend vastab andmetüübile. 

   Miks see on ohtlik: Kui ründaja sisestab sellesse vormi SQL-päringu, võib ta andmebaasi riket põhjustada või konfidentsiaalset teavet avaldada. 

   Mida peaks veebiarendaja meeles pidama: Ärge usaldage saadud andmeid brauserist. Kaitsta tuleb nii kliendi- kui ka serveripoolset osa. 

   Kliendipoolsel küljel kirjutage JavaScripti abil välja valideerimise kontroll. 

   Populaarsete raamistikute sisseehitatud funktsioonid aitavad samuti serveris kahtlasi märke päästa. Serveris on soovitatav kasutada ka parameetrilised päringud andmebaaside suhtes.

   Määrake, kus veebirakenduses toimub andmebaasiga suhtlemine. 

   Koostoime tekib, kui saame mingit teavet: päring ID-ga (ID muutmine), uue kasutaja loomine, uus kommentaar – uued kirjed andmebaasis. Siin võivad ilmneda SQL-injektsioonid. Isegi kui kustutame andmebaasist kirje, on SQL-injektsioon võimalik.

Üldised soovitused

Ärge leiutage ratast – kasutage katsetatud raame. Reeglina on populaarsed raamistikud turvalisemad. .NET-i puhul on see ASP.NET MVC ja ASP.NET Core, Pythoni puhul Django või Flask, Ruby puhul Ruby on Rails, PHP puhul Symfony, Laravel, Yii, JavaScripti puhul Node.JS-Express.js, Java puhul Spring MVC.

Jälgige tarnija uuendusi ja uuendage regulaarselt. Haavatavused avastatakse, seejärel kirjutatakse eksploit, jagatakse avalikult ja kõik kordub uuesti. Tellige uuendused kuni tarkvara tarnija stabiilsete versioonideni.

Kontrollige juurdepääsuõigusi. Serveri poolt tuleb alati oma koodi suhtuda nagu ka kõik, alates esimesest ja kuni viimase täheni, on kirjutatud teie kõige vihatumate vaenlaste poolt, kes soovivad teie saiti lõhkuda ja teie andmete terviklikkust rikkuda. Eriti kuna mõnikord on see tõesti nii.

Kasutage kloone, testimisplatvorme ja seejärel alles viige tootmisse. See help to avoid pitfalls and mistakes in the production environment: the production environment generates revenue, and downtime is critical. When adding, fixing, or closing any issues, it is essential to work in a testing environment first, check functionality and detected vulnerabilities, and only then plan work for the production environment. 

Kaitsege oma veebirakendust Veebirakenduse tulemüüri ja integreerige selle juurde haavatavuste skanneri aruanded. Näiteks kasutatakse DataLine'i teenuste ühendamiseks Qualys'i ja FortiWeb'i.

Allikas: habr.com