Duela urtebete inguru, DataLine-n jarri genuen martxan informatikako aplikazioetan ahultasunak bilatzeko eta aztertzeko. Zerbitzua Qualys hodeiko soluzioan oinarritzen da, horren funtzionamenduari buruz . Irtenbidearekin lan egin genuen urtebetean, 291 azterketa egin genituen gune ezberdinetarako eta web aplikazioetako ahultasun arruntei buruzko estatistikak metatu genituen.
Beheko artikuluan erakutsiko dizut zehatz-mehatz webgunearen segurtasunean zein zulo dauden kritikotasun maila ezberdinen atzean. Ikus dezagun zer ahultasun aurkitu zuen eskanerrak maiz, zergatik gerta daitezkeen eta nola babestu.
Qualys-ek web aplikazioen ahultasun guztiak hiru kritikotasun mailatan banatzen ditu: baxua, ertaina eta altua. βLarritasunaren araberaβ banaketari erreparatuz gero, badirudi dena ez dagoela hain gaizki. Kritikotasun maila handiko ahultasun gutxi daude, gehienetan guztiak ez-kritikoak dira:
Baina akritikoak ez du esan nahi kaltegabea. Kalte larriak ere eragin ditzakete.
Ahultasun "ez-kritiko" nagusiak
- Eduki mistoko ahultasunak.
Webgunearen segurtasunerako estandarra bezeroaren eta zerbitzariaren arteko datuak HTTPS protokoloaren bidez transferitzea da, enkriptatzea onartzen duena eta informazioa atzematetik babesten duena.
Zenbait gune erabiltzen eduki mistoa: Datu batzuk HTTP protokolo seguruaren bidez transferitzen dira. Horrela transmititzen da gehienetan eduki pasiboa β Gunearen bistaratzeari soilik eragiten dion informazioa: argazkiak, css estiloak. Baina batzuetan horrela transmititzen da eduki aktiboa: gunearen portaera kontrolatzen duten scriptak. Kasu honetan, software berezia erabiliz, zerbitzaritik datorren eduki aktiboa duen informazioa azter dezakezu, zure erantzunak berehala alda ditzakezu eta makinak bere sortzaileek nahi ez zuten moduan funtziona dezakezu.
Arakatzaileen bertsio berriek erabiltzaileei ohartarazten diete eduki mistoa duten guneak ez direla seguruak eta edukia blokeatzen dutela. Webguneetako garatzaileek arakatzailearen abisuak ere jasotzen dituzte kontsolan. Adibidez, horrela ikusten da :
Zergatik da arriskutsua?: Erasotzaileek protokolo seguru bat erabiltzen dute erabiltzailearen informazioa atzemateko, script-ak ordezkatzeko eta bere izenean gunera eskaerak bidaltzeko. Gune bisitari batek datuak sartu ez baditu ere, horrek ez du babesten phishing β isilpeko informazioa lortzea iruzurrezko metodoak erabiliz. Esate baterako, script bat erabiliz, erabiltzailea erabiltzailearentzat ezaguna den gune ez seguru batera birbideratu dezakezu. Zenbait kasutan, gune gaiztoak jatorrizkoak baino are itxura hobea du, eta erabiltzaileak inprimakia berak bete dezake eta isilpeko datuak bidal ditzake.Web garatzaile batek gogoratu behar duena: Gunearen administratzaileak SSL/TLS ziurtagiria instalatu eta konfiguratu badu ere, ahultasun bat sor daiteke giza akatsen ondorioz. Adibidez, orriren batean ez baduzu esteka erlatiboa jartzen, http-tik esteka absolutua baizik, eta horrez gain, ez baduzu http-tik https-rako birzuzenketarik ezarri.
Webgune batean eduki mistoa detekta dezakezu arakatzailea erabiliz: bilatu orriaren iturburu-kodea, irakurri jakinarazpenak garatzaileen kontsolan. Hala ere, garatzaileak denbora luzez eta lapurtera egin beharko du kodea. Prozesua bizkortu dezakezu analisi automatikoko tresnekin, adibidez: , Lighthouse software librea edo Screaming Frog SEO Spider ordainpeko softwarea.
Gainera, ahultasuna heredatu zen kode heredatuarekin izandako arazoengatik sor daiteke. Adibidez, orrialde batzuk txantiloi zahar bat erabiliz sortzen badira, eta horrek ez du kontuan hartzen webguneen https-rako trantsizioa.
- "HTTPOnly" eta "seguru" banderarik gabeko cookieak.
"HTTPOnly" atributuak cookieak babesten ditu erasotzaileek erabiltzaileen datuak lapurtzeko erabiltzen dituzten scriptek prozesatzeko. "Segurua" banderak ez du onartzen cookie-ak testu garbian bidaltzea. Cookieak bidaltzeko HTTPS protokolo segurua erabiltzen bada soilik komunikazioa onartuko da.
Bi atributuak cookieen propietateetan zehazten dira:
Set-Cookie: Secure; HttpOnlyZergatik da arriskutsua?: gunearen garatzaileak atributu hauek zehaztu ez baditu, erasotzaile batek cookietik erabiltzailearen informazioa atzeman eta ustiatu dezake. Autentifikaziorako eta baimenerako cookieak erabiltzen badira, erabiltzailearen saioa bahitu eta gunean ekintzak egin ahal izango ditu bere izenean.
Web garatzaile batek gogoratu behar duena: Oro har, esparru ezagunetan atributu hauek automatikoki ezartzen dira. Baina hala ere egiaztatu web zerbitzariaren konfigurazioa eta ezarri bandera: Set-Cookie HttpOnly; Segurua.
Kasu honetan, "HTTPOnly" atributuak cookieak ikusezin bihurtuko ditu zure JavaScriptentzat.
- Bideetan oinarritutako ahultasunak.
Eskanerrak ahultasun horren berri ematen du publikoki eskuragarri dagoen fitxategi edo webguneko direktorio bat aurkitzen badu konfidentziala izan daitekeen informazioa. Adibidez, sistemaren konfigurazio fitxategi indibidualak edo fitxategi sistema osorako sarbidea detektatzen ditu. Egoera hau posible da webgunean sarbide-eskubideak gaizki ezartzen badira.
Zergatik da arriskutsua?: Fitxategi-sistema "irtengo" bada, erasotzaile bat sistema eragilearen interfazera erori daiteke eta pasahitzak dituzten karpetak aurkitzen saiatuko dira testu garbian gordetzen badira (ez egin hori!). Edo pasahitzen hash-ak lapurtu ditzakezu eta pasahitza indar gordina, eta, gainera, sisteman pribilegioak handitzen eta azpiegituran sakontzen saiatu.
Web garatzaile batek gogoratu behar duena: Ez ahaztu sarbide-eskubideez eta konfiguratu plataforma, web zerbitzaria, web aplikazioa, web direktoriotik "ihes egitea" ezinezkoa izan dadin.
- Betetze automatikoa gaituta duten datu sentikorrak sartzeko inprimakiak.
Erabiltzaile batek maiz betetzen baditu webguneetako inprimakiak, bere arakatzaileak informazio hori gordetzen du automatikoki betetzeko eginbidea erabiliz.
Webguneetako inprimakiek informazio sentikorra duten eremuak izan ditzakete, hala nola pasahitzak edo kreditu-txartelen zenbakiak. Horrelako eremuetarako, merezi du inprimakiak betetze automatikoko funtzioa webgunean bertan desgaitzea.
Zergatik da arriskutsua?: Erabiltzailearen arakatzaileak informazio sentikorra gordetzen badu, erasotzaileak geroago atzeman dezake, adibidez phishing bidez. Funtsean, Γ±abardura hori ahaztu duen web garatzaile bat bere erabiltzaileak konfiguratzen ari da.
Web garatzaile batek gogoratu behar duena: Kasu honetan, gatazka klasiko bat dugu: erosotasuna vs segurtasuna. Web garatzaile bat erabiltzailearen esperientzian pentsatzen ari bada, osatze automatikoa aukera dezake kontzienteki. Adibidez, jarraitzea garrantzitsua bada β Desgaitasuna duten erabiltzaileentzako edukien irisgarritasunari buruzko gomendioak.
Arakatzaile gehienentzat, osatze automatikoa desgai dezakezu autocompete="off" atributuarekin, adibidez:
<body> <form action="/eu/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>Baina ez du funtzionatuko Chrome-n. JavaScript erabiliz saihesten da, errezetaren aldaera bat aurki daiteke .
- X-Frame-Options goiburua ez dago ezarrita gunearen kodean.
Goiburu honek marko, iframe, kapsulatu edo objektu etiketei eragiten die. Bere laguntzarekin, zure webgunea marko baten barruan txertatzea guztiz debekatu dezakezu. Horretarako, X-Frame-Options: deny balioa zehaztu behar duzu. Edo X-Frame-Options: bera jatorria zehaztu dezakezu, gero iframe batean txertatzea zure domeinuan soilik egongo da erabilgarri.
Zergatik da arriskutsua?: Horrelako goibururik eza gune gaiztoetan erabil daiteke clickjacking. Eraso honetarako, erasotzaileak marko garden bat sortzen du botoien gainean eta erabiltzailea engainatzen du. Adibidez: iruzurgileek sare sozialetako orriak webgune batean enkodratzen dituzte. Erabiltzaileak uste du gune honetako botoi bat sakatzen ari dela. Horren ordez, klika atzematen da eta erabiltzailearen eskaera saio aktibo bat dagoen sare sozialera bidaltzen da. Horrela erasotzaileek spam-a bidaltzen dute erabiltzailearen izenean edo harpidedunak eta atseginak lortzen dituzte.
Ez baduzu funtzio hau desgaitzen, erasotzaile batek zure aplikazioaren botoia gune gaizto batean jar dezake. Baliteke zure erreferentzia-programan edo zure erabiltzaileei interesa izatea.
Web garatzaile batek gogoratu behar duena: ahultasuna gerta daiteke balio gatazkatsua duen X-Frame-Options web zerbitzarian edo karga-orekatzailean ezartzen bada. Kasu honetan, zerbitzariak eta orekatzaileak goiburua berridatzi besterik ez du egingo, lehentasun handiagoa baitute backend kodearekin alderatuta.
X-Frame-Options goiburuaren ukatze eta jatorri berdineko balioek Yandex web-ikustailearen funtzionamendua oztopatuko dute. Web-ikustailerako iframes erabiltzeko, arau bereizi bat idatzi behar duzu ezarpenetan. Adibidez, nginx-erako honela konfigura dezakezu:
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) ahultasunak.
Hau gunearen estiloan ahultasun bat da. Estilo fitxategietara sartzeko href="/eu/somefolder/styles.css/" bezalako esteka erlatiboak erabiltzen badira gertatzen da. Erasotzaile batek horretaz aprobetxatuko du erabiltzailea orri gaizto batera birbideratzeko modua aurkitzen badu. Orrialdeak esteka erlatibo bat txertatuko du bere url-ean eta estilo-dei bat simulatuko du. badsite.ru/β¦/somefolder/styles.css/ bezalako eskaera bat jasoko duzu, estilo baten itxurapean ekintza gaiztoak egin ditzakeena.
Zergatik da arriskutsua?: Iruzurgile batek ahultasun hori ustiatu lezake beste segurtasun-zulo bat aurkitzen badu. Ondorioz, posible da erabiltzailearen datuak cookieetatik edo tokenetatik lapurtzea.
Web garatzaile batek gogoratu behar duena: Ezarri X-Content-Type-Options goiburua: nosniff. Kasu honetan, arakatzaileak estiloen eduki mota egiaztatuko du. Mota testua/css ez bada, arakatzaileak eskaera blokeatuko du.
Ahultasun kritikoak
- Pasahitz-eremua duen orri bat zerbitzaritik kanal ez seguru baten bidez transmititzen da (Pasahitz-eremuak dituen HTML inprimakia HTTP bidez hornitzen da).
Enkriptatutako kanal baten bidez zerbitzariaren erantzuna ahula da "Gizona erdian" erasoen aurrean. Erasotzaileak trafikoa atzeman dezake eta bezeroaren eta zerbitzariaren artean ziri egin dezake orria zerbitzaritik bezerora doan heinean.
Zergatik da arriskutsua?: Iruzurgileak orria ordezkatu eta erabiltzaileari datu konfidentzialak lortzeko formulario bat bidali ahal izango dio, erasotzailearen zerbitzarira joango dena.
Web garatzaile batek gogoratu behar duena: Gune batzuek erabiltzaileei behin-behineko kodea bidaltzen diete posta elektronikoz/telefonoz pasahitz baten ordez. Kasu honetan, ahultasuna ez da hain kritikoa, baina mekanismoak erabiltzaileen bizitza zailduko du.
- Saio-hasiera eta pasahitzarekin inprimaki bat bidaltzea kanal ez seguru baten bidez (Saio-hasiera formularioa ez da HTTPS bidez bidaltzen).
Kasu honetan, saio-hasiera eta pasahitza dituen formulario bat bidaltzen da erabiltzailetik zerbitzarira zifratu gabeko kanal baten bidez.
Zergatik da arriskutsua?: Aurreko kasuan ez bezala, hau dagoeneko ahultasun kritikoa da. Errazagoa da datu sentikorrak atzematea, ez duzulako kodea idatzi behar horretarako.
- Ahultasun ezagunak dituzten JavaScript liburutegiak erabiltzea.
Eskaneatu bitartean, liburutegirik erabiliena jQuery izan zen, bertsio ugarirekin. Bertsio bakoitzak ahultasun ezagun bat edo gehiago ditu gutxienez. Eragina oso ezberdina izan daiteke ahultasunaren izaeraren arabera.
Zergatik da arriskutsua?: Ezagutzen diren ahultasunetarako ustiapenak daude, adibidez:
Web garatzaile batek gogoratu behar duena: Aldian behin ziklora itzuli: ahultasun ezagunak bilatu - konpondu - egiaztatu. Oinarrizko liburutegiak nahita erabiltzen badituzu, adibidez, arakatzaile zaharragoak onartzeko edo dirua aurrezteko, bilatu ahultasun ezagun bat konpontzeko aukera. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), edo cross-site scripting, web-aplikazio baten aurkako eraso bat da, datu-basean malwarea sartzea eragiten duena. Qualys-ek ahultasun bat aurkitzen badu, esan nahi du erasotzaile potentzialak bere js script propioa sartu dezakeela edo dagoeneko sartu duela gunearen kodean ekintza gaiztoak egiteko.XSS gordeta arriskutsuagoa, scripta zerbitzarian txertatuta eta erasotutako orria nabigatzailean irekitzen den bakoitzean exekutatzen baita.
XSS islatua errazago gauzatzea, script maltzur bat HTTP eskaera batean sar daitekeelako. Aplikazioak HTTP eskaera bat jasoko du, ez ditu datuak balioztatuko, paketatu egingo ditu eta berehala bidaliko du. Erasotzaile batek trafikoa atzematen badu eta bezalako script bat txertatzen badu
<script>/*+ΡΡΠΎ+ΡΠΎ+ΠΏΠ»ΠΎΡ ΠΎΠ΅+*/</script>orduan eskaera maltzur bat bidaliko da bezeroaren izenean.
XSS-ren adibide deigarri bat: CVC, txartelaren iraungitze-data eta abar sartzeko orriak simulatzen dituzten js sniffer-ak.
Web garatzaile batek gogoratu behar duena: Content-Security-Policy goiburuan, erabili script-src atributua bezeroaren arakatzailea deskargatu eta exekutatu fidagarri batetik kodea bakarrik behartzeko. Adibidez, script-src 'self'-k gure guneko script guztiak zerrenda zurian jartzen ditu soilik.
Praktika onena Inline kodea da: onartu inline javascript bakarrik unsafe-inline balioa erabiliz. Balio honek inline js/css erabiltzea ahalbidetzen du, baina ez du debekatzen js fitxategiak sartzea. Script-src 'self'-ekin konbinatuta kanpoko scriptak exekutatzea desgaitzen dugu.Ziurtatu dena erregistratzen duzula report-uri erabiliz eta begiratu webgunean inplementatzeko saiakerak.
- SQL injekzioak.
Ahultasunak webgunearen datu basera zuzenean sartzen den webgune batean SQL kodea injektatzeko aukera adierazten du. SQL injekzioa posible da erabiltzailearen datuak ez badira pantailaratzen: ez da zuzentasuna egiaztatzen eta berehala erabiltzen da kontsultan. Adibidez, hau gertatzen da webgune bateko inprimaki batek ez badu egiaztatzen sarrera datu-motarekin bat datorren ala ez.Zergatik da arriskutsua?: Erasotzaile batek inprimaki honetan SQL kontsulta bat sartzen badu, datu-basea huts egin dezake edo isilpeko informazioa ager dezake.
Web garatzaile batek gogoratu behar duena: Ez fidatu nabigatzailetik datorrenarekin. Zure burua babestu behar duzu bai bezeroaren aldetik bai zerbitzariaren aldetik.
Bezeroaren aldetik, idatzi eremuaren baliozkotzea JavaScript erabiliz.
Esparru ezagunetan integratutako funtzioek zerbitzariko karaktere susmagarriak ihes egiten laguntzen dute. Zerbitzarian datu-baseko kontsulta parametrizatuak erabiltzea ere gomendatzen da.
Zehaztu datu-basearekiko elkarrekintza non gertatzen den web aplikazioan.
Elkarreragina edozein informazio jasotzen dugunean gertatzen da: id batekin eskaera bat (id aldaketa), erabiltzaile berri bat sortzea, iruzkin berri bat edo datu-basean sarrera berriak. Hemen SQL injekzioak gerta daitezke. Datu-basetik erregistro bat ezabatzen badugu ere, SQL injekzioa posible da.
Gomendio orokorrak
Ez birasmatu gurpila - erabili frogatutako esparruak. Oro har, esparru ezagunak seguruagoak dira. .NET - ASP.NET MVC eta ASP.NET Core, Python - Django edo Flask, Ruby - Ruby on Rails, PHP - Symfony, Laravel, Yii, JavaScript - Node.JS-Express.js, Java - Udaberriko MVC.
Jarraitu saltzaileen eguneraketak eta eguneratu aldizka. Ahultasun bat aurkituko dute, gero esplotazio bat idatzi, publikoki eskuragarri jarriko dute eta dena gertatuko da berriro. Harpidetu software-saltzailearen bertsio egonkorren eguneratzeetara.
Egiaztatu sarbide-eskubideak. Zerbitzariaren aldean, trata ezazu beti zure kodea, lehenengo letratik azkenera arte, zure etsai gorrotatuenak idatzi izan balu bezala, zure webgunea hautsi nahi duena, zure datuen osotasuna urratu nahi duena. Gainera, batzuetan hori egia da.
Erabili klonak, proba guneak eta, gero, erabili produkziorako. Horrek lagunduko du, lehenik eta behin, ingurune produktibo batean akatsak eta akatsak saihesten: ingurune produktibo batek dirua ekartzen du, ingurune produktibo sinple bat funtsezkoa da. Arazoren bat gehitzean, konpontzen edo ixtean, merezi du proba-ingurunean lan egitea, gero aurkitutako funtzionaltasunak eta ahultasunak egiaztatzea eta, ondoren, produkzio-ingurunearekin lan egitea planifikatzea.
Babestu zure web aplikazioarekin eta ahultasun-eskaneraren txostenak integratu harekin. Adibidez, DataLine-k Qualys eta FortiWeb erabiltzen ditu zerbitzu sorta gisa.
Iturria: www.habr.com