هدر امنیتی و HSTS چیست؟ راهنمای فعال‌سازی امن
هدر امنیتی چیست و HSTS چه می‌کند؟ nosniff، Referrer-Policy، حذف هدرهای افشاگر و پله‌های max-age در HSTS را مرحله‌به‌مرحله و با احتیاط فعال کنید.
هدرهای امنیتی چند خط کوچک در پاسخ سرور هستند که به مرورگر می‌گویند با محتوای سایت شما چگونه رفتار کند. فعال کردنشان ساده به نظر می‌رسد، اما بعضی از آن‌ها، به‌خصوص HSTS، اگر بی‌دقت فعال شوند تا پایان مدتی که انتخاب کرده‌اید مشکل می‌سازند. در این راهنما هدرهایی را مرور می‌کنیم که nsin برای هر دامنه در پنل ارائه می‌دهد، می‌گوییم هر کدام چه می‌کند و ترتیب امن فعال‌سازی چیست. جزئیات از مستندات هدرهای امنیتی nsin و قوانین هدر گرفته شده است.
هدر امنیتی چیست و nsin چه هدرهایی اضافه می‌کند؟
هدر امنیتی یک هدر HTTP در پاسخ است که رفتار مرورگر را محدود یا مشخص می‌کند. nsin می‌تواند این هدرها را به ترافیک HTTPS پروکسی‌شده سایت شما اضافه کند. سه نکته مهم:
- به‌صورت پیش‌فرض خاموش‌اند و برای هر دامنه جداگانه تنظیم می‌شوند.
- فقط روی پاسخ‌های پروکسی‌شده و HTTPS اثر می‌گذارند؛ رکوردهای DNS-only (بدون پروکسی) و درخواست‌های
http://تغییر نمی‌کنند. - تغییرات ظرف چند ثانیه اعمال می‌شود و هر زمان می‌توانید خاموششان کنید؛ فقط اثر HSTS در مرورگرهایی که آن را دیده‌اند ماندگار است و پایین‌تر توضیح می‌دهیم.
مسیر تنظیم در پنل: دامنه را انتخاب کنید، به Security → Security Headers بروید و گزینه‌ها را روشن کنید. HSTS جداست و در Security → HSTS قرار دارد.
سه گزینه ساده و کاربردی
| گزینه | هدر | کار |
|---|---|---|
| No MIME sniffing | X-Content-Type-Options: nosniff | مرورگر به Content-Type دقیق سرور اعتماد می‌کند و حدس نمی‌زند؛ جلوی حمله‌های سوءاستفاده از تشخیص اشتباه نوع محتوا را می‌گیرد. |
| Referrer policy | Referrer-Policy: strict-origin-when-cross-origin | آدرس ارجاع‌دهنده‌ای که به سایت‌های دیگر فرستاده می‌شود به خود دامنه شما کوتاه می‌شود؛ با پیش‌فرض مرورگرهای امروزی هم‌خوان است. |
| Strip fingerprint headers | حذف X-Powered-By، X-AspNet-Version، X-AspNetMvc-Version، X-Generator، X-Drupal-Cache، X-Runtime | هدرهایی را برمی‌دارد که نوع و نسخه بک‌اند را لو می‌دهند. |
سرور شما همیشه اولویت دارد: اگر مبدأ خودش nosniff یا Referrer-Policy فرستاده باشد، nsin چیزی اضافه نمی‌کند. سه گزینه از هم مستقل‌اند.
کدام گزینه می‌تواند سایت را خراب کند؟
فقط No MIME sniffing. اگر سرور برای فایل‌های جاوااسکریپت یا CSS، Content-Type اشتباه (مثلاً text/plain) بفرستد، مرورگری که nosniff دریافت کرده آن‌ها را بارگذاری نمی‌کند و ظاهر سایت به هم می‌ریزد. پس اول مطمئن شوید نوع محتوا در مبدأ درست تنظیم شده و بعد آن را روشن کنید. طبق مستندات، دو گزینه دیگر برای عملاً همه سایت‌ها امن‌اند. توصیه مستندات این است که هدرها را یکی‌یکی روشن کنید و بعد از هر کدام سایت را در یک تب تازه بررسی کنید.
چیزی که nsin برای شما تعیین نمی‌کند
nsin سیاست Content-Security-Policy، CORS یا سیاست قاب‌گذاری (framing) را تعیین نمی‌کند، چون فقط اپلیکیشن شما می‌داند چه منابعی مجاز است. دو راه دارید: آن را روی سرور خودتان بفرستید تا nsin عبور دهد، یا با قانون هدر روی لبه بنویسید.
قانون هدر فهرستی مرتب از عملیات است و هر ردیف آن جهت (درخواست یا پاسخ)، عمل (Set، Add یا Remove) و نام هدر را مشخص می‌کند؛ برای Set و Add یک مقدار هم لازم است. چند نکته از مستندات:
- عملیات پاسخ بعد از کش اعمال می‌شود؛ پس بعد از تغییر لازم نیست کش را پاک کنید.
- در انواع دیگر قانون، اولین قانون منطبق برنده است، ولی در قوانین هدر همه قوانین منطبق اجرا می‌شوند؛ اگر دو قانون یک هدر را تنظیم کنند، قانون پایین‌تر فهرست برنده است.
- هر قانون حداکثر ۱۶ عملیات دارد و طول هر مقدار حداکثر ۴ کیلوبایت است.
- قوانین هدر روی پلن رایگان در دسترس نیستند؛ پلن‌ها را ببینید.
- می‌توان قانون را در حالت dry run ذخیره کرد تا فقط ثبت شود.
نمونه‌ای از مستندات برای کل سایت: عملیات پاسخ از نوع Set روی X-Frame-Options با مقدار SAMEORIGIN و روی Permissions-Policy با مقدار camera=(), microphone=().
HSTS چیست؟
HSTS همان هدر Strict-Transport-Security است که به مرورگر می‌گوید دامنه را فقط با HTTPS باز کند. مرورگری که یک بار این هدر را دیده باشد، تا پایان مدت max-age دیگر اصلاً درخواست HTTP ساده نمی‌فرستد. nsin برای هر رکورد پروکسی‌شده همیشه HTTP را روی لبه به HTTPS ریدایرکت می‌کند؛ HSTS نسخه قوی‌تر و سمت مرورگر همین کار است. درباره خود گواهی و HTTPS در راهنمای گواهی SSL رایگان هم نوشته‌ایم.
مستندات درباره HSTS هشدار جدی دارد: HSTS را نمی‌شود کاملاً برگرداند. مرورگری که هدر را دیده، تا پایان مدت انتخاب‌شده HTTP را رد می‌کند، حتی اگر بعداً HSTS را خاموش کنید؛ خاموش کردن فقط جلوی قفل شدن بازدیدکننده‌های جدید روی HTTPS را می‌گیرد. پس تنها زمانی فعالش کنید که همه چیز روی دامنه، از صفحه و تصویر و اسکریپت تا دانلود و مسیرهای API، با HTTPS کار کند.
پله‌های مدت (max-age)
پنل شش مدت پیشنهاد می‌دهد و در هر ذخیره فقط یک پله بالا می‌روید:
| پله | max-age | هزینه یک اشتباه |
|---|---|---|
| ۵ دقیقه | 300 | پنج دقیقه؛ شروع هر دامنه از اینجاست |
| ۱ ساعت | 3600 | یک ساعت |
| ۱ روز | 86400 | یک روز |
| ۱ هفته | 604800 | یک هفته |
| ۳۰ روز | 2592000 | یک ماه |
| ۱ سال | 31536000 | یک سال، و مقداری که فهرست preload می‌خواهد |
بین هر پله ترافیک واقعی بدهید و بعد بالا بروید. کاهش مدت همیشه مجاز است و اولین راه‌حل در صورت بروز مشکل است، ولی فقط برای بازدیدکننده‌های برگشتی کمک می‌کند.
includeSubDomains و preload
- Include subdomains: قانون را به همه زیر‌دامنه‌ها، حتی آینده و فراموش‌شده‌ها، تعمیم می‌دهد. هر زیر‌دامنه‌ای که HTTPS ندارد برای کسانی که هدر را دیده‌اند غیرقابل‌دسترس می‌شود؛ پیش از فعال‌سازی همه را بررسی کنید.
- Preload: پیش‌نیاز ثبت دامنه در فهرست preload است؛ فهرستی که داخل خود مرورگرها قرار دارد و باعث می‌شود حتی اولین درخواست بازدیدکننده هم با HTTPS باشد. شرط‌ها: HSTS روشن، شامل شدن زیر‌دامنه‌ها، مدت یک سال و تایپ کردن نام دامنه برای تأیید. تنظیم این گزینه فقط مرحله اول است و ثبت را باید خودتان در hstspreload.org انجام دهید. مستندات صریحاً می‌گوید preload عملاً دائمی است: خروج از فهرست یعنی درخواست حذف از hstspreload.org و ماه‌ها انتظار برای به‌روزرسانی مرورگرها.
نکته دیگر: وقتی HSTS در nsin روشن باشد، مقدار آن هدر Strict-Transport-Security خود مبدأ را جایگزین می‌کند، چون مرورگر فقط اولین هدر را می‌خواند و مبدأی که بی‌سروصدا یک سال بفرستد پله‌های شما را بی‌اثر می‌کند. اگر HSTS را در nsin خاموش نگه دارید، هدر خود مبدأ دست‌نخورده عبور می‌کند. چون HSTS را نمی‌شود کاملاً برگرداند، در قانون هدر هم نمی‌توانید این هدر را تغییر دهید و باید از مسیر Security → HSTS و با همان پله‌ها بروید.
حداقل نسخه TLS
در بخش SSL/TLS می‌توانید قدیمی‌ترین نسخه TLS مجاز را تعیین کنید:
- TLS 1.2 (پیش‌فرض): TLS 1.2 و 1.3 را می‌پذیرد.
- فقط TLS 1.3: گوشی‌های اندرویدی قدیمی، ویندوز ۷، بعضی پروکسی‌های سازمانی و کلاینت‌های API قدیمی اصلاً نمی‌توانند وصل شوند.
هیچ نسخه‌ای زیر TLS 1.2 در هیچ دامنه‌ای پذیرفته نمی‌شود. کلاینتی که زیر حداقل تعیین‌شده باشد هنگام اتصال خطا می‌گیرد و صفحه توضیحی نمی‌بیند. پیش از اجباری کردن TLS 1.3، سهم واقعی TLS 1.2 را در نمودار TLS صفحه SSL/TLS ببینید. برخلاف HSTS، این تنظیم ظرف چند ثانیه اعمال می‌شود و به همان سرعت هم قابل برگرداندن است.
ترتیب پیشنهادی فعال‌سازی
- مطمئن شوید سایت روی CDN فعال و HTTPS برقرار است.
Referrer-Policyو حذف هدرهای افشاگر را روشن کنید.- نوع محتوای فایل‌های مبدأ را بررسی کنید، سپس
nosniffرا روشن کنید و در تب تازه امتحان کنید. - CSP و بقیه سیاست‌ها را در اپلیکیشن یا با قانون هدر بنویسید.
- HSTS را با ۵ دقیقه شروع کنید و پله‌پله بالا بروید.
- فقط بعد از اطمینان کامل، به فکر یک سال، includeSubDomains و preload باشید.
برای نگاه گسترده‌تر به لایه‌های محافظتی، WAF و محافظت در برابر DDoS را هم ببینید.
پرسش‌های متداول
HSTS چیست و چه فرقی با ریدایرکت HTTP به HTTPS دارد؟
ریدایرکت بعد از ارسال درخواست HTTP اتفاق می‌افتد؛ ولی مرورگری که HSTS را دیده باشد دیگر اصلاً درخواست HTTP نمی‌فرستد (با preload حتی از اولین درخواست). nsin ریدایرکت را همیشه انجام می‌دهد و HSTS لایه اضافه و اختیاری است.
اگر HSTS را خاموش کنم مشکل حل می‌شود؟
فقط برای بازدیدکننده‌های جدید. مرورگرهایی که هدر را دیده‌اند تا پایان مدت قبلی HTTP را رد می‌کنند. برای همین باید با ۵ دقیقه شروع کنید.
آیا nsin هدر CSP هم اضافه می‌کند؟
خیر. CSP را خودتان روی مبدأ می‌فرستید یا با قانون هدر روی لبه می‌نویسید.
هدرهای امنیتی روی رکوردهای DNS-only هم اثر دارند؟
خیر، فقط روی پاسخ‌های پروکسی‌شده HTTPS اعمال می‌شوند.
هدرها را برای دامنه خودتان در پنل nsin و بخش Security تنظیم کنید و با ۵ دقیقه HSTS شروع کنید.