اگر این ۳ تنظیم ساده را انجام ندهید، سایت شما هدف آسان هکرهاست!

بیش از نیمی از یک میلیون سایت پرترافیک دنیا، حتی ابتدایی‌ترین هدرهای امنیتی را ندارند. این عدد نشان می‌دهد مشکل، پیچیدگی فنی نیست؛ بی‌توجهی است.

در واقع، تنظیمات امنیتی ساده سایت معمولاً چند دقیقه بیشتر زمان نمی‌برند. با این‌حال، همین چند دقیقه، فاصله بین یک سایت آسیب‌پذیر و یک سایت با دفاع پایه واقعی را می‌سازد.

چرا با وجود سادگی، این تنظیمات اجرا نمی‌شوند؟

دلیل اصلی، پیچیدگی فنی نیست. در واقع، این تنظیمات معمولاً چون «فوری» به‌نظر نمی‌رسند، در صف کارهای عقب‌افتاده باقی می‌مانند. بنابراین، تیم توسعه روی قابلیت‌های جدید تمرکز می‌کند و تنظیمات امنیتی ساده سایت، ساکت و بدون فشار مستقیم، فراموش می‌شوند.

چرا اندازه کوچک تنظیم، به‌معنی اثر کوچک نیست؟

هر سه تنظیم این مقاله، مستقیماً جلوی یک روش شناخته‌شده حمله را می‌گیرند. هدرهای امنیتی جلوی Clickjacking و اجرای اسکریپت ناخواسته را می‌گیرند؛ فلگ‌های کوکی جلوی سرقت نشست را می‌گیرند؛ و غیرفعال‌سازی Directory Listing جلوی جمع‌آوری اطلاعات سیستمی توسط مهاجم را می‌گیرد. هیچ‌کدام «تزئینی» نیستند.

پیش از رفتن سراغ پیاده‌سازی، تفاوت عملی وجود و نبود این تنظیمات را باید دید. راهنمای هدرهای HTTP سازمان OWASP این تفاوت را برای هر هدر، به‌طور مجزا و در واقع با جزئیات کامل، مستند کرده است.

در واقع، راهکار پیشنهادی، اعمال هر سه تنظیم امنیتی ساده سایت در یک نشست کاری واحد است، نه پخش‌کردن آن‌ها در چند هفته آینده.

در واقع، تیم سنتیوا در پروژه‌های تقویت تنظیمات امنیتی ساده سایت این مراحل را عملی می‌کند:

• اسکن اولیه سایت برای مشخص‌کردن دقیق کدام هدرها و فلگ‌ها از قبل فعال‌اند و کدام‌ها نیستند
• پیاده‌سازی هر سه تنظیم روی محیط تست، پیش از اعمال روی سرور اصلی
• هماهنگ‌سازی تنظیمات بین لایه‌های مختلف (پراکسی، سرور وب، اپلیکیشن) در معماری‌های چندلایه
• ارائه گزارش نهایی با نتیجه تست هدرها و کوکی‌ها بعد از اعمال تغییرات

سناریوی این راهنما: یک سایت شرکتی فرضی به آدرس company-example.ir در نظر می‌گیریم. این سایت پشت Nginx به‌عنوان reverse proxy و یک بک‌اند PHP-FPM اجرا می‌شود؛ دستورات معادل Apache هم برای تیم‌هایی که از آن استفاده می‌کنند آمده است. دقیقاً همین نام دامنه در تمام مراحل زیر تکرار می‌شود.

تنظیم ۱: هدرهای امنیتی HTTP

server { server_name company-example.ir; add_header X-Frame-Options "DENY" always; add_header X-Content-Type-Options "nosniff" always; add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always; }

در واقع، این پنج هدر، سه دسته حمله را هدف می‌گیرند. X-Frame-Options جلوی Clickjacking را می‌گیرد؛ X-Content-Type-Options جلوی اجرای فایل به‌عنوان نوع اشتباه (MIME-sniffing) را می‌گیرد؛ و Strict-Transport-Security مرورگر را مجبور می‌کند همیشه از HTTPS استفاده کند.

<IfModule mod_headers.c> Header always set X-Frame-Options "DENY" Header always set X-Content-Type-Options "nosniff" Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains" Header always set Referrer-Policy "strict-origin-when-cross-origin" </IfModule>

اگر سایت روی Apache اجرا می‌شود، فقط کافی است ماژول mod_headers فعال باشد. به همین دلیل، بعد از هر دو تغییر، سرویس مربوطه باید Reload شود تا هدرها روی درخواست‌های جدید اعمال شوند.

تنظیم ۲: فلگ‌های امن کوکی

session.cookie_secure = 1 session.cookie_httponly = 1 session.cookie_samesite = "Strict"

این سه فلگ با هم کار می‌کنند. Secure کوکی را فقط روی HTTPS ارسال می‌کند؛ HttpOnly دسترسی جاوااسکریپت به کوکی را می‌بندد؛ و SameSite از ارسال ناخواسته کوکی در درخواست‌های بین‌سایتی جلوگیری می‌کند. طبق راهنمای مدیریت نشست OWASP، ترکیب هر سه، دفاع لایه‌ای واقعی در برابر سرقت نشست می‌سازد.

location / { proxy_pass http://127.0.0.1:9000; proxy_cookie_flags ~ secure httponly samesite=strict; }

با این‌حال، وقتی تغییر مستقیم کد اپلیکیشن قدیمی امکان‌پذیر نیست، همین یک خط در Nginx می‌تواند فلگ‌های امن را به هر کوکی عبوری از پراکسی اضافه کند.

تنظیم ۳: غیرفعال‌سازی Directory Listing و مخفی‌کردن نسخه سرور

server { server_name company-example.ir; autoindex off; server_tokens off; }

در واقع، autoindex off جلوی نمایش لیست فایل‌های یک پوشه بدون index را می‌گیرد. همچنین، server_tokens off نسخه دقیق Nginx را از هدر پاسخ حذف می‌کند تا مهاجم نتواند مستقیم دنبال آسیب‌پذیری‌های شناخته‌شده همان نسخه بگردد.

<Directory /var/www/company-example.ir> Options -Indexes </Directory> ServerTokens Prod ServerSignature Off

در نهایت، بعد از اعمال هر سه تنظیم، دوباره با curl -I هدرهای پاسخ را چک کنید و مطمئن شوید هیچ پوشه‌ای بدون فایل index، لیست فایل‌ها را نشان نمی‌دهد.

یک نمونه معمول: سایت شرکتی با پنل مدیریت

«تا قبل از این بررسی، اصلاً نمی‌دانستیم لیست کامل فایل‌های پوشه آپلود، برای هر بازدیدکننده‌ای قابل مشاهده است. یک تنظیم دو‌خطی این مشکل را برای همیشه حل کرد.»

در واقع، این تجربه در بین سایت‌های کوچک و متوسط با تیم فنی محدود بسیار رایج است. به همین دلیل، جمع‌بندی نتیجه معمول این مسیر ارزش توجه دارد:

• شناسایی حداقل یک پوشه با Directory Listing فعال که تا آن لحظه کسی متوجه‌اش نشده بود
• فعال‌سازی کامل هر سه تنظیم در یک نشست کاری، بدون نیاز به توقف سرویس
• کاهش محسوس سطح اطلاعاتی که مهاجم می‌تواند بدون تلاش زیاد از سایت جمع‌آوری کند

فوری (همین امروز)

• افزودن پنج هدر امنیتی اصلی به پیکربندی Nginx یا Apache
• غیرفعال‌سازی Directory Listing و مخفی‌کردن نسخه سرور

کوتاه‌مدت (این هفته)

• تنظیم فلگ‌های Secure، HttpOnly و SameSite روی کوکی‌های نشست
• تست کامل با curl -I و بررسی رفتار فرم‌های ورود بعد از فعال‌سازی SameSite

بلندمدت (مستمر)

• افزودن این سه تنظیم به چک‌لیست راه‌اندازی هر سرور یا سرویس جدید
• بازبینی دوره‌ای هدرها بعد از هر تغییر معماری (مثل افزودن CDN یا پراکسی جدید)

سوالات متداول تخصصی

• تنظیمات امنیتی ساده سایت شامل سه مورد است: هدرهای امنیتی HTTP، فلگ‌های امن کوکی، و غیرفعال‌سازی Directory Listing.
• هر سه در کمتر از ۱۰ دقیقه، بدون تغییر کد اصلی اپلیکیشن، قابل اجرا هستند.
• هرکدام مستقیماً جلوی یک دسته حمله شناخته‌شده را می‌گیرد: Clickjacking، سرقت نشست، و جمع‌آوری اطلاعات سیستمی.
• بهترین روش، اعمال هر سه هم‌زمان روی محیط تست و سپس انتقال به سرور اصلی است.
• بی‌توجهی به این تنظیمات، دلیل فنی ندارد؛ فقط یک اولویت فراموش‌شده است.

تنظیمات امنیتی ساده سایت، کم‌هزینه‌ترین سرمایه‌گذاری امنیتی است که همین امروز می‌توانید انجام دهید.