Жил орчмын өмнө бид DataLine компанийг эхлүүлсэн Мэдээллийн технологийн хэрэглээний эмзэг байдлыг хайж, дүн шинжилгээ хийх. Энэхүү үйлчилгээ нь Qualys үүлэн шийдэл дээр суурилдаг бөгөөд түүний үйл ажиллагааны талаар . Энэхүү шийдэлтэй ажилласан жилийн хугацаанд бид өөр өөр сайтуудад 291 удаа скан хийж, вэб програмын нийтлэг эмзэг байдлын талаарх статистик мэдээллийг цуглуулсан.
Доорх нийтлэлд би вэбсайтын аюулгүй байдлын янз бүрийн түвшний шүүмжлэлийн ард яг ямар цоорхой нуугдаж байгааг харуулах болно. Сканнер ямар эмзэг байдлыг ихэвчлэн илрүүлдэг, яагаад тэдгээр нь тохиолдож болох, өөрийгөө хэрхэн хамгаалах талаар харцгаая.
Qualys нь вэб програмын бүх эмзэг байдлыг бага, дунд, өндөр гэсэн гурван түвшинд хуваадаг. Хэрэв та хуваарилалтыг "хүнд" байдлаар нь харвал бүх зүйл тийм ч муу биш юм шиг санагддаг. Өндөр түвшний эгзэгтэй сул талууд цөөн байдаг бөгөөд ихэнхдээ бүгд чухал биш байдаг:
Гэхдээ шүүмжлэлгүй гэдэг нь хор хөнөөлгүй гэсэн үг биш юм. Тэд бас ноцтой хохирол учруулж болзошгүй.
Шилдэг "чухал бус" сул талууд
- Холимог агуулгын эмзэг байдал.
Вэбсайтын аюулгүй байдлын стандарт нь шифрлэлтийг дэмждэг, мэдээллийг саатуулахаас хамгаалдаг HTTPS протоколоор дамжуулан үйлчлүүлэгч болон серверийн хооронд өгөгдөл дамжуулах явдал юм.
Зарим сайтууд ашигладаг холимог агуулга: Зарим өгөгдлийг аюулгүй HTTP протоколоор дамжуулдаг. Үүнийг ихэвчлэн ингэж дамжуулдаг идэвхгүй агуулга - зөвхөн сайтын дэлгэцэнд нөлөөлдөг мэдээлэл: зураг, css загвар. Гэхдээ заримдаа ийм байдлаар дамждаг идэвхтэй агуулга: сайтын үйл ажиллагааг хянадаг скриптүүд. Энэ тохиолдолд тусгай программ хангамжийг ашиглан серверээс ирж буй идэвхтэй контент бүхий мэдээлэлд дүн шинжилгээ хийж, хариултаа шууд өөрчилж, машиныг бүтээгчийн төлөвлөөгүй байдлаар ажиллуулах боломжтой.
Хөтөчүүдийн шинэ хувилбарууд нь холимог агуулгатай сайтууд аюултай гэдгийг хэрэглэгчдэд анхааруулж, агуулгыг блоклодог. Вэбсайт хөгжүүлэгчид мөн хөтчийн анхааруулгыг консол дээр хүлээн авдаг. Жишээлбэл, энэ нь дотроо иймэрхүү харагдаж байна :
Ямар аюултай вэ: Халдагчид хэрэглэгчийн мэдээллийг таслан зогсоох, скриптийг солих, түүний өмнөөс сайт руу хүсэлт илгээхийн тулд аюулгүй бус протокол ашигладаг. Сайтын зочин мэдээлэл оруулаагүй байсан ч энэ нь түүнийг хамгаалахгүй фишинг – хууран мэхлэх аргыг ашиглан нууц мэдээллийг олж авах. Жишээлбэл, скрипт ашиглан та хэрэглэгчийг танил болсон мэт харагдуулдаг аюултай сайт руу дахин чиглүүлэх боломжтой. Зарим тохиолдолд хортой сайт нь эх хувилбараасаа ч илүү сайн харагддаг бөгөөд хэрэглэгч өөрөө маягтыг бөглөж, нууц мэдээллийг илгээх боломжтой.Вэб хөгжүүлэгч юу санаж байх ёстой: Сайтын админ SSL/TLS сертификат суулгаж тохируулсан байсан ч хүний буруугаас болж эмзэг байдал үүсч болзошгүй. Жишээлбэл, хэрэв та аль нэг хуудсан дээр харьцангуй холбоос биш, харин http-ээс үнэмлэхүй холбоос байрлуулсан бөгөөд үүнээс гадна та http-ээс https руу чиглүүлэлтийг тохируулаагүй болно.
Та хөтөч ашиглан сайт дээрх холимог агуулгыг илрүүлэх боломжтой: хуудасны эх кодыг хайх, хөгжүүлэгчийн консол дээрх мэдэгдлүүдийг унших. Гэсэн хэдий ч хөгжүүлэгч кодтой удаан, уйтгартай ажиллах шаардлагатай болно. Та автоматжуулсан шинжилгээний хэрэгслээр үйл явцыг хурдасгаж болно, жишээлбэл: , үнэгүй Lighthouse програм хангамж эсвэл төлбөртэй програм хангамж Screaming Frog SEO Spider.
Түүнчлэн, удамшсан код - кодтой холбоотой асуудлаас болж эмзэг байдал үүсч болно. Жишээлбэл, сайтуудыг https руу шилжүүлэхийг харгалздаггүй хуучин загвар ашиглан зарим хуудсыг үүсгэсэн бол.
- "Зөвхөн HTTP" болон "аюулгүй" дарцаггүй күүки.
"Зөвхөн HTTP" шинж чанар нь халдагчид хэрэглэгчийн мэдээллийг хулгайлахад ашигладаг скриптээр күүки боловсруулахаас хамгаалдаг. "Аюулгүй" туг нь күүкийг тодорхой текстээр илгээхийг зөвшөөрдөггүй. Зөвхөн аюулгүй HTTPS протоколыг күүки илгээхэд ашигладаг бол харилцаа холбоог зөвшөөрөх болно.
Хоёр шинж чанарыг күүкийн шинж чанарт зааж өгсөн болно:
Set-Cookie: Secure; HttpOnlyЯмар аюултай вэ: Хэрэв сайтын хөгжүүлэгч эдгээр шинж чанаруудыг заагаагүй бол халдагчид күүки дэх хэрэглэгчийн мэдээллийг таслан авч, түүнийг ашиглах боломжтой. Хэрэв күүки нь баталгаажуулалт, зөвшөөрөлд ашиглагдаж байгаа бол тэрээр хэрэглэгчийн сессийг хулгайлж, түүний өмнөөс сайт дээр үйлдэл хийх боломжтой болно.
Вэб хөгжүүлэгч юу санаж байх ёстой: Дүрмээр бол түгээмэл хүрээнүүдэд эдгээр шинж чанаруудыг автоматаар тохируулдаг. Гэсэн хэдий ч вэб серверийн тохиргоог шалгаж, тугийг тохируулна уу: Set-Cookie HttpOnly; Аюулгүй.
Энэ тохиолдолд "Зөвхөн HTTP" атрибут нь күүкиг таны JavaScript-д харагдахгүй болгоно.
- Замд суурилсан эмзэг байдал.
Сканнер нь олон нийтэд нээлттэй файл эсвэл нууц мэдээлэл бүхий вэбсайтын лавлахыг олсон тохиолдолд ийм эмзэг байдлын талаар мэдээлдэг. Жишээлбэл, энэ нь системийн тохиргооны файлууд эсвэл бүхэл бүтэн файлын системд хандах хандалтыг илрүүлдэг. Сайт дээр нэвтрэх эрхийг буруу тохируулсан тохиолдолд ийм нөхцөл байдал үүсч болно.
Ямар аюултай вэ: Хэрэв файлын систем "гацаж" байвал халдагчид үйлдлийн системийн интерфейс рүү орж, нууц үг бүхий хавтаснуудыг тодорхой текстээр хадгалсан бол олохыг оролдож болно (үүнийг бүү хий!). Эсвэл та нууц үгийн хэшийг хулгайлж, нууц үгээ харгис хүчээр ашиглахаас гадна систем дэх давуу эрхээ дээшлүүлж, дэд бүтцэд илүү гүнзгий орохыг оролдож болно.
Вэб хөгжүүлэгч юу санаж байх ёстой: Хандалтын эрхийн талаар бүү мартаарай, платформ, вэб сервер, вэб програмыг тохируулж, вэб лавлахаас "зугтах" боломжгүй болно.
- Автоматаар бөглөх идэвхжсэн үед нууц мэдээлэл оруулах маягтууд.
Хэрэв хэрэглэгч вэбсайтууд дээр байнга маягт бөглөдөг бол тэдний хөтөч автоматаар бөглөх функцийг ашиглан энэ мэдээллийг хадгалдаг.
Вэбсайт дээрх маягтууд нь нууц үг эсвэл зээлийн картын дугаар гэх мэт эмзэг мэдээлэл бүхий талбаруудыг агуулж болно. Ийм талбаруудын хувьд сайт дээрх маягтыг автоматаар бөглөх функцийг идэвхгүй болгох нь зүйтэй.
Ямар аюултай вэ: Хэрэглэгчийн хөтөч нууц мэдээллийг хадгалдаг бол халдагчид дараа нь, жишээ нь фишингээр дамжуулан саад хийх боломжтой. Нэг ёсондоо энэ нюансыг мартсан вэб хөгжүүлэгч хэрэглэгчдээ тохируулж байна.
Вэб хөгжүүлэгч юу санаж байх ёстой: Энэ тохиолдолд бид сонгодог зөрчилдөөнтэй байна: ая тухтай байдал, аюулгүй байдал. Хэрэв вэб хөгжүүлэгч хэрэглэгчийн туршлагын талаар бодож байгаа бол тэрээр ухамсартайгаар автоматаар бөглөхийг сонгох боломжтой. Жишээлбэл, дагах нь чухал бол – хөгжлийн бэрхшээлтэй хэрэглэгчдэд зориулсан контентыг хүртээмжтэй болгох зөвлөмж.
Ихэнх хөтчүүдийн хувьд та autocompete="off" атрибутаар автомат бөглөхийг идэвхгүй болгож болно, жишээлбэл:
<body> <form action="/mn/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>Гэхдээ энэ нь Chrome-д ажиллахгүй. Үүнийг JavaScript ашиглан тойрч гарсан тул жорны хувилбарыг олж болно .
- X-Frame-Options-ийн толгой хэсгийг сайтын кодонд тохируулаагүй болно.
Энэ толгой хэсэг нь фрейм, iframe, оруулах эсвэл объектын шошгонд нөлөөлдөг. Түүний тусламжтайгаар та өөрийн сайтыг хүрээ дотор оруулахыг бүрэн хориглож болно. Үүнийг хийхийн тулд та X-Frame-Options: deny утгыг зааж өгөх хэрэгтэй. Эсвэл та X-Frame-Options: sameorigin-ийг зааж өгч болно, дараа нь iframe-д оруулах нь зөвхөн таны домэйнд боломжтой болно.
Ямар аюултай вэ: Ийм гарчиг байхгүй тохиолдолд хортой сайтуудад ашиглаж болно clickjacking. Энэ халдлагын хувьд халдагчид товчлууруудын дээр ил тод хүрээ үүсгэж, хэрэглэгчийг хуурдаг. Жишээ нь: луйварчид вэб сайт дээр нийгмийн сүлжээний хуудсуудыг жаазалдаг. Хэрэглэгч өөрийгөө энэ сайтын товчлуур дээр дарж байна гэж бодож байна. Үүний оронд товшилтыг таслан зогсоож, хэрэглэгчийн хүсэлтийг идэвхтэй сесс байгаа нийгмийн сүлжээнд илгээдэг. Ингэж халдагчид хэрэглэгчийн нэрийн өмнөөс спам илгээж эсвэл захиалагч, лайк дардаг.
Хэрэв та энэ функцийг идэвхгүй болгохгүй бол халдагчид таны програмын товчлуурыг хортой сайт дээр байрлуулж болно. Тэр таны лавлагааны хөтөлбөр эсвэл таны хэрэглэгчдийг сонирхож магадгүй юм.
Вэб хөгжүүлэгч юу санаж байх ёстой: Хэрэв вэб сервер эсвэл ачааллын тэнцвэржүүлэгч дээр зөрчилтэй утгатай X-Frame-Options тохируулагдсан бол эмзэг байдал үүсч болно. Энэ тохиолдолд сервер болон тэнцвэржүүлэгч нь арын кодтой харьцуулахад илүү чухал ач холбогдолтой тул толгой хэсгийг дахин бичих болно.
X-Frame-Options толгой хэсгийн үгүйсгэх болон ижил гарал үүслийн утгууд нь Yandex вэб үзүүлэгчийн ажиллагаанд саад болно. Вэб үзэгчдэд iframes ашиглахыг зөвшөөрөхийн тулд тохиргоонд тусдаа дүрэм бичих хэрэгтэй. Жишээлбэл, nginx-ийн хувьд та үүнийг дараах байдлаар тохируулж болно:
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) сул талууд.
Энэ нь сайтын хэв маягийн эмзэг байдал юм. Хэв маягийн файлд хандахын тулд href="/mn/somefolder/styles.css/" гэх мэт харьцангуй холбоосуудыг ашигладаг бол энэ нь тохиолддог. Халдагчид хэрэглэгчийг хортой хуудас руу дахин чиглүүлэх арга олсон тохиолдолд үүнийг ашиглах болно. Энэ хуудас нь өөрийн URL-д харьцангуй холбоос оруулж, загварын дуудлагыг дуурайлгана. Та badsite.ru/…/somefolder/styles.css/ гэх мэт хүсэлтийг хүлээж авах бөгөөд энэ нь хэв маягийн нэрийн дор хорлонтой үйлдэл хийх боломжтой.
Ямар аюултай вэ: Луйварчин өөр хамгаалалтын цоорхой олбол энэ эмзэг байдлыг ашиглаж болно. Үүний үр дүнд күүки эсвэл жетоноос хэрэглэгчийн мэдээллийг хулгайлах боломжтой.
Вэб хөгжүүлэгч юу санаж байх ёстой: X-Content-Type-Options толгой хэсгийг: nosniff болгож тохируулна уу. Энэ тохиолдолд хөтөч нь загварын агуулгын төрлийг шалгана. Хэрэв төрөл нь текст/css-ээс өөр байвал хөтөч хүсэлтийг блоклох болно.
Чухал эмзэг байдал
- Нууц үгийн талбар бүхий хуудсыг серверээс найдваргүй сувгаар дамжуулдаг (нууц үгийн талбар(ууд) агуулсан HTML хэлбэрийг HTTP-ээр дамжуулдаг).
Шифрлэгдээгүй сувгаар серверийн хариу үйлдэл нь "Дунд байгаа хүн" халдлагад өртөмтгий байдаг. Хуудас серверээс үйлчлүүлэгч рүү шилжих үед халдагчид траффикийг таслан зогсоож, үйлчлүүлэгч болон серверийн хооронд шахаж болно.
Ямар аюултай вэ: Луйварчин хуудсыг сольж, халдагчийн сервер рүү нэвтрэх нууц мэдээллийн маягтыг хэрэглэгч рүү илгээх боломжтой болно.
Вэб хөгжүүлэгч юу санаж байх ёстой: Зарим сайтууд хэрэглэгчдэд нууц үгийн оронд нэг удаагийн кодыг имэйл/утасаар илгээдэг. Энэ тохиолдолд эмзэг байдал нь тийм ч чухал биш боловч механизм нь хэрэглэгчдийн амьдралыг улам хүндрүүлнэ.
- Аюулгүй сувгаар нэвтрэх болон нууц үг бүхий маягт илгээж байна (Нэвтрэх маягтыг HTTPS-ээр илгээгээгүй).
Энэ тохиолдолд хэрэглэгчийн нэр, нууц үг бүхий маягтыг шифрлэгдээгүй сувгаар сервер рүү илгээдэг.
Ямар аюултай вэ: Өмнөх тохиолдлоос ялгаатай нь энэ нь аль хэдийн чухал эмзэг байдал юм. Үүнийг хийхийн тулд код бичих шаардлагагүй тул эмзэг өгөгдлийг саатуулах нь илүү хялбар байдаг.
- Мэдэгдэж буй сул талуудтай JavaScript сангуудыг ашиглах.
Скан хийх явцад хамгийн их ашиглагддаг номын сан бол олон тооны хувилбартай jQuery байв. Хувилбар бүр дор хаяж нэг, эсвэл бүр олон мэдэгдэж буй сул талуудтай. Эмзэг байдлын шинж чанараас хамааран нөлөө нь маш өөр байж болно.
Ямар аюултай вэ: Мэдэгдэж буй сул талуудын мөлжлөгүүд байдаг, жишээлбэл:
Вэб хөгжүүлэгч юу санаж байх ёстой: Тогтмол мөчлөг рүү буцах: мэдэгдэж буй сул талуудыг хайх - засах - шалгах. Хэрэв та хуучин хөтчүүдийг дэмжих эсвэл мөнгө хэмнэх зорилгоор хуучин номын сангуудыг зориудаар ашигладаг бол мэдэгдэж буй сул талыг засах боломжийг хайж үзээрэй. - Сайт хоорондын скрипт (XSS).
Cross-Site Scripting (XSS) буюу сайт хоорондын скрипт нь вэб программ руу халдлага үйлдэж, мэдээллийн санд хортой програм нэвтрүүлэхэд хүргэдэг. Хэрэв Qualys ийм эмзэг байдлыг олсон бол энэ нь болзошгүй халдагчид хортой үйлдэл хийх өөрийн js скриптийг сайтын кодонд оруулсан эсвэл аль хэдийн оруулсан гэсэн үг юм.Хадгалсан XSS Скриптийг сервер дээр суулгаж, халдлагад өртсөн хуудсыг хөтөч дээр нээх болгонд ажиллуулдаг тул илүү аюултай.
XSS-ийг тусгасан HTTP хүсэлтэд хортой скрипт оруулах боломжтой тул үүнийг хийхэд хялбар байдаг. Аппликешн нь HTTP хүсэлтийг хүлээн авах бөгөөд өгөгдлийг баталгаажуулахгүй, багцалж, шууд илгээнэ. Хэрэв халдагчид замын хөдөлгөөнд саад болж, скрипт оруулбал
<script>/*+что+то+плохое+*/</script>дараа нь үйлчлүүлэгчийн нэрийн өмнөөс хортой хүсэлт илгээгдэх болно.
XSS-ийн гайхалтай жишээ: js sniffers нь CVC оруулах хуудас, картын хүчинтэй байх хугацаа гэх мэтийг дуурайдаг.
Вэб хөгжүүлэгч юу санаж байх ёстой: Content-Security-Policy толгой хэсэгт script-src атрибутыг ашиглан үйлчлүүлэгчийн хөтчийг зөвхөн итгэмжлэгдсэн эх сурвалжаас код татаж аваад ажиллуулахыг албадаарай. Жишээлбэл, script-src 'self' нь зөвхөн манай сайтын бүх скриптийг цагаан жагсаалтад оруулдаг.
Хамгийн сайн туршлага бол Inline код: зөвхөн inline-inline утгыг ашиглан шугаман JavaScript-г зөвшөөрөх. Энэ утга нь inline js/css ашиглахыг зөвшөөрдөг боловч js файлуудыг оруулахыг хориглодоггүй. script-src 'self'-тэй хослуулан бид гадаад скриптүүдийг гүйцэтгэхийг идэвхгүй болгодог.report-uri-г ашиглан бүх зүйлийг бүртгэж, сайтад хэрэгжүүлэх оролдлогуудыг анхаарч үзээрэй.
- SQL тарилга.
Энэ эмзэг байдал нь вэб сайтын мэдээллийн санд шууд ханддаг вэб сайт руу SQL код оруулах боломжтойг харуулж байна. Хэрэглэгчийн өгөгдлийг шалгаагүй тохиолдолд SQL тарилга хийх боломжтой: энэ нь зөв эсэхийг шалгаагүй бөгөөд асуулгад шууд ашиглагддаг. Жишээлбэл, вэбсайт дээрх маягт нь оролт нь өгөгдлийн төрөлтэй таарч байгаа эсэхийг шалгаагүй тохиолдолд ийм зүйл тохиолддог.Ямар аюултай вэ: Хэрэв халдагчид энэ маягт руу SQL асуулга оруулбал өгөгдлийн санг эвдэх эсвэл нууц мэдээллийг илчлэх боломжтой.
Вэб хөгжүүлэгч юу санаж байх ёстой: Хөтөчөөс ирдэг зүйлд бүү итгэ. Та үйлчлүүлэгч болон серверийн аль алинд нь өөрийгөө хамгаалах хэрэгтэй.
Үйлчлүүлэгч тал дээр JavaScript ашиглан талбарын баталгаажуулалтыг бичнэ үү.
Түгээмэл хүрээн дэх суулгасан функцууд нь сервер дээрх сэжигтэй тэмдэгтүүдээс зайлсхийхэд тусалдаг. Мөн сервер дээр параметржүүлсэн мэдээллийн сангийн асуулга ашиглахыг зөвлөж байна.
Мэдээллийн сантай харьцах ажиллагаа вэб програм дээр яг хаана явагддагийг тодорхойл.
Бид ямар нэгэн мэдээлэл хүлээн авах үед харилцан үйлчлэл үүсдэг: id бүхий хүсэлт (id-ийн өөрчлөлт), шинэ хэрэглэгч үүсгэх, шинэ сэтгэгдэл эсвэл мэдээллийн санд шинэ оруулгууд. Энд SQL тарилга хийх боломжтой. Бид өгөгдлийн сангаас бичлэг устгасан ч SQL injection хийх боломжтой.
Ерөнхий зөвлөмжүүд
Дугуйг дахин бүү зохион бүтээгээрэй - батлагдсан хүрээ ашиглана уу. Дүрмээр бол алдартай хүрээ нь илүү найдвартай байдаг. .NET - ASP.NET MVC болон ASP.NET Core, Python-д - Django эсвэл Flask, Ruby-д - Ruby on Rails, PHP-д - Symfony, Laravel, Yii, JavaScript-д - Node.JS-Express.js, Java-д зориулагдсан. - Хаврын MVC.
Борлуулагчийн шинэчлэлтүүдийг дагаж, тогтмол шинэчилж байх. Тэд эмзэг байдлыг олж, дараа нь мөлжлөг бичиж, олон нийтэд нээлттэй болгож, бүх зүйл дахин болно. Програм хангамж үйлдвэрлэгчээс тогтвортой хувилбаруудын шинэчлэлтийг захиалаарай.
Хандалтын эрхийг шалгана уу. Серверийн тал дээр таны кодыг эхний үсгээс сүүлчийн үсэг хүртэл таны сайтыг эвдэж, мэдээллийн бүрэн бүтэн байдлыг зөрчихийг хүссэн хамгийн үзэн яддаг дайсан бичсэн мэт харьц. Түүнээс гадна заримдаа энэ нь үнэн юм.
Клон, туршилтын талбайг ашигла, дараа нь тэдгээрийг үйлдвэрлэхэд ашиглана. Энэ нь нэгдүгээрт, үр бүтээлтэй орчинд алдаа, алдаа гаргахаас зайлсхийхэд тусална: бүтээмжтэй орчин мөнгө авчирдаг, энгийн бүтээмжтэй орчин нь чухал юм. Аливаа асуудлыг нэмэх, засах, хаахдаа туршилтын орчинд ажиллаж, дараа нь олдсон функциональ болон сул талуудыг шалгаж, үйлдвэрлэлийн орчинтой ажиллахаар төлөвлөх нь зүйтэй.
Өөрийн вэб программыг хамгаалаарай эмзэг байдлын сканнерын тайлангуудтай нэгтгэх. Жишээлбэл, DataLine нь Qualys болон FortiWeb-ийг багц үйлчилгээ болгон ашигладаг.
Эх сурвалж: www.habr.com