Mga isang taon na ang nakalipas, kami sa DataLine ay naglunsad upang maghanap at magsuri ng mga kahinaan sa mga aplikasyon ng IT. Ang serbisyo ay batay sa Qualys cloud solution, tungkol sa pagpapatakbo nito . Sa loob ng isang taon ng pagtatrabaho sa solusyon, nagsagawa kami ng 291 na pag-scan para sa iba't ibang mga site at naipon ang mga istatistika sa mga karaniwang kahinaan sa mga web application.
Sa artikulo sa ibaba ipapakita ko sa iyo nang eksakto kung anong mga butas sa seguridad ng website ang nakatago sa likod ng iba't ibang antas ng pagiging kritikal. Tingnan natin kung anong mga kahinaan ang madalas na natagpuan ng scanner, kung bakit maaaring mangyari ang mga ito, at kung paano protektahan ang iyong sarili.
Hinahati ng Qualys ang lahat ng mga kahinaan sa web application sa tatlong antas ng pagiging kritikal: mababa, katamtaman at mataas. Kung titingnan mo ang pamamahagi sa pamamagitan ng "kalubhaan", tila ang lahat ay hindi masyadong masama. Mayroong ilang mga kahinaan na may mataas na antas ng pagiging kritikal, karamihan sa lahat ay hindi kritikal:
Ngunit ang hindi kritikal ay hindi nangangahulugang hindi nakakapinsala. Maaari rin silang magdulot ng malubhang pinsala.
Mga nangungunang "hindi kritikal" na kahinaan
- Mga kahinaan ng pinaghalong nilalaman.
Ang pamantayan para sa seguridad ng website ay ang paglilipat ng data sa pagitan ng kliyente at ng server sa pamamagitan ng HTTPS protocol, na sumusuporta sa pag-encrypt at nagpoprotekta sa impormasyon mula sa pagharang.
Ginagamit ng ilang site halo-halong nilalaman: Ang ilang data ay inililipat sa pamamagitan ng hindi secure na HTTP protocol. Ito ay kung paano ito madalas ihatid passive na nilalaman β impormasyon na nakakaapekto lamang sa pagpapakita ng site: mga larawan, mga istilo ng css. Ngunit kung minsan ito ay kung paano ito naipapasa aktibong nilalaman: mga script na kumokontrol sa pag-uugali ng site. Sa kasong ito, gamit ang espesyal na software, maaari mong suriin ang impormasyon na may aktibong nilalaman na nagmumula sa server, baguhin ang iyong mga tugon sa mabilisang at gawin ang makina sa paraang hindi nilayon ng mga tagalikha nito.
Ang mga mas bagong bersyon ng mga browser ay nagbabala sa mga user na ang mga site na may halo-halong nilalaman ay hindi ligtas at hinaharangan ang nilalaman. Nakakatanggap din ang mga developer ng website ng mga babala sa browser sa console. Halimbawa, ganito ang hitsura nito :
Ano ang mapanganib: Gumagamit ang mga umaatake ng isang hindi secure na protocol upang maharang ang impormasyon ng user, palitan ang mga script at magpadala ng mga kahilingan sa site sa ngalan niya. Kahit na ang isang bisita sa site ay hindi nagpasok ng data, hindi ito pinoprotektahan mula sa kanya phishing β pagkuha ng kumpidensyal na impormasyon gamit ang mga mapanlinlang na pamamaraan. Halimbawa, gamit ang isang script, maaari mong i-redirect ang user sa isang hindi ligtas na site na nagpapanggap bilang isang pamilyar sa user. Sa ilang mga kaso, mas maganda ang hitsura ng nakakahamak na site kaysa sa orihinal, at maaaring punan mismo ng user ang form at magsumite ng kumpidensyal na data.Ano ang dapat tandaan ng isang web developer: Kahit na nag-install at nag-configure ang administrator ng site ng SSL/TLS certificate, maaaring magkaroon ng kahinaan dahil sa human error. Halimbawa, kung sa isa sa mga pahina ay hindi ka naglagay ng kamag-anak na link, ngunit isang ganap na link mula sa http, at bilang karagdagan hindi ka nag-set up ng mga pag-redirect mula sa http patungo sa https.
Maaari mong makita ang halo-halong content sa isang site gamit ang isang browser: hanapin ang source code ng page, basahin ang mga notification sa developer console. Gayunpaman, ang developer ay kailangang mag-tinker sa code sa loob ng mahabang panahon at nakakapagod. Maaari mong pabilisin ang proseso gamit ang mga awtomatikong tool sa pagsusuri, halimbawa: , libreng Lighthouse software o bayad na software Screaming Frog SEO Spider.
Gayundin, maaaring lumitaw ang kahinaan dahil sa mga problema sa legacy-code - code na minana. Halimbawa, kung ang ilang mga pahina ay nabuo gamit ang isang lumang template, na hindi isinasaalang-alang ang paglipat ng mga site sa https.
- Cookies na walang "HTTPOnly" at "secure" na mga flag.
Pinoprotektahan ng attribute na "HTTPonly" ang cookies mula sa pagpoproseso ng mga script na ginagamit ng mga attacker para magnakaw ng data ng user. Hindi pinapayagan ng "secure" na flag na maipadala ang cookies sa malinaw na text. Papayagan lang ang komunikasyon kung gagamitin ang secure na HTTPS protocol para ipadala ang cookie.
Ang parehong mga katangian ay tinukoy sa mga katangian ng cookie:
Set-Cookie: Secure; HttpOnlyAno ang mapanganib: Kung hindi tinukoy ng developer ng site ang mga katangiang ito, maaaring harangin ng isang attacker ang impormasyon ng user mula sa cookie at pagsamantalahan ito. Kung ginagamit ang cookies para sa pagpapatunay at awtorisasyon, magagawa niyang i-hijack ang session ng user at magsagawa ng mga aksyon sa site sa ngalan niya.
Ano ang dapat tandaan ng isang web developer: Bilang panuntunan, sa mga sikat na framework ang mga katangiang ito ay awtomatikong itinatakda. Ngunit suriin pa rin ang configuration ng web server at itakda ang bandila: Set-Cookie HttpOnly; Secure.
Sa kasong ito, gagawin ng attribute na βHTTPOnlyβ na hindi nakikita ng iyong sariling JavaScript ang cookies.
- Path-Based Vulnerabilities.
Ang scanner ay nag-uulat ng gayong kahinaan kung makakita ito ng pampublikong naa-access na file o direktoryo ng website na may potensyal na kumpidensyal na impormasyon. Halimbawa, nakita nito ang mga indibidwal na file ng configuration ng system o access sa buong file system. Posible ang sitwasyong ito kung ang mga karapatan sa pag-access ay hindi naitakda nang tama sa site.
Ano ang mapanganib: Kung "lumabas" ang file system, maaaring mahulog ang isang attacker sa interface ng operating system at subukang maghanap ng mga folder na may mga password kung nakaimbak ang mga ito sa malinaw na text (huwag gawin iyon!). O maaari mong nakawin ang mga hash ng password at malupit na puwersahin ang password, at subukan din na itaas ang mga pribilehiyo sa system at lumipat nang mas malalim sa imprastraktura.
Ano ang dapat tandaan ng isang web developer: Huwag kalimutan ang tungkol sa mga karapatan sa pag-access at i-configure ang platform, web server, web application upang imposibleng "makatakas" sa web directory.
- Mga form para sa pagpasok ng sensitibong data na naka-enable ang auto-fill.
Kung madalas na pinupunan ng isang user ang mga form sa mga website, iniimbak ng kanilang browser ang impormasyong ito gamit ang tampok na autofill.
Ang mga form sa mga website ay maaaring magsama ng mga field na may sensitibong impormasyon, gaya ng mga password o numero ng credit card. Para sa mga naturang field, sulit na huwag paganahin ang function ng form na autofill sa mismong site.
Ano ang mapanganib: Kung nag-iimbak ang browser ng user ng sensitibong impormasyon, maaaring harangin ito ng isang attacker sa ibang pagkakataon, halimbawa sa pamamagitan ng phishing. Sa esensya, isang web developer na nakalimutan ang tungkol sa nuance na ito ay nagse-set up sa kanyang mga user.
Ano ang dapat tandaan ng isang web developer: Sa kasong ito, mayroon kaming isang klasikong salungatan: kaginhawahan laban sa seguridad. Kung ang isang web developer ay nag-iisip tungkol sa karanasan ng user, maaari niyang sinasadyang pumili ng autocomplete. Halimbawa, kung mahalagang sundin β mga rekomendasyon para sa pagiging naa-access ng nilalaman para sa mga user na may mga kapansanan.
Para sa karamihan ng mga browser, maaari mong i-disable ang autocomplete gamit ang autocompete="off" attribute, halimbawa:
<body> <form action="/tl/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>Ngunit hindi ito gagana para sa Chrome. Ito ay iniiwasan gamit ang JavaScript, isang variant ng recipe ang mahahanap .
- Ang header ng X-Frame-Options ay hindi nakatakda sa code ng site.
Nakakaapekto ang header na ito sa mga tag ng frame, iframe, embed, o object. Sa tulong nito, maaari mong ganap na ipagbawal ang pag-embed ng iyong site sa loob ng isang frame. Upang gawin ito, kailangan mong tukuyin ang halaga ng X-Frame-Options: deny. O maaari mong tukuyin ang X-Frame-Options: sameorigin, pagkatapos ay ang pag-embed sa isang iframe ay magiging available lang sa iyong domain.
Ano ang mapanganib: Ang kawalan ng naturang header ay maaaring gamitin sa mga nakakahamak na site upang clickjacking. Para sa pag-atakeng ito, ang umaatake ay gumagawa ng transparent na frame sa ibabaw ng mga button at nililinlang ang user. Halimbawa: ang mga scammer ay nag-frame ng mga social networking page sa isang website. Iniisip ng user na nagki-click siya sa isang button sa site na ito. Sa halip, ang pag-click ay naharang at ang kahilingan ng user ay ipinadala sa social network kung saan mayroong aktibong session. Ito ay kung paano magpadala ng spam ang mga umaatake sa ngalan ng user o makakuha ng mga subscriber at like.
Kung hindi mo idi-disable ang feature na ito, maaaring ilagay ng attacker ang iyong application button sa isang nakakahamak na site. Maaaring interesado siya sa iyong referral program o sa iyong mga user.
Ano ang dapat tandaan ng isang web developer: Ang kahinaan ay maaaring mangyari kung ang X-Frame-Options na may magkasalungat na halaga ay nakatakda sa web server o load balancer. Sa kasong ito, muling isusulat ng server at balancer ang header, dahil mas mataas ang priyoridad nila kumpara sa backend code.
Ang pagtanggi at parehong mga halaga ng pinagmulan ng X-Frame-Options na header ay makagambala sa pagpapatakbo ng Yandex web viewer. Upang payagan ang paggamit ng mga iframe para sa web viewer, kailangan mong magsulat ng hiwalay na panuntunan sa mga setting. Halimbawa, para sa nginx maaari mong i-configure ito tulad nito:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Mga kahinaan sa PRSSI (Path-relative stylesheet import).
Isa itong kahinaan sa pag-istilo ng site. Ito ay nangyayari kung ang mga kaugnay na link tulad ng href="/tl/somefolder/styles.css/" ay ginagamit upang ma-access ang mga style file. Sasamantalahin ito ng isang umaatake kung makakahanap sila ng paraan para i-redirect ang user sa isang malisyosong page. Ang page ay maglalagay ng kamag-anak na link sa url nito at gayahin ang isang style na tawag. Makakatanggap ka ng kahilingan tulad ng badsite.ru/β¦/somefolder/styles.css/, na maaaring magsagawa ng mga nakakahamak na aksyon sa ilalim ng pagkukunwari ng isang istilo.
Ano ang mapanganib: Maaaring samantalahin ng isang manloloko ang kahinaang ito kung makakita sila ng isa pang butas sa seguridad. Bilang resulta, posibleng magnakaw ng data ng user mula sa cookies o mga token.
Ano ang dapat tandaan ng isang web developer: Itakda ang header ng X-Content-Type-Options sa: nosniff. Sa kasong ito, susuriin ng browser ang uri ng nilalaman para sa mga estilo. Kung ang uri ay iba sa text/css, iba-block ng browser ang kahilingan.
Mga kritikal na kahinaan
- Ang isang page na may field ng password ay ipinapadala mula sa server sa isang hindi secure na channel (Ang HTML form na naglalaman ng (mga) field ng password ay inihahatid sa HTTP).
Ang tugon mula sa server sa isang hindi naka-encrypt na channel ay mahina sa mga pag-atake ng "Man in the middle". Maaaring harangin ng isang attacker ang trapiko at i-wedge ang sarili nito sa pagitan ng client at server habang naglalakbay ang page mula sa server patungo sa client.
Ano ang mapanganib: Mapapalitan ng manloloko ang pahina at magpadala sa user ng isang form para sa kumpidensyal na data, na mapupunta sa server ng umaatake.
Ano ang dapat tandaan ng isang web developer: Ang ilang mga site ay nagpapadala sa mga user ng isang beses na code sa pamamagitan ng email/telepono sa halip na isang password. Sa kasong ito, ang kahinaan ay hindi masyadong kritikal, ngunit ang mekanismo ay magpapalubha sa buhay ng mga gumagamit.
- Pagpapadala ng isang form na may login at password sa isang hindi secure na channel (Ang Form sa Pag-login ay Hindi Isinumite sa pamamagitan ng HTTPS).
Sa kasong ito, ang isang form na may login at password ay ipinapadala mula sa user patungo sa server sa pamamagitan ng hindi naka-encrypt na channel.
Ano ang mapanganib: Hindi tulad ng nakaraang kaso, isa na itong kritikal na kahinaan. Mas madaling ma-intercept ang sensitibong data dahil hindi mo na kailangan pang magsulat ng code para magawa ito.
- Paggamit ng mga library ng JavaScript na may alam na mga kahinaan.
Sa panahon ng pag-scan, ang pinaka ginagamit na library ay ang jQuery na may malawak na bilang ng mga bersyon. Ang bawat bersyon ay may hindi bababa sa isa, o higit pa, kilalang mga kahinaan. Ang epekto ay maaaring ibang-iba depende sa katangian ng kahinaan.
Ano ang mapanganib: May mga pagsasamantala para sa mga kilalang kahinaan, halimbawa:
Ano ang dapat tandaan ng isang web developer: Regular na bumalik sa cycle: maghanap para sa mga kilalang kahinaan - ayusin - suriin. Kung sinasadya mong gumamit ng mga legacy na library, halimbawa para suportahan ang mga mas lumang browser o para makatipid ng pera, maghanap ng pagkakataon para ayusin ang isang kilalang kahinaan. - Cross-site scripting (XSS).
Ang Cross-Site Scripting (XSS), o cross-site scripting, ay isang pag-atake sa isang web application na nagreresulta sa pagpasok ng malware sa database. Kung nakita ni Qualys ang ganoong kahinaan, nangangahulugan ito na ang isang potensyal na umaatake ay maaari o naipakilala na ang kanyang sariling js script sa code ng site upang magsagawa ng mga nakakahamak na aksyon.Nakaimbak na XSS mas mapanganib, dahil ang script ay naka-embed sa server at isinasagawa sa tuwing bubuksan ang inaatakeng pahina sa browser.
Sinasalamin ang XSS mas madaling isagawa dahil ang isang malisyosong script ay maaaring maipasok sa isang kahilingan sa HTTP. Makakatanggap ang application ng HTTP request, hindi magpapatunay ng data, ipapakete ito, at ipapadala kaagad. Kung ang isang attacker ay humarang sa trapiko at nagpasok ng isang script tulad ng
<script>/*+ΡΡΠΎ+ΡΠΎ+ΠΏΠ»ΠΎΡ ΠΎΠ΅+*/</script>pagkatapos ay isang malisyosong kahilingan ang ipapadala sa ngalan ng kliyente.
Isang kapansin-pansing halimbawa ng XSS: js sniffers na gayahin ang mga page para sa pagpasok ng CVC, petsa ng pag-expire ng card, at iba pa.
Ano ang dapat tandaan ng isang web developer: Sa header ng Content-Security-Policy, gamitin ang script-src attribute para pilitin ang client browser na i-download at i-execute lang ang code mula sa pinagkakatiwalaang source. Halimbawa, pina-whitelist ng script-src 'self' ang lahat ng script mula sa aming site lamang.
Ang pinakamahusay na kasanayan ay Inline code: payagan lamang ang inline na javascript gamit ang hindi ligtas na inline na halaga. Pinapayagan ng value na ito ang paggamit ng inline na js/css, ngunit hindi ipinagbabawal ang pagsasama ng mga js file. Sa kumbinasyon ng script-src 'sarili' hindi namin pinapagana ang mga panlabas na script na maisakatuparan.Tiyaking i-log ang lahat gamit ang report-uri at tingnan ang mga pagtatangka na ipatupad ito sa site.
- SQL injection.
Ang kahinaan ay nagpapahiwatig ng posibilidad ng pag-inject ng SQL code sa isang website na direktang nag-a-access sa database ng website. Posible ang SQL injection kung hindi na-screen ang data mula sa user: hindi ito sinusuri kung tama at agad itong ginagamit sa query. Halimbawa, nangyayari ito kung hindi titingnan ng isang form sa isang website kung tumutugma ang input sa uri ng data.Ano ang mapanganib: Kung ang isang attacker ay nagpasok ng isang SQL query sa form na ito, maaari niyang i-crash ang database o magbunyag ng kumpidensyal na impormasyon.
Ano ang dapat tandaan ng isang web developer: Huwag magtiwala sa kung ano ang nanggagaling sa browser. Kailangan mong protektahan ang iyong sarili sa parehong panig ng kliyente at sa panig ng server.
Sa panig ng kliyente, isulat ang pagpapatunay ng field gamit ang JavaScript.
Nakakatulong din ang mga built-in na function sa mga sikat na framework para makatakas sa mga kahina-hinalang character sa server. Inirerekomenda din na gumamit ng parameterized na mga query sa database sa server.
Tukuyin kung saan eksaktong nagaganap ang pakikipag-ugnayan sa database sa web application.
Nagaganap ang pakikipag-ugnayan kapag nakatanggap kami ng anumang impormasyon: isang kahilingan na may isang id (pagbabago ng id), ang paglikha ng isang bagong user, isang bagong komento, o mga bagong entry sa database. Dito maaaring mangyari ang mga SQL injection. Kahit na magtanggal kami ng record mula sa database, posible ang SQL injection.
Pangkalahatang mga rekomendasyon
Huwag muling likhain ang gulong - gumamit ng mga napatunayang balangkas. Sa pangkalahatan, mas secure ang mga sikat na framework. Para sa .NET - ASP.NET MVC at ASP.NET Core, para sa Python - Django o Flask, para sa Ruby - Ruby on Rails, para sa PHP - Symfony, Laravel, Yii, para sa JavaScript - Node.JS-Express.js, para sa Java - Spring MVC.
Sundin ang mga update ng vendor at regular na mag-update. Makakahanap sila ng kahinaan, pagkatapos ay magsulat ng pagsasamantala, gawin itong available sa publiko, at mangyayari muli ang lahat. Mag-subscribe sa mga update sa mga matatag na bersyon mula sa vendor ng software.
Suriin ang mga karapatan sa pag-access. Sa panig ng server, palaging ituring ang iyong code na parang ito, mula sa una hanggang sa huling titik, ay isinulat ng iyong pinakakinasusuklaman na kaaway, na gustong sirain ang iyong site, lumalabag sa integridad ng iyong data. Bukod dito, kung minsan ito ay totoo.
Gumamit ng mga clone, mga site ng pagsubok, at pagkatapos ay gamitin ang mga ito para sa produksyon. Makakatulong ito, una, upang maiwasan ang mga pagkakamali at pagkakamali sa isang produktibong kapaligiran: ang isang produktibong kapaligiran ay nagdudulot ng pera, ang isang simpleng produktibong kapaligiran ay kritikal. Kapag nagdaragdag, nag-aayos o nagsasara ng anumang problema, sulit na magtrabaho sa isang kapaligiran ng pagsubok, pagkatapos ay suriin ang pag-andar at mga kahinaan na natagpuan, at pagkatapos ay pagpaplanong magtrabaho kasama ang kapaligiran ng produksyon.
Protektahan ang iyong web application gamit ang at isama rito ang mga ulat mula sa vulnerability scanner. Halimbawa, ang DataLine ay gumagamit ng Qualys at FortiWeb bilang isang bundle ng mga serbisyo.
Pinagmulan: www.habr.com