Günците fatale të sigurisë së faqes: çfarë mësuam nga statistikat e skanerit të dobësive gjatë vitit

Rreth një vit më parë, ne në DataLine lançuam shërbim për kërkimin dhe analizimin e dobësive në aplikacionet IT. Baza e shërbimit është zgjidhja cloud Qualys, për të cilën ne kemi biseduar tashmë. Gjatë një viti përdorimi të zgjidhjes, ne kemi kryer 291 skanime për faqe të ndryshme dhe kemi grumbulluar statistika mbi dobësitë e zakonshme në aplikacionet web. 

Në artikullin më poshtë do të tregoj se cilat pikëpamje të sigurisë së faqeve fshihen pas niveleve të ndryshme të rëndësisë. Le të shohim cilat dobësi i ka gjetur skaneri më shpesh, pse ato mund të ndodhin dhe si mund të mbroni veten. 

Të gjitha dobësitë e aplikacioneve web Qualys i ndan në tri nivele rëndësie: të ulëta, të mesme dhe të larta. Nëse shikojmë shpërndarjen sipas "peshës", duket se gjendja nuk është kaq e keqe. Dobësitë me nivel të lartë rëndësie janë të pakta, kryesisht të gjitha janë jo kritike: 

Por jo kritik nuk do të thotë pa rrezik. Ato gjithashtu mund të shkaktojnë dëme serioze. 

Të dhënat kryesore të dobësive "jo kritike"

1. Dobësitë që lidhen me përmbajtjen e përzier.

   Standardi i sigurisë për faqet web konsiderohet të jetë transmetimi i të dhënave midis klientit dhe serverit nëpërmjet protokolit HTTPS, i cili mbështet enkriptimin dhe mbron informacionin nga kapja. 

   Disa faqe përdorin përmbajtje të përzier: transmetojnë një pjesë të të dhënave përmes protokollit të pasigurt HTTP. Shpesh kështu transmetohet përmbajtja pasive – informacione që ndikojnë vetëm në shfaqjen e faqes: imazhe, stilet css. Por ndonjëherë kështu transmetohet dhe përmbajtja aktive: skriptet që menaxhojnë sjelljen e faqes. Në këtë rast, me ndihmën e softuerit të veçantë, është e mundur të analizohet informacija që vjen nga serveri me përmbajtje aktive, të modifikohet në kohë reale përgjigjet e saj dhe të detyrohet makina të funksionojë ndryshe nga si ishte parashikuar nga krijuesit e saj. 

   Broswerat e versioneve të reja paralajmërojnë përdoruesit se faqet me përmbajtje të përzier nuk janë të sigurta dhe bllokojnë përmbajtjen. Zhvilluesit e faqeve gjithashtu marrin paralajmërime nga brosweri në konsolë. Ja si duket kjo në Firefox: 

   
   
   Çfarë është e rrezikshme: Kriminelët përdorin protokollin e pasigurt për të kapur informacionin rreth përdoruesit, për të zëvendësuar skriptet dhe për të dërguar kërkesa në sit në emrin e tij. Edhe nëse vizitori i faqes nuk ka futur të dhëna, kjo nuk e mbron atë nga phishing - grumbullimi i informacionit të ndjeshëm me metoda mashtruese. Për shembull, me ndihmën e një skripti, mund të ridrejtohet përdoruesi në një faqe të pasigurt, e cila maskohet si një faqe e njohur për përdoruesin. Në raste të veçanta, faqja e keqe duket madje më mirë se origjinali, dhe përdoruesi mund ta plotësojë formën dhe t'i përcjellë të dhënat e ndjeshme. 

   Çfarë duhet të mbajë mend një zhvillues i uebit: Edhe nëse administratori i faqes ka instaluar dhe konfiguruar certifikatën SSL/TLS, dobësitë mund të ndodhin për shkak të faktorëve njerëzorë. Për shembull, nëse në ndonjë nga faqet është vendosur një lidhje jo relative, por absolute me http, dhe përveç kësaj nuk janë konfiguruar ridrejtime nga http në https. 

   Për të zbuluar përmbajtje të përzier në faqe, mund të përdorni broswerin: të kërkoni në kodin burimor të faqes, të lexoni njoftimet në konsolën e zhvilluesit. Megjithatë, zhvilluesi do të duhet të përballet me një kod të gjatë dhe të mundimshëm. Procesin mund ta shpejtojë mjete të automatizuara analize, për shembull: SSL Check, softueri i lirë Lighthouse ose softueri me pagesë Screaming Frog SEO Spider.

   Gjithashtu, dobësitë mund të ndodhin për shkak të problemeve me kodin e trashëguar – kodin që u kalua nga brezi në brez. Për shembull, nëse disa faqe gjenerohen nga një model të vjetër, ku nuk merret parasysh kalimi i faqeve në https.    

2. Cookies pa flamujt «HTTPOnly» dhe «secure».

   Atributi «HTTPOnly» mbron skedarët e cookies nga përpunimi i skripteve që kriminelët përdorin për të vjedhur të dhënat e përdoruesve. Flamuri «secure» nuk lejon dërgimin e cookies në formë të hapur. Shkëmbimi i të dhënave do të jetë i lejuar vetëm nëse për dërgimin e cookies përdoret protokolli i sigurt HTTPS. 

   Të dy atributet shkruhen në pronat e cookies:

   Set-Cookie: Secure; HttpOnly

   Çfarë është e rrezikshme: Nëse zhvilluesi i faqes nuk ka specifikuar këto atribute, një kriminel mund të kapë informacionin e përdoruesit nga cookies dhe ta shfrytëzojë atë. Nëse cookies përdoren për autentikimin dhe autorizimin, ai do të jetë në gjendje të dyfishojë seancën e përdoruesit dhe të kryejë veprime në faqe në emrin e tij. 

   Çfarë duhet të mbajë mend një zhvillues i uebit: Si rregull, në framework-et e njohura këto atribute përcaktohen automatikisht. Por përsëri, kontrolloni konfigurimin e serverit tuaj web dhe vendosni flamurin: Set-Cookie HttpOnly; Secure.

   Për më tepër, atributi «HTTPOnly» do t'i bëjë cookies të padukshme edhe për JavaScript-in tuaj.  

3. Dobësitë e bazuara në rrugë («dobësi rrugore»).

   Skeneri njofton për një dobësi të tillë nëse gjen një skedar ose direktor të disponueshëm publik në faqen e internetit me informacione potencialisht konfidenciale. Për shembull, zbulon skedarë të veçantë me konfigurimin e sistemit ose qasje të gjithanshme në sistemin e skedareve. Kjo situatë është e mundur nëse janë vendosur keq të drejtat e aksesit në faqe.

   Çfarë është e rrezikshme: Nëse sistemi i skedarëve "doli jashtë", një sulmues mund të depërtojë në ndërfaqen e sistemit operativ dhe të përpiqet të gjejë dosje me fjalëkalime, nëse ato ruhen në mënyrë të hapur (mos e bëni këtë!). Ose mund të vjedhë hash-ët e fjalëkalimeve dhe të provojë të gjejë fjalëkalimin, si dhe të përpiqet të rrisë privilegjet në sistem dhe të avancojë brenda infrastrukturës.  

   Çfarë duhet të mbajë mend një zhvillues i uebit: Mos haroni për të drejtat e aksesit dhe konfiguroni platformën, serverin web, aplikacionin web, në mënyrë që të mos jetë e mundur "të shpëtohet" nga direktoria web.

4. Format për hyrjen e të dhënave konfidenciale me funksionin e autoshkurtimit të aktivizuar.

   Nëse një përdorues shpesh plotëson forma në faqe, shfletuesi i tij ruan këtë informacion përmes funksionit të autoshkurtimit. 

   Format në faqet e internetit mund të përmbajnë fusha me informacione konfidenciale, për shembull, fjalëkalime ose numra kartash krediti. Për këto fusha, është e rekomandueshme të çaktivizohet funksioni i autoshkurtimit të formave në faqen e internetit. 

   Çfarë është e rrezikshme: Nëse shfletuesi i përdoruesit ruan informacionin konfidencial, një sulmues mund ta kapë atë më vonë, për shembull, përmes phishing-ut. Në thelb, një zhvillues web-i që të harrojë këtë aspekt rrezikon përdoruesit e tij. 

   Çfarë duhet të mbajë mend një zhvillues i uebit: Në këtë rast kemi një konflikt klasik: komoditeti vs. siguria. Nëse një zhvillues web-i mendon për komoditetin e përdoruesit, ai mund të zgjedhë në mënyrë të vetëdijshme autoshkurtimin. Për shembull, nëse është e rëndësishme të ndiqet Udhëzimet për Aksesueshmërinë e Pëmbajtjes Web – rekomandime për aksesueshmërinë e përmbajtjes për përdoruesit me aftësi të kufizuara. 

   Për shumicën e shfletoreshave, mund të çaktivizohet autoshkurtimi përmes atributit autocompete="off", për shembull:

    <body>
       <form action="/sq/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit">
         <div>
           <input type="text" placeholder="Emri">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Emri i fundit" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Numri i kartës së kreditit">
         </div>
         <input type="submit">
       <input type="hidden" name="trp-form-language" value="sq"/></form>
     </body>

   Por për Chrome, kjo nuk do të funksionojë. Kjo kalohet përmes JavaScript-it, një variant mund të gjendet këtu. 

5. Në kodin e faqes nuk është caktuar titulli X-Frame-Options. 

   Ky titull ndikon në etiketat frame, iframe, embed ose object. Me të, mund të ndalohet plotësisht përfshirja e faqes suaj brenda një framer. Për këtë duhet të përcaktohet vlera X-Frame-Options: deny. Ose mund të përcaktohet X-Frame-Options: sameorigin, në këtë rast përfshirja në iframe do të jetë e disponueshme vetëm në domainin tuaj.

   Çfarë është e rrezikshme: Mungesa e këtij titulli mund të përdoret në faqe të dëmshme për klikatake.. Për një sulm të tillë, një sulmues krijon një frame të qartë mbi butonat dhe e mashtron përdoruesin. Për shembull: mashtruesit vendosin në frame në faqe dhe faqet e rrjeteve sociale. Përdoruesi mendon se po klikon një buton në këtë faqe. Në vend të kësaj, klikimi kapet dhe dërgon një kërkesë të përdoruesit në rrjetin social, ku ka një sesion aktiv. Kështu, sulmuesit shpërndajnë spamin në emër të përdoruesit ose rrisin ndjekësit dhe like-t. 

   Nëse nuk e ndaloni një mundësi të tillë, një sulmues mund të vendosë butonin e aplikacionit tuaj në një faqe të dëmshme. Ai mund të jetë i interesuar për programin tuaj të referimit ose për përdoruesit tuaj.  

   Çfarë duhet të mbajë mend një zhvillues i uebit: Dobësia mund të shfaqet nëse X-Frame-Options me një vlerë në konflikt është caktuar në serverin web ose balancuesin e ngarkesës. Në këtë rast, serveri dhe balancuesi thjesht do të rifreskojnë titullin, pasi kanë prioritet më të lartë krahasuar me kodin e pjesës backend.  

   Vlerat deny dhe sameorigin të titullit X-Frame-Options do të pengojnë funksionimin e webvizorit të Yandex. Për të lejuar përdorimin e iframe për webvizorin, duhet të shkruani një rregull të veçantë në konfigurime. Për shembull, për nginx, mund të konfigurohet kështu:

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

6. Dobësitë PRSSI (Importimi i stilit relativ ndaj rrugës).  

   Kjo është një dobësi në stilet e faqes. Ajo ndodh nëse për qasje në skedarët e stilit përdoren lidhje relative të tilla si href="/somefolder/styles.css/". Një sulmues do ta shfrytëzojë këtë nëse gjen një mënyrë për ta drejtuar përdoruesin në një faqe të dëmshme. Faqja do të vendosë lidhjen relative në URL-në e saj dhe do të imitojë qasjen në stile. Kështu, do të rezultojë një kërkesë si badsite.ru/…/somefolder/styles.css/, e cila nën maskën e stilit mund të realizojë veprime të dëmshme. 

   Çfarë është e rrezikshme: Një mashtrues do të mund ta shfrytëzojë këtë dobësi nëse gjen një tjetër vrimë në siguri. Si rezultat, mund të vjedhin të dhënat e përdoruesve nga cookie ose tokenët.

   Çfarë duhet të mbajë mend një zhvillues i uebit: Caktoni titullin X-Content-Type-Options: nosniff. Në këtë rast, shfletuesi do të kontrollojë llojin e përmbajtjes për stilin. Nëse lloji ndryshon nga text/css, shfletuesi do të bllokojë kërkesën.

Dobësi kritike

1. Faqja me fushën për fjalëkalim kalon nga serveri përmes një kanali të papajisur (HTML form containing password field(s) is served over HTTP).

   Përgjigjja nga serveri në një kanal të paenkriptuar është e ndjeshme ndaj sulmeve të tipit «Man in the middle». Një sulmues mund të kapë trafikun dhe të ndërhyjë mes klientit dhe serverit, kur faqja kalon nga serveri te klienti. 

   Çfarë është e rrezikshme: Një mashtrues mund të përmbysë faqen dhe t'i dërgojë përdoruesit një formular për të dhëna konfidenciale, të cilat do të shkojnë në serverin e sulmuesit. 

   Çfarë duhet të mbajë mend një zhvillues i uebit: Disa faqe, në vend të fjalëkalimit, u dërgojnë përdoruesve një kod të njëhershëm për email/telefon. Në këtë rast, ndjeshmëria nuk është aq kritike, por mekanizmi do t'i komplikohet jetën përdoruesve.

2. Dërgimi i formularit me login dhe fjalëkalim përmes një kanali të papajisur (Login Form Is Not Submitted Via HTTPS).

   Në këtë rast, nga përdoruesi dërgohet në server një formular me login dhe fjalëkalim në një kanal të paenkriptuar.

   Çfarë është e rrezikshme: Përshtatje me rastin e mëparshëm, kjo tashmë është një ndjeshmëri kritike. Është më e lehtë të kapësh të dhënat konfidenciale, pasi nuk nevojitet të shkruani kod për këtë. 

3. Përdorimi i bibliotekave JavaScript me ndjeshmëri të njohura.

   Gjatë skanimit, biblioteka më e përdorur u bë jQuery me një gamë të gjerë versionesh. Në çdo version ka të paktën një ose më shumë ndjeshmëri të njohura. Ndikimi mund të jetë i ndryshëm - varet nga natyra e ndjeshmërisë.

   Çfarë është e rrezikshme: Për ndjeshmëri të njohura ka eksploitate, për shembull:

   
   
   Çfarë duhet të mbajë mend një zhvillues i uebit: Kthehuni rregullisht në ciklin: kërkoni ndjeshmëri të njohura – eliminohuni – kontrolloni. Nëse e përdorni bibliotekat e përmendura në mënyrë të qëllimshme, për shembull për të mbështetur shfletuesit e vjetër ose për të kursyer buxhetin, kërkoni mundësi për të eliminuar ndjeshmërinë e njohur. 

4. Skripte ndërfaqesh (XSS). 
   Cross-Site Scripting (XSS), ose skripte ndërfaqesh, janë sulme ndaj aplikacioneve në ueb, kur si rezultat në bazën e të dhënave shfaqet malware. Nëse Qualys gjen një ndjeshmëri të tillë, do të thotë që një sulmues potencial mund të integrojë ose tashmë ka integruar një skript js në kodin e faqes për të kryer veprime të dëmshme.

   XSS të ruajtura (Stored XSS) janë më të rrezikshme, pasi skripti integron në server dhe ekzekutohet çdo herë kur hapet faqeja e sulmuar në shfletues.

   XSS të reflektuar (Reflected XSS) është më e lehtë për t'u realizuar, pasi skripti keqdashës mund të integrohet në kërkesën HTTP. Aplikacioni merr kërkesën HTTP, nuk verifikon të dhënat, i paketoni ato dhe menjëherë i dërgon. Nëse sulmuesi kap trafikun dhe vendos një skript të tillë

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

   atëherë do të dërgohet një kërkesë keqdashëse sipas emrit të klientit.

   Një shembull i qartë i XSS: js-sniffers, të cilët imitojnë faqet për futjen e CVC, të datës së skadencës së kartës dhe kështu me radhë. 

   Çfarë duhet të mbajë mend një zhvillues i uebit: Në titullin Content-Security-Policy përdorni atributin script-src, për të lejuar shfletuesin e klientit të ngarkojë dhe ekzekutojë vetëm kodin nga një burim të besueshëm. Për shembull, script-src ‘self’ e vendos në listën e bardhë të gjithë skriptet vetëm nga faqja jonë. 
   Praktika më e mirë është që Inline code: të lejoni vetëm javascript inline me vlerën unsafe-inline. Kjo vlerë lejon përdorimin e js/css inline, por nuk ndalon lidhjen e skedarëve js. Në kombinim me script-src ‘self’ ne ndalojmë ekzekutimin e skripteve jashtë.

   Sigurohuni që të regjistroni gjithçka me report-uri dhe shqyrtoni përpjekjet për integrimin në faqe.

5. SQL-injeksionet.
   Ndjeshmëria flet për mundësinë e integrimit të kodit SQL në faqen e internetit, i cili i qaset direkt bazës së të dhënave të faqes. SQL-injeksioni është i mundur, nëse të dhënat nga përdoruesi nuk bëhen escaping: nuk kontrollohen për saktësi dhe përdoren direkt në kërkesë. Për shembull, kështu ndodh, nëse formulari në faqen e internetit nuk kontrollon përputhshmërinë e hyrjes me tipin e të dhënave. 

   Çfarë është e rrezikshme: Nëse një sulmues fut një kërkesë SQL në një formular të tillë, ai mund të rrëzojë bazën e të dhënave ose të nxjerrë informacione konfidenciale. 

   Çfarë duhet të mbajë mend një zhvillues i uebit: Mos i besoni asaj që vjen nga shfletuesi. Duhet të mbroheni si në anën e klientit, ashtu edhe në anën e serverit. 

   Në anën e klientit shkruani një kontroll të fushave me JavaScript. 

   Funksionet e integruara në frameworkët e njohura gjithashtu ndihmojnë në escaping simbolet e dyshimta në server. Në server gjithashtu rekomandohet përdorimi i kërkesave parametrike në bazat e të dhënave.

   Përcaktoni se ku ndodh ndërveprimi me bazën e të dhënave në aplikacionin web. 

   Ndërveprimi ndodh kur marrim ndonjë informacion: kërkesa me id (ndryshimi i id), krijimi i një përdoruesi të ri, një koment të ri - regjistrime të reja në bazë. Këtu mund të ndodhin SQL-injeksione. Edhe nëse e largojmë një regjistrim nga baza, ndiqet SQL-injeksioni.

Rekomandime të Përgjithshme

Mos shpikni biçikletën - përdorni frameworkë të provuar. Zakonisht, framework-et e njohura janë më të sigurta. Për .NET – është ASP.NET MVC dhe ASP.NET Core, për Python – Django ose Flask, për Ruby – Ruby on Rails, për PHP – Symfony, Laravel, Yii, për JavaScript – Node.JS- Express.js, për Java – Spring MVC.

Mbani një sy mbi përditësimet e furnizuesit dhe përditësoni rregullisht.. Do të zbulohet një dobësi, pastaj do të shkruhet një eksploatues, do të publikohet për publikun, dhe gjithçka do të përsëritet sërish. Abonohuni për përditësimet deri në versionet stabile nga furnizuesi i softuerit.

Kontrolloni të drejtat e aksesit.. Nga ana e serverit, gjithmonë duhet ta trajtoni kodin tuaj sikur ai të jetë shkruar nga armiku juaj më i urryer, që dëshiron të dëmtojë faqen tuaj dhe të dëmtojë integritetin e të dhënave tuaja. Aq më tepër, ndonjëherë kjo vërtet ndodh.

Përdorni klonë, ambiente testimi, dhe pastaj aplikoni në prodhim.. Kjo do të ndihmojë, së pari, të evitoni gabime dhe lëshime në ambientin e prodhimit: ambienti i prodhimit sjell para, ndërprerja e ambientit të prodhimit është kritike. Kur shtoni, rregulloni apo zgjidhni ndonjë problem, duhet të kryeni punime në ambientin testues, pastaj të kontrolloni funksionalitetin dhe dobësitë e gjetura, dhe më pas të planifikoni punët në ambientin e prodhimit. 

Mbroni aplikacionin web me Web Application Firewall dhe integrojeni me raportet nga skaneri i dobësive.. Për shembull, në DataLine, si lidhje shërbimesh përdoren Qualys dhe FortiWeb.

Burimi: habr.com