.env faylini internetdan himoyalash: parollar sizib chiqmasligi uchun

Zamonaviy PHP va Node.js loyihalarida barcha maxfiy sozlamalar odatda bitta .env faylida saqlanadi: ma'lumotlar bazasining logini va paroli, pochta serveri ma'lumotlari, to'lov tizimlarining kalitlari, Telegram bot tokeni va hokazo. Bu juda qulay, chunki kod va sozlamalar bir-biridan ajraladi. Ammo bu fayl veb-serverning ochiq papkasida turib qolsa, uni brauzerda https://example.uz/.env manzilini terib, oddiy matn sifatida o'qish mumkin bo'ladi. Bitta shunday so'rov hujumchiga saytingizning deyarli barcha kalitlarini beradi.

Nega bu xato ko'p uchraydi

Laravel kabi framework'lar loyihani shunday tuzadiki, veb-serverning ildizi faqat public papkasiga yo'naltirilishi kerak, .env esa undan bir daraja yuqorida turadi. Muammo loyiha hostingga ko'chirilganda paydo bo'ladi: dasturchi butun loyihani sayt ildiziga tashlaydi va public/index.php ga yo'naltirish uchun .htaccess qo'shadi. Natijada .env ham ildizda qoladi va server sozlamasiga qarab uni to'g'ridan-to'g'ri berib yuboradi. Xuddi shu holat .env.backup, .env.old yoki tahrirlovchi qoldirgan .env~ kabi nusxalar bilan ham yuz beradi, ular ko'pincha unutiladi.

Internetda bunday fayllarni qidiradigan botlar to'xtovsiz ishlaydi. Sayt kirish jurnallarini ochsangiz, /.env, /api/.env, /laravel/.env kabi so'rovlarni deyarli har kuni ko'rasiz. Bu sayt nishonga olinganini emas, balki avtomatik skanerlar barcha manzillarni ketma-ket tekshirib chiqayotganini bildiradi, shuning uchun "mening saytim kichik, kimga kerak" degan fikr bu yerda ishlamaydi.

Saytingizni qanday tekshirish mumkin

Eng oddiy tekshiruv terminalda curl buyrug'i bilan qilinadi. Javob kodi 403 yoki 404 bo'lsa va sahifa mazmunida DB_PASSWORD kabi qatorlar bo'lmasa, fayl yopiq. Agar 200 kodi qaytsa va fayl mazmuni chiqsa, zudlik bilan choralar ko'rish kerak. Tekshiruvni asosiy domen, www versiyasi va subdomenlar uchun alohida qiling, chunki ular turli papkalarga qarashi mumkin.

curl -s -o /dev/null -w "%{http_code}\n" https://example.uz/.env
curl -s https://example.uz/.env | head -5

# jurnalda kim so'raganini ko'rish
grep '"GET /.env' access.log | tail -20

Eng to'g'ri yechim: faylni veb-ildizdan tashqariga chiqarish

Hech qanday qoida faylni veb-ildizdan tashqarida saqlashchalik ishonchli emas. Agar veb-server faylni umuman "ko'rmasa", uni xato sozlama bilan ham berib yubora olmaydi. VPS'da yoki panel sayt papkasini o'zgartirishga ruxsat berganda, ildizni loyihaning public papkasiga yo'naltiring. sayt.uz hostingida bu sozlama ISPmanager panelida bo'ladi va panelning o'zi sayt.uz kabinetidan ochiladi; aniq qadamlarni bilmasangiz, texnik yordamdan so'rash mumkin.

/home/user/example.uz/
├── .env              # veb orqali ko'rinmaydi
├── app/
├── vendor/
└── public/           # veb-server ildizi shu yerda
    └── index.php

Agar fayl ildizda qolishi shart bo'lsa

Ba'zan hosting tuzilmasi ildizni o'zgartirishga imkon bermaydi. Bunday holda nuqta bilan boshlanadigan barcha fayllarga kirishni veb-server darajasida taqiqlash kerak. Apache 2.4 uchun quyidagi qoida .htaccess fayliga yoziladi va .env hamda uning barcha nusxalarini yopadi. Nginx'da esa yashirin fayllarni yopuvchi location bloki qo'shiladi, lekin Let's Encrypt sertifikati uchun kerak bo'ladigan .well-known papkasi istisno qilinadi.

# .htaccess (Apache 2.4)
<FilesMatch "^\.env">
    Require all denied
</FilesMatch>

# Nginx: server { } bloki ichida
location ~ /\.(?!well-known) {
    deny all;
    return 404;
}

Qoidani qo'shgandan keyin yuqoridagi curl tekshiruvini qayta bajaring. Nginx sozlamasini o'zgartirgach, avval nginx -t bilan sintaksisni tekshirish va keyin systemctl reload nginx qilish kerak, aks holda yangi qoida kuchga kirmaydi.

Fayl huquqlari va Git

Veb orqali yopish bilan birga faylning serverdagi huquqlari ham muhim. .env faqat sayt egasi bo'lgan foydalanuvchi tomonidan o'qilishi kerak, boshqa foydalanuvchilar uchun esa butunlay yopiq bo'lishi lozim. Bundan tashqari, fayl hech qachon Git repozitoriyasiga tushmasligi kerak: repozitoriyaga kerakli o'zgaruvchilar ro'yxatini qiymatlarsiz saqlaydigan .env.example qo'yiladi.

chmod 600 .env
echo ".env" >> .gitignore
git rm --cached .env   # agar avval tasodifan commit qilingan bo'lsa

E'tibor bering, git rm --cached faylni faqat keyingi commit'lardan olib tashlaydi, tarixda esa u saqlanib qoladi. Shuning uchun bir marta repozitoriyaga tushgan parollarni sizgan deb hisoblash kerak.

Fayl sizib chiqqan bo'lsa nima qilish kerak

Agar tekshiruvda .env ochiq ekani aniqlansa, uni yopishning o'zi yetarli emas, chunki fayl allaqachon kimdir tomonidan yuklab olingan bo'lishi mumkin. Quyidagi ishlarni shu tartibda bajaring:

1. Faylni yuqoridagi usullardan biri bilan darhol yoping va tekshiruvni takrorlang.
2. Ma'lumotlar bazasi parolini o'zgartiring va yangi parolni .env ga yozing.
3. To'lov tizimlari, SMS xizmati, pochta va bot tokenlari kabi barcha kalitlarni ularning kabinetida yangilang.
4. Laravel'dagi APP_KEY ni ham almashtirishni ko'rib chiqing, lekin bu shifrlangan ma'lumotlar va sessiyalarga ta'sir qilishini oldindan o'rganing.
5. Kirish jurnallaridan fayl qachon va qaysi IP'lardan so'ralganini aniqlang va baza jadvallarida begona foydalanuvchilar paydo bo'lmaganini tekshiring.

Misol: Buxorodagi mehmonxona sayti

Buxorodagi kichik mehmonxonaning bron qilish sayti Laravel'da yozilgan va hostingga butunligicha ko'chirilgan edi. Bir kuni administrator pochta orqali notanish manzillarga yuzlab xat ketganini payqadi: .env ochiq qolgan, undagi SMTP paroli bilan spam yuborilgan edi. Dasturchi sayt ildizini public papkasiga o'tkazdi, pochta va baza parollarini almashtirdi hamda .htaccess ga qo'shimcha taqiq qo'ydi. Shundan keyin u yangi loyihalarni ishga tushirishdan oldin har safar curl tekshiruvini bajarishni odat qildi.