DIQQAT! ModSecurity’dagi yangi zaifliklar WAF himoyasini chetlab o‘tishga imkon berishi mumkin!

OWASP ModSecurity — veb-ilovalarni turli kiberhujumlardan himoya qilish uchun qo‘llaniladigan ochiq kodli Web Application Firewall (WAF) vositasidir. U veb-ilovalarga kelayotgan HTTP so‘rovlarini tekshiradi, shubhali yoki zararli ma’lumotlarni aniqlaydi va xavfsizlik qoidalariga mos kelmaydigan so‘rovlarni bloklaydi. ModSecurity Apache HTTP Server, Nginx va Microsoft IIS kabi veb-serverlar bilan birgalikda ishlatiladi.

2026-yil 30-sentabr kuni ModSecurity’da bir nechta yangi xavfsizlik zaifliklari aniqlangani va ular bo‘yicha tegishli tavsiyalar e’lon qilingani ma’lum qilindi. Ayrim zaifliklar hujumchilarga WAF tomonidan amalga oshiriladigan tekshiruvlarni chetlab o‘tish va zararli so‘rovlarni himoyalangan veb-ilovaga yetkazish imkonini berishi mumkin.

Bu holat ModSecurity’dan foydalanayotgan tashkilotlar uchun muhim ahamiyatga ega. Chunki WAF qoidalari zararli so‘rovlarni aniqlashda asosiy himoya vositalaridan biri hisoblanadi. Agar WAF ma’lumotni noto‘g‘ri qayta ishlasa yoki uni ilovadan boshqacha talqin qilsa, ayrim zararli so‘rovlar aniqlanmay qolishi mumkin.

Zaifliklar qanday xavf tug‘diradi?

WAF’ning asosiy vazifalaridan biri — foydalanuvchidan kelayotgan HTTP so‘rovni ilovaga yetib borishidan oldin tahlil qilishdir. Masalan, tizim SQL Injection, XSS, buyruq kiritish, zararli fayl yuklash yoki boshqa xavfli harakatlarni aniqlasa, so‘rovni bloklashi mumkin.

Ammo xavfsizlik vositasi bilan himoyalanayotgan ilova bir xil ma’lumotni turlicha talqin qilsa, xavfli holat yuzaga keladi. Bunda WAF so‘rovni xavfsiz deb qabul qilishi, backend esa ayni ma’lumotni boshqa shaklda qayta ishlab, zararli mazmunni qabul qilishi mumkin.

Yangi zaifliklarning katta qismi aynan shunday tahlil va qayta ishlashdagi nomuvofiqliklar bilan bog‘liq.

RFC 2231 filename* parametri orqali WAF tekshiruvini chetlab o‘tish

Eng jiddiy muammolardan biri GHSA-5pww-8rfg-9crf sifatida qayd etilgan bo‘lib, u multipart HTTP so‘rovlaridagi RFC 2231 standartiga mos filename* parametrini qayta ishlash bilan bog‘liq. Ushbu zaiflik High darajada baholangan.

Multipart so‘rovlar, odatda, veb-saytlarga fayl yuklash jarayonida ishlatiladi. Masalan, foydalanuvchi hujjat, rasm yoki boshqa faylni yuklaganida, uning nomi va boshqa ma’lumotlari HTTP so‘rovi tarkibida yuboriladi.

Muammo shundaki, ModSecurity fayl nomini tekshirishda ma’lum qoidalardan foydalanadi, backend ilova esa RFC talablariga muvofiq filename* qiymatini boshqa tarzda talqin qilishi mumkin. Rasmiy tavsifda Go, Python, Node.js va Java kabi texnologiyalarda ishlaydigan RFC-mos backendlar bilan bunday nomuvofiqlik yuzaga kelishi mumkinligi ko‘rsatilgan.

Natijada hujumchi maxsus shakllantirilgan fayl yuklash so‘rovini yuborib, WAF tekshiruvini chetlab o‘tishi mumkin. Masalan, xavfsizlik qoidasi shubhali fayl kengaytmasi yoki fayl nomini bloklashga mo‘ljallangan bo‘lsa, ModSecurity uni bir ko‘rinishda ko‘rishi, backend esa boshqa qiymatni qabul qilishi ehtimoli mavjud.

Bu esa WAF va himoyalanayotgan veb-ilova o‘rtasida xavfsizlik bo‘shlig‘i paydo bo‘lishiga olib keladi.

Base64 ma’lumotlarini noto‘g‘ri qayta ishlash

Yana bir muammo GHSA-4j47-8qcr-jf59 identifikatori bilan qayd etilgan. Ushbu zaiflik ModSecurity’dagi t:base64DecodeExt transformatsiya funksiyasiga taalluqli bo‘lib, Moderate darajada baholangan.

Mazkur funksiya Base64 ko‘rinishidagi ma’lumotlarni dekodlash uchun ishlatiladi. Biroq noto‘g‘ri yoki buzilgan Base64 padding guruhi uchraganida, funksiya dekodlangan ma’lumotni to‘liq yoki kutilgan shaklda qaytarmasligi mumkin.

Bu esa xavfsizlik qoidalariga ta’sir qiladi. Chunki ModSecurity zararli mazmunni aniqlashdan oldin ma’lumotni dekodlashi mumkin. Agar dekodlash jarayonida ma’lumot yo‘qolsa yoki noto‘g‘ri ko‘rinishga kelsa, keyingi xavfsizlik qoidasi zararli satrni aniqlay olmasligi ehtimoli paydo bo‘ladi.

Hujumchilar esa SQL Injection, XSS, buyruq kiritish yoki web shell kabi zararli yuklamalarni turli kodlash usullari yordamida yashirishga urinishi mumkin.

Shu sababli WAF uchun nafaqat oddiy, balki noto‘g‘ri shakllantirilgan yoki maxsus kodlangan ma’lumotlarni ham to‘g‘ri qayta ishlash muhim ahamiyatga ega.

Izohlarni olib tashlash mexanizmidagi muammo

GHSA-qrch-pjfr-9g47 zaifligi esa removeComments transformatsiyasiga tegishli. Ushbu mexanizm ma’lumot tarkibidagi izohlarni olib tashlab, keyinchalik xavfsizlik qoidalari tomonidan tekshiriladigan ma’lumotni normallashtirish uchun ishlatiladi. Zaiflik Moderate darajada baholangan.

Muammo ketma-ket joylashgan ayrim izohlar to‘liq olib tashlanmaganda yuzaga keladi. Hujumchi zararli buyruq, SQL so‘rovi yoki boshqa shubhali ifoda qismlari orasiga maxsus izohlarni joylashtirib, WAF qoidalarini chalg‘itishga urinishi mumkin.

Agar ModSecurity so‘rovni to‘liq normallashtira olmasa, xavfsizlik qoidasi zararli ifodani aniqlamasligi mumkin. Backend esa mazkur ma’lumotni boshqa usulda qayta ishlab, uni bajarishi yoki qabul qilishi ehtimoldan xoli emas.

PCRE2 xatosi ham xavfsizlik qoidalariga ta’sir qilishi mumkin

Yana bir zaiflik — GHSA-5m93-4h75-3p2w — PCRE2 kutubxonasidan foydalanadigan @rxGlobal operatorining match-limit xatolarini qayta ishlash bilan bog‘liq.

Rasmiy tavsifga ko‘ra, ma’lum sharoitlarda PCRE2 tomonidan qaytarilgan match-limit xatosi “mos kelmadi” holati sifatida talqin qilinishi mumkin.

Bu holat ham muayyan xavfsizlik qoidalarining ishlashiga ta’sir ko‘rsatib, zararli ma’lumotni aniqlash jarayonida kutilmagan natijaga olib kelishi mumkin.

Boshqa aniqlangan muammolar

2026-yil 30-sentabrda e’lon qilingan tavsiyalar faqat yuqoridagi uchta muammo bilan cheklanmaydi.

Rasmiy ModSecurity xavfsizlik ro‘yxatida quyidagi muammolar ham qayd etilgan:

• GHSA-jx3r-phvx-2jmj — ModSecurity v3 XML request body processor’da ishga tushirilmagan ko‘rsatkichdan foydalanish bilan bog‘liq High darajadagi zaiflik;
• GHSA-vmg8-j66p-vgvw — javob tarkibini tekshirishni chetlab o‘tishga olib kelishi mumkin bo‘lgan High darajadagi muammo;
• GHSA-rcw9-2f5r-7p88 — multipart/form-data parserining shakllangan ma’lumotlarni noto‘g‘ri qayta ishlashi natijasida so‘rov tarkibini tekshirishni chetlab o‘tish imkoniyati;
• GHSA-2vqc-36qp-ccmw — HttpsClient::download funksiyasida TLS host nomini tekshirish bilan bog‘liq muammo;
• shuningdek, ayrim platforma va funksiyalarga tegishli boshqa zaifliklar ham mavjud.

Bu muammolarning barchasi bir xil oqibatga olib kelmaydi. Ayrimlari WAF qoidalarini chetlab o‘tishga, boshqalari esa xizmatning barqarorligiga yoki ma’lumotlarni qayta ishlash jarayoniga ta’sir qilishi mumkin.

ModSecurity foydalanuvchilari nima qilishi kerak?

Tashkilotlarda ModSecurity ishlatilayotgan bo‘lsa, WAF versiyasi va konfiguratsiyasini tekshirish muhim. OWASP ModSecurity loyihasi rasmiy ravishda v2.9.x va v3.0.x tarmoqlarini qo‘llab-quvvatlashini bildirgan.

Shuningdek, 2026-yil 29-iyundagi rasmiy yangilanishda multipart parser bilan bog‘liq CVE-2026-52747 va i386 arxitekturasidagi utf8toUnicode muammosi uchun v3.0.16 versiyasiga yangilash tavsiya etilgan.

Shu sababli mutaxassislarga quyidagi choralarni ko‘rish tavsiya etiladi:

1. ModSecurity versiyasini tekshirish.
Serverlarda o‘rnatilgan ModSecurity/libModSecurity versiyasini aniqlash va tegishli xavfsizlik tavsiyalaridagi ta’sirlangan versiyalar bilan solishtirish lozim.

2. Eng so‘nggi xavfsizlik yangilanishlarini o‘rnatish.
Ishlab chiquvchi tomonidan taqdim etilgan tuzatishlar mavjud bo‘lsa, WAF komponentlarini qo‘llab-quvvatlanadigan va tuzatilgan versiyalarga yangilash kerak. Rasmiy relizlarda yangi aniqlangan muammolar uchun tegishli tuzatishlar kiritilgan.

3. WAF qoidalarini qayta sinovdan o‘tkazish.
Ayniqsa fayl yuklash, multipart/form-data, Base64 kodlangan ma’lumotlar, XML, izohlar bilan ajratilgan so‘rovlar va murakkab regular expression qoidalari alohida tekshirilishi kerak.

4. WAF va backend o‘rtasidagi ma’lumot talqinini solishtirish.
Ilova serveri va WAF bir xil HTTP so‘rovni turlicha qayta ishlayotgan bo‘lsa, hujumchi ushbu farqdan foydalanib, xavfsizlik qoidalarini chetlab o‘tishi mumkin.

5. Faqat WAF himoyasiga tayanib qolmaslik.
WAF muhim himoya qatlamlaridan biri bo‘lsa-da, u yagona xavfsizlik mexanizmi sifatida qaralmasligi kerak. Ilovalarning o‘zida autentifikatsiya, avtorizatsiya, fayl yuklashni nazorat qilish, kiritilayotgan ma’lumotlarni tekshirish, server monitoringi va jurnal yuritish kabi qo‘shimcha himoya mexanizmlari ham ishlashi lozim.

6. Jurnallarni muntazam tahlil qilish.
WAF tomonidan rad etilgan yoki shubhali deb topilgan so‘rovlar, noodatiy multipart so‘rovlar, takroriy kodlangan ma’lumotlar va xavfsizlik qoidalarini ishga tushirishga urinishlar muntazam tahlil qilinishi kerak.

ModSecurity’da aniqlangan yangi zaifliklar WAF himoyasining o‘zi ham muntazam ravishda yangilanib, sinovdan o‘tkazilishi zarurligini ko‘rsatmoqda. Ayniqsa, WAF tomonidan tahlil qilinayotgan ma’lumot bilan backend tomonidan qayta ishlanayotgan ma’lumot o‘rtasidagi farq hujumchilar uchun xavfsizlik qoidalarini chetlab o‘tish imkoniyatini yaratishi mumkin.

Shu bois ModSecurity administratorlari o‘rnatilgan versiyalarni tekshirishi, rasmiy xavfsizlik tavsiyalarini muntazam kuzatishi, mavjud yangilanishlarni o‘z vaqtida o‘rnatishi va WAF qoidalarini turli kodlangan, buzilgan, multipart hamda maxsus shakllantirilgan so‘rovlar yordamida sinab borishi zarur.

Kiberxavfsizlikda himoyaning samaradorligi faqat zararli so‘rovni aniqlashga emas, balki WAF, veb-server va ilovaning bir xil ma’lumotni izchil va xavfsiz qayta ishlashiga ham bog‘liq.