Ma'lumotlar ochiqlanishi: debug rejim, xato sahifalari va marshrutlar ro'yxati

Ma'lumotlar ochiqlanishi (information disclosure) ko'pincha "kichik" zaiflik hisoblanadi: u o'zi tizimni buzmaydi. Lekin u hujumchiga eng qimmatli narsani beradi — tizim qanday tuzilgani haqidagi bilimni. Qaysi framework, qaysi versiya, qaysi fayl yo'llari, qaysi yashirin admin marshrutlari bor — bularning barchasi keyingi hujumni rejalashtirishni osonlashtiradi.

O'z mahsulotimiz (soliq-moliya SaaS platformasi) ekspertizasida ma'lumotlar ochiqlanishi bo'yicha ikkita alohida topilma bo'lgan. Ularni va boshqa tipik manbalarni ko'rib chiqamiz.

1. Brauzerga chiqarilgan marshrutlar ro'yxati

Laravel + Inertia yoki Vue/React loyihalarida Ziggy paketi keng ishlatiladi. U backend'dagi nomlangan marshrutlarni JavaScript'da route('users.show', id) ko'rinishida ishlatish imkonini beradi. Qulay, lekin standart sozlamada Ziggy barcha marshrutlarni sahifaga JSON sifatida joylaydi.

Natijada har qanday tashrif buyuruvchi sahifa manbasini ochib, quyidagilarni ko'radi:

• admin.* marshrutlari va ularning URL'lari;
• ichki API endpoint'lari;
• test, debug yoki eski funksiyalar uchun qoldirilgan marshrutlar;
• parametrlar nomlari (masalan, {organization}/{user}).

Bu aynan bizning ekspertizada qayd etilgan holat edi. Yechim — brauzerga faqat frontend haqiqatan ishlatadigan marshrutlarni berish. Ziggy'da buni config/ziggy.php orqali qilish mumkin:

return [
    'only' => ['home', 'login', 'dashboard', 'invoices.*', 'profile.*'],
    // yoki: 'except' => ['admin.*', 'debugbar.*', 'horizon.*', 'telescope.*'],
];

Agar admin va oddiy foydalanuvchi interfeysi bitta ilovada bo'lsa, guruhlardan foydalaning va admin marshrutlarini faqat admin sahifalariga uzating. Esda tuting: marshrutni yashirish himoya emas, u faqat xaritani kichraytiradi. Har bir marshrut baribir server tomonda avtorizatsiya bilan himoyalangan bo'lishi shart.

2. Javoblardagi ortiqcha ma'lumotlar

Ikkinchi topilma — API va Inertia javoblarida keragidan ko'p ma'lumot qaytishi. Masalan, model to'g'ridan-to'g'ri return $user; qilib qaytarilsa, unga parol xeshi, ichki identifikatorlar, xizmat maydonlari yoki bog'langan modellar qo'shilib ketishi mumkin. Frontend ularni ko'rsatmasa ham, ular tarmoq javobida ko'rinadi.

Yechim:

• modellarda $hidden ro'yxatini to'ldiring (password, remember_token, ikki faktorli maxfiy kalitlar);
• yaxshisi — API Resource yoki aniq massiv bilan faqat kerakli maydonlarni qaytaring;
• Inertia'da global share() ichiga butun foydalanuvchi modelini emas, faqat kerakli maydonlarni qo'ying.

return [
    'id' => $user->id,
    'name' => $user->name,
    'role' => $user->role,
];

3. Debug rejim va stack trace

APP_DEBUG=true production'da qolsa, har qanday xato batafsil sahifani chiqaradi: to'liq fayl yo'llari, kod parchalari, so'rov parametrlari, ba'zan muhit o'zgaruvchilari ham. Bu ma'lumotlar ochiqlanishining eng og'ir ko'rinishi.

Production uchun .env:

APP_ENV=production
APP_DEBUG=false

O'zgartirgandan keyin konfiguratsiya keshini yangilang (php artisan config:cache), aks holda eski qiymat ishlashda davom etishi mumkin. Shuningdek:

• Debugbar, Telescope kabi vositalar production'da o'chirilgan yoki qat'iy himoyalangan bo'lsin;
• /.env, /.git/, /storage/logs/ kabi yo'llar veb orqali ochilmasligini tekshiring;
• xato sahifalari (404, 500) o'zingizning sodda shablonlaringiz bo'lsin, ichki tafsilotsiz.

4. Server versiyasi sarlavhalari

Ko'p serverlar javobda o'z nomi va versiyasini aytadi:

Server: nginx/1.18.0
X-Powered-By: PHP/8.1.2

Versiyani bilish hujumchiga shu versiyaga tegishli ma'lum zaifliklarni qidirishni osonlashtiradi. Yashirish oson:

# nginx.conf, http blokida
server_tokens off;

; php.ini
expose_php = Off

Bu serverni yangilashning o'rnini bosmaydi, lekin keraksiz ma'lumot berishni to'xtatadi.

Qoida: production'dagi har bir javob faqat foydalanuvchiga kerakli narsani o'z ichiga olishi kerak. Qolgan hamma narsa — log faylda, server ichida.

O'zingiz tekshirib ko'ring

Bir necha daqiqada bajariladigan tekshiruvlar:

1. Sahifa manbasini oching (Ctrl+U) va admin, api, debug so'zlarini qidiring.
2. Mavjud bo'lmagan manzilni oching (/test-404-xyz) va xato sahifasida ichki tafsilot bor-yo'qligini ko'ring.
3. Brauzerning DevTools, Network bo'limida javob sarlavhalarini tekshiring: Server, X-Powered-By.
4. Bir nechta API javobini oching va ekranda ko'rinmaydigan maydonlar bor-yo'qligini ko'ring.
5. /.env va /.git/config manzillarini sinab ko'ring — ikkalasi ham 404 yoki 403 qaytarishi kerak.

Terminal orqali sarlavhalarni ko'rish:

curl -sI https://example.uz | grep -iE 'server|x-powered-by'

Standartlar

OWASP Top 10 (2021) ro'yxatida bu muammolar A05 "Security Misconfiguration" va A01 "Broken Access Control" bilan bog'liq. CWE'da asosiy toifa — CWE-200 (Exposure of Sensitive Information), stack trace uchun esa CWE-209. OWASP ASVS'ning xatolar va loglar bo'limi production'da batafsil xato chiqarmaslikni talab qiladi.

Xulosa

Ma'lumotlar ochiqlanishi odatda bir necha qator konfiguratsiya bilan yopiladi, lekin uni topish uchun tizimni hujumchi ko'zi bilan ko'rish kerak. Bizning jarayonda Claude AI agenti konfiguratsiya fayllari, marshrutlar va javob tuzilmalarini tez ko'rib chiqadi, mutaxassis esa har bir topilmani tasdiqlaydi va tuzatadi.

Loyihangiz ortiqcha ma'lumot berayotganini bilmoqchi bo'lsangiz, skanerlash uchun ariza qoldiring. Biz bunday teshiklarni rasmiy ekspertizadan oldin topib, yopishga yordam beramiz.