Afërsisht një vit më parë, ne në DataLine lansuam për kërkimin dhe analizimin e dobësive në aplikacionet IT. Baza e shërbimit është zgjidhja cloud Qualys, për punën e së cilës . Në vitin e kaluar të punës me zgjidhjen, 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 vrima në sigurinë e faqeve fshihen pas niveleve të ndryshme të rrezikshmërisë. Le të shohim cilat dobësi skaneri i gjente veçanërisht shpesh, pse ato mund të ndodhin dhe si të mbrohemi.
Të gjitha dobësitë e aplikacioneve web Qualys i ndan në tri nivele rrezikshmërie: të ulët, të mesëm dhe të lartë. Nëse shikojmë shpërndarjen sipas "seriozitetit", duket se gjithçka nuk është aq keq. Ka pak dobësi me nivel të lartë rrezikshmërie, kryesisht të gjitha janë jo kritike:
Por jo kritike – nuk do të thotë pa rrezik. Ato gjithashtu mund të shkaktojnë dëme të rënda.
Top "dobësive jo kritike"
- Dobësi të lidhura me përmbajtje të përzier.
Standardi i sigurisë së faqeve është transmetimi i të dhënave midis klientit dhe serverit sipas protokollit HTTPS, i cili mbështet enkripcioni 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 transmetohen përmbajtje pasive – informacioni që ndikon vetëm në shfaqjen e faqes: imazhe, stilset css. Por ndonjëherë kështu transmetohet edhe përmbajtje aktive: skriptet që menaxhojnë sjelljen e faqes. Në këtë rast, me anë të një programi të veçantë mund të analizosh informacionin që vjen nga serveri me përmbajtje aktive, të modifikosh përgjigjet në mënyrë të menjëhershme dhe të bësh që makina të veprojë ndryshe nga sa është menduar nga krijuesit e saj.
Shfletuesit 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 shfletuesi në konsolë. Për shembull, kështu duket në :
Çfarë rreziku ka: Kibernetikët përdorin protokollin e papërmirësuar për të kapur informacionin e përdoruesve, për të zëvendësuar skriptet dhe për të dërguar kërkesa në faqen e internetit në emrin e tij. Edhe nëse vizitori i faqes nuk ka futur të dhëna, kjo nuk e mbron atë nga peshkimi – nxjerrja e informacionit të ndjeshëm në mënyrë mashtruese. Për shembull, me anë të një skripti mund të ridrejtohet përdoruesi në një faqe të pasigurt, e cila maskohet si ajo e njohur për përdoruesin. Në raste të caktuara, faqja e keqe duket madje më mirë se origjinali, dhe përdoruesi mund ta plotësojë formën dhe t'i dërgojë të dhënat e ndjeshme.Çfarë duhet të mbajë mend zhvilluesi i uebit: Edhe nëse administratori i faqes ka instaluar dhe konfigurua certifikatën SSL/TLS, një dobësi mund të ndodhë për shkak të faktorëve njerëzorë. Për shembull, nëse në ndonjë nga faqet është vendosur një lidhje absolute me http, e jo në mënyrë relative, dhe për më tepër nuk janë konfiguruar ridrejtime nga http në https.
Për të zbuluar përmbajtjen e përzier në faqen e internetit, mund të përdorni shfletuesin: kërkoni në kodin burimor të faqes, lexoni njoftimet në konsolën e zhvilluesit. Sidoqoftë, zhvilluesit do t'u kërkohet të kalojnë gjatë në kod. Procesin mund ta përshpejtoni me mjete automatike analize, për shembull: , softueri i lirë Lighthouse ose softueri me pagesë Screaming Frog SEO Spider.
Gjithashtu, një dobësi mund të ndodhë për shkak të problemeve me kodin e vjetër – kodin që është trashëguar. Për shembull, nëse disa faqe gjenerohen sipas një model të vjetër, ku nuk merret parasysh kalimi i faqeve në https.
- Cookie pa flamujt ‘HTTPOnly’ dhe ‘secure’.
Atributi ‘HTTPOnly’ mbron skedarët e cookie nga përpunimi nga skriptet që kibernetikët i përdorin për të vjedhur të dhënat e përdoruesve. Flamuri ‘secure’ nuk lejon transferimin e cookie-ve në mënyrë të hapur. Shkëmbimi i të dhënave do të lejohet vetëm nëse për dërgimin e cookie-ve përdoret protokolli i sigurt HTTPS.
Të dy atributet duhet të përshkruhen në pronësitë e cookie-ve:
Set-Cookie: Secure; HttpOnlyÇfarë rreziku ka: Nëse zhvilluesi i faqes nuk ka specifikuar këto atribute, kibernetiku mund të kapë informacionin e përdoruesit nga cookie dhe ta përdorë atë. Nëse cookie-t përdoren për autentifikim dhe autorizim, ai do të jetë në gjendje të vjedhë seancën e përdoruesit dhe të kryejë veprime në faqen në emrin e tij.
Çfarë duhet të mbajë mend zhvilluesi i uebit: Në rregull, në framework-ët popullorë, këto atribute vendosen automatikisht. Por të kontrolloni konfigurimin e serverit web dhe të vendosni flamurin: Set-Cookie HttpOnly; Secure.
Në këtë rast, atributi «HTTPOnly» do t'i bëjë cookies të padukshëm dhe për JavaScript-in tuaj.
- Përgjigjet e Dëmtueshme Baze të Rrugës.
Skeneri raporton për një vulnerabilitet të tillë nëse gjen një skedar ose direktor të aksesueshëm publik të faqes me informacione potencialisht të ndjeshme. Për shembull, zb discoversf ekton skedarë të veçantë me konfigurimin e sistemit ose qasje në sistemin e skedarëve në tërësi. Kjo situatë është e mundur nëse faqa e internetit ka caktuar gabimisht të drejtat e aksesit.
Çfarë rreziku ka: Nëse sistemi i skedarëve «vjen 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ë formë të hapur (mos e bëni atë!). Ose mund të vjedhë hash-et e fjalëkalimeve dhe të provojnë t'i gjejnë fjalëkalimin përmes mbushjes, si dhe të përpiqet të rrisë privilegjet në sistem dhe të avancojë brenda infrastrukturës.
Çfarë duhet të mbajë mend zhvilluesi i uebit: Mos harroni rreth të drejtave të aksesit dhe konfiguroni platformën, serverin web, aplikacionin web, në mënyrë që të mos mund të «shkoni» jashtë direktorisë web.
- Format për futjen e të dhënave të ndjeshme me funksionin e plotësimit automatik të aktivizuar.
Nëse përdoruesi shpesh ploteson forma në faqet e internetit, shfletuesi i tij ruan këto informata me anë të funksionit të plotësimit automatik.
Format në faqet e internetit mund të përfshijnë fusha me informacione të ndjeshme, për shembull, fjalëkalime ose numra kartelash krediti. Për këto fusha, duhet të çaktivizoni funksionin e plotësimit automatik në vetë faqen.
Çfarë rreziku ka: Nëse shfletuesi i përdoruesit ruan informata të ndjeshme, një sulmues mund ta kapë atë më vonë, për shembull, me anë të phishing-ut. Në thelb, zhvilluesi web, i cili harroi këtë nuancë, vë në rrezik përdoruesit e tij.
Çfarë duhet të mbajë mend zhvilluesi i uebit: Në këtë rast kemi një konflikt klasik: komoditeti vs siguria. Nëse zhvilluesi web mendon për komfortin e përdoruesit, ai mund të zgjedhë me vetëdije plotësimin automatik. Për shembull, nëse është e rëndësishme të respektohet – rekomandimet për aksesin në përmbajtje për përdoruesit me aftësi të kufizuara.
Për shumicën e shfletuesve, mund të çaktivizoni plotësimin automatik me atributin 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="Mbiemri" 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 anashkalohet me anë të JavaScript, një variant i recetës mund të gjendet. .
- Në kodin e faqes së internetit 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 në një frame. Për këtë, duhet të caktohet vlera X-Frame-Options: deny. Ose mund të caktohet X-Frame-Options: sameorigin, atëherë përfshirja në iframe do të jetë e disponueshme vetëm në domenin tuaj.
Çfarë rreziku ka: Mungesa e një titulli të tillë mund të përdoret në faqe të dëmshme për clickjacking. Për një sulm të tillë, sulmuesi krijon një frame transparent mbi butonat dhe e mashtron përdoruesin. Për shembull: mashtruesit vendosin në frame në faqen e dëmshme të rrjeteve sociale. Përdoruesi mendon se po klikon mbi një buton në këtë faqë. Në vend të kësaj, kliku mbulon dhe dërgon një kërkesë të përdoruesit në rrjetin social, ku ka një sesion aktiv. Në këtë mënyrë, sulmuesit shpërndajnë spam në emër të përdoruesit ose rrisin ndjekësit dhe like-t.
Nëse nuk e ndaloni një mundësi të tillë, sulmuesi mund të vendosë butonin e aplikacionit tuaj në një faqe të dëmshme. Ai mund të ketë interes në programin tuaj referral ose te përdoruesit tuaj.
Çfarë duhet të mbajë mend zhvilluesi i uebit: Një vulnerabilitet mund të shfaqet nëse X-Frame-Options me një vlerë konfliktuese është caktuar në serverin web ose balancuesin e ngarkesës. Në këtë rast, serveri dhe balancuesi i ngarkesës do ta rishkruajnë thjesht titullin, pasi kanë përparësi më të lartë në krahasim me kodin e pjesës së prapme.
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ë cilësimet. 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; ... } - Vulnerabilitetet PRSSI (Importimi i stilit të rrugës relative).
Ky është një vulnerabilitet në stilin e faqes. Ai shfaqet nëse për qasjen në skedarët e stilit përdoren lidhje relative si href="/somefolder/styles.css/". Sulmuesi do ta përdorë këtë, nëse gjen një mënyrë për ta kaluar përdoruesin në një faqe të dëmshme. Faqja do t'i japë lidhjes relative në url-in e saj dhe do të imitojë qasjen në stilin. Do të rezultojë një kërkesë si badsite.ru/.../somefolder/styles.css/, e cila nën pretekstin e stilit mund të kryejë veprime të dëmshme.
Çfarë rreziku ka: Një mashtrues mund të përfitojë nga kjo dobësi nëse gjen një tjetër vrimë në siguri. Si rezultat, kështu mund të vidhen të dhënat e përdoruesit nga cookies ose tokenët.
Çfarë duhet të mbajë mend zhvilluesi i uebit: Shtoni titullin X-Content-Type-Options: nosniff. Në këtë rast, shfletuesi do të kontrollojë llojin e përmbajtjes për stilet. Nëse lloji është ndryshe nga text/css, shfletuesi do ta bllokojë kërkesën.
Dobësitë kritike
- Faqja me fushën për fjalëkalim dërgohet nga serveri përmes një kanali të pa sigurt (HTML form containing password field(s) is served over HTTP).
Përgjigjja nga serveri për një kanal të pa kriptuar është e prirur ndaj sulmeve të tipit «Man in the middle». Një sulmues mund të kapë trafikun dhe të ndërhyjë ndërmjet klientit dhe serverit, kur faqa shkon nga serveri te klienti.
Çfarë rreziku ka: Një mashtrues mund të zëvendësojë faqen dhe t'i dërgojë përdoruesit një formë për të dhënat e ndjeshme, të cilat do të shkojnë në serverin e sulmuesit.
Çfarë duhet të mbajë mend zhvilluesi i uebit: Disa vende në vend të fjalëkalimit dërgojnë përdoruesve një kod të vetëm përmes emailit/telefonit. Në këtë rast, dobësia nuk është aq kritike, por mekanizmi do ta komplikohet jetën përdoruesve.
- Dërgimi i formularit me emër përdoruesi dhe fjalëkalim përmes një kanali të pa sigurt (Login Form Is Not Submitted Via HTTPS).
Në këtë rast, nga përdoruesi në server dërgohet një formular me emër përdoruesi dhe fjalëkalim përmes një kanali të pa kriptuar.
Çfarë rreziku ka: Ndryshe nga rastin e mëparshëm, kjo është një dobësi kritike. Kapja e të dhënave të ndjeshme është më e lehtë, pasi as nuk është nevoja të shkruani kod për të.
- Përdorimi i librarive JavaScript me dobësi të njohura.
Gjatë skanimit, biblioteka më e përdorur u bë jQuery me një gamë të gjerë versionesh. Në secilën version ka të paktën një, ndonjëherë edhe më shumë dobësi të njohura. Ndikimi mund të jetë nga më të ndryshmet – varet nga natyra e dobësisë.
Çfarë rreziku ka: Për dobësi të njohura ka eksploite, për shembull këto:
Çfarë duhet të mbajë mend zhvilluesi i uebit: Kthehuni rregullisht në cikël: kërkimi i dobësive të njohura – eliminimi – kontrolli. Nëse po përdorni libra të vjetruar me vetëdije, për shembull për të mbështetur shfletues të vjetër ose për të kursyer buxhetin, kërkoni mundësi për të eliminuar dobësinë e njohur. - Scripts ndër-sajtesh (XSS).
Cross-Site Scripting (XSS), ose skriptet ndër-site, janë sulme ndaj aplikacioneve në ueb, ku për pasojë shfaqet malware në bazën e të dhënave. Nëse Qualys gjen një dobie, atëherë një sulmues potencial mund të ketë introduktuar ose tashmë ka introduktuar në kodin e faqes së internetit skriptin e tij js për të kryer veprime të dëmshme.XSS të Ruajtura (Stored XSS) janë më të rrezikshme, pasi skripti introduktohet në server dhe ekzekutohet çdo herë kur hapet faqja e sulmuar në shfletues.
XSS të Reflektuar (Reflected XSS) janë më të lehtë për t'u realizuar, pasi skripti keqbërës mund të introduktohet në kërkesën HTTP. Aplikacioni do marrë kërkesën HTTP, nuk do ta kontrollojë të dhënën, do ta paketojë dhe menjëherë do ta dërgojë. Nëse sulmuesi kap trafikun dhe fut skriptin e tipit
<script>/*+что+то+плохое+*/</script>atëherë një kërkesë e dëmshme do të dërgohet në emër të klientit.
Një shembull i dukshëm i XSS: js-sniferët, të cilët imitojnë faqe për futjen e CVC, afatit të skadencës së kartës dhe kështu me radhë.
Çfarë duhet të mbajë mend zhvilluesi i uebit: Në titullin Content-Security-Policy përdorni atributin script-src, për të siguruar që shfletuesi i klientit të ngarkojë dhe të ekzekutojë vetëm kod nga një burim i besueshëm. Për shembull, script-src ‘self’ në listën e bardhë përfshin të gjithë skriptet vetëm nga faqja jonë.
Praktika më e mirë është të lejoni vetëm kodin Inline: lejoni vetëm javascript inline me vlerën unsafe-inline. Kjo vlerë lejon përdorimin e js/css inline, por nuk ndalon ngarkimin e skedarëve js. Në kombinim me script-src ‘self’ ndalojmë ekzekutimin e skenarëve të jashtëm.Sigurohuni të regjistroni gjithçka duke përdorur report-uri dhe shqyrtoni përpjekjet për introduktim në faqe.
- Injeksionet SQL.
Dobia tregon mundësinë e introduktimit të kodit SQL në faqe, i cili drejtohet direkt në bazën e të dhënave të faqes. Injeksioni SQL është i mundshëm nëse të dhënat nga përdoruesi nuk janë të shenjuara: nuk kontrollohen për korrektësi dhe përdoren menjëherë në kërkesë. Për shembull, kështu ndodh nëse forma në faqe nuk kontrollon përputhshmërinë e hyrjes me tipin e të dhënave.Çfarë rreziku ka: Nëse një sulmues fut një kërkesë SQL në një formë të tillë, ai mund të shkatërrojë bazën e të dhënave ose të nxjerrë informacion të ndjeshëm.
Çfarë duhet të mbajë mend zhvilluesi i uebit: Mos i besoni asaj që vjen nga shfletuesi. Duhet të mbroheni edhe në anën e klientit, edhe në anën e serverit.
Në anën e klientit, shkruani verifikimin e fushave me ndihmën e JavaScript.
Funksionet e ndërtuara në frameworket e njohura gjithashtu ndihmojnë në ekranuar simbolet e dyshimta në server. Në server, është gjithashtu e rekomanduar të përdoren kërkesat e parametrizuara për bazat e të dhënave.
Përcaktoni saktësisht ku ndodh ndërveprimi me bazën e të dhënave në aplikacionin web.
Ndërveprimi ndodh kur ne marrim ndonjë informacion: një kërkesë me id (ndryshimi i id), krijimi i një përdoruesi të ri, një koment i ri, - regjistrime të reja në bazë. Këtu mund të ndodhin sql-injeksione. Edhe nëse fshijmë një regjistrim nga baza, mund të ndodhi sql-injeksioni.
Rekomandime të përgjithshme
Mos shpikni biçikletën – përdorni frameworke të provuara. Në përgjithësi, frameworket e njohura janë më të sigurta. Për .NET – ky ë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.
Merrni parasysh azhurnimet e ofruesit dhe azhurnoni rregullisht. Do të gjejnë një dobësi, pastaj do të shkruajnë një exploit, do ta publikojnë në akses publik, dhe gjithçka do të përsëritet përsëri. Regjistrohuni për azhurnime deri në versionet stabile nga ofruesi i softuerit.
Kontrolloni të drejtat e aksesit. Nga ana e serverit, gjithmonë trajtoni kodin tuaj sikur të ishte shkruar nga armiku juaj më i urryer, i cili dëshiron të thyejë faqen tuaj dhe të dëmtojë integritetin e të dhënave tuaja. Sidomos, ndonjëherë, kjo vërtet ndodh.
Përdorni klonime, ambiente testimi, dhe pastaj derdhni në prodhim. Kjo do të ndihmojë, së pari, të shmangni gabimet dhe mangësitë në ambientin produktiv: ambienti produktiv sjell para, ndalimi i ambientit produktiv është kritik. Kur shtoni, korrigjoni ose mbyllni ndonjë problem, është e rëndësishme të bëni punët në një mjedis testimi, pastaj të kontrolloni funksionalitetin dhe dobësitë e gjetura, dhe pastaj të planifikoni punët me ambientin produktiv.
Mbroni aplikacionin web me dhe integro shkresa nga skaneri i dobësive. Për shembull, në DataLine si lidhje shërbimesh përdoren Qualys dhe FortiWeb.
Burimi: habr.com
