قوانین هدر
قانون هدر هدرهای HTTP را روی لبه ویرایش میکند: روی درخواست، پیش از آنکه nsin آن را به سرور شما بفرستد؛ روی پاسخ، پیش از آنکه به بازدیدکننده برسد؛ یا هر دو، از یک قانون واحد. لازم نیست چیزی روی سرور شما تغییر کند.
وقتی سراغش بروید که هدری را میخواهید که اپلیکیشن شما نمیفرستد — یک
Content-Security-Policy، یک X-Frame-Options، یا رمزی مشترک که ثابت کند
درخواست از nsin آمده است — یا وقتی میخواهید هدری که اپلیکیشن شما میفرستد پیش
از دیدهشدن حذف شود.
دو جهت
Section titled “دو جهت”| کِی اعمال میشود | سرور شما میبیند | بازدیدکننده میبیند | |
|---|---|---|---|
| درخواست | پیش از تماس nsin با سرور شما | بله | خیر |
| پاسخ | پیش از خروج پاسخ از لبه | خیر | بله |
یک قانون میتواند عملیاتی در هر دو جهت داشته باشد.
ویرایش پاسخ بعد از کش انجام میشود، نه قبل از ذخیرهشدن. یعنی صفحهای که از کش میآید هم هدرهایی را میگیرد که قانون شما امروز میگوید، و هر تغییری در قانون از همان درخواست بعدی دیده میشود — برای عوضکردن یک هدر پاسخ هرگز لازم نیست کش را پاک کنید.
عملیاتها
Section titled “عملیاتها”هر قانون یک فهرست مرتب از عملیات است. هر عملیات یک جهت، یک کنش، یک نام هدر و (برای دو کنش اول) یک مقدار دارد.
| کنش | چه میکند |
|---|---|
| Set | هرچه هست را با مقدار شما جایگزین میکند. وقتی دقیقاً یک مقدار میخواهید. |
| Add | مقدار شما را اضافه میکند و آنچه کلاینت یا سرور شما فرستاده باقی میماند. |
| Remove | هدر را کاملاً حذف میکند. مقدار نمیگیرد. |
عملیاتها به همان ترتیبی که نوشتهاید اجرا میشوند، پس روی یک نام هدر، عملیات بعدی برندهی قبلی است.
حذف یک گروه هدر با هم
Section titled “حذف یک گروه هدر با هم”عملیات remove میتواند به * ختم شود: X-Debug-* هر هدری را که با
X-Debug- شروع شود حذف میکند. این تنها جایی است که وایلدکارت مجاز است —
set و add به یک نام دقیق نیاز دارند تا روی آن بنویسند.
فهرست هدرهای رزروشدهی پایین برای هر نامی که وایلدکارت واقعاً به آن بخورد دوباره بررسی میشود، پس یک الگوی گسترده هرگز نمیتواند هدری را که nsin مالک آن است حذف کند.
قوانین هدر با هم جمع میشوند
Section titled “قوانین هدر با هم جمع میشوند”این تنها نوع قانونی است که همهی قوانین منطبق اجرا میشوند. در بقیهی nsin اولین قانون منطبق برنده است و بقیه نادیده گرفته میشوند.
برای هدرها این رفتار درستتر است: یک قانون سراسری «هدرهای امنیتی من» بهعلاوهی یک
قانون کوچک که روی /admin یک هدر دیگر اضافه میکند، حالت معمول است؛ و اگر فقط
اولین قانون اجرا میشد، مجبور بودید مجموعهی سراسری را در هر قانون مسیری تکرار
کنید.
وقتی دو قانون یک نام هدر را مینویسند، قانون پایینتر برنده است — چون آخر اجرا میشود. با جابهجا کردن فهرست، ترتیب را عوض کنید.
دامنهی اثر
Section titled “دامنهی اثر”مثل هر قانون، قانون هدر را میتوان با رکوردها، نام میزبان و مسیر محدود کرد — به مرور قوانین ببینید.
دو محدودیت مخصوص همین نوع است:
- محدودکردن بر اساس آیپی بازدیدکننده فقط برای قوانینی که تنها عملیات پاسخ دارند ممکن است. یک هدر درخواست، آنچه nsin از سرور شما میگیرد را عوض میکند بدون اینکه کلید کش عوض شود؛ پس نسخهای که برای آیپی یک بازدیدکننده گرفته شده به بقیه هم داده میشود. ویرایش پاسخ برای هر درخواست و بعد از کش انجام میشود و محدودیت آیپی را کامل نگه میدارد.
- رکوردهای Gateway مشمول نیستند. یک نام میزبان Gateway جلوی سرویسهای بالادستِ مشتریان زیادی میایستد، پس قانونی که آنجا یک هدر اعتبارنامهای بزند به ترافیک دیگران هم میرسد.
حالت آزمایشی
Section titled “حالت آزمایشی”قانون هدر را میتوان در حالت آزمایشی ذخیره کرد. قانون همچنان تطبیق مییابد و ثبت میشود، اما درخواست و پاسخ هر دو دستنخورده عبور میکنند. از آن استفاده کنید تا پیش از هر تغییری مطمئن شوید یک قانون گسترده همان چیزی را میگیرد که در نظر داشتید.
سقفها
Section titled “سقفها”| محدودیت | مقدار |
|---|---|
| تعداد عملیات در هر قانون | ۱۶ |
| طول یک مقدار | ۴ کیلوبایت |
| مجموع افزوده در هر قانون | ۸ کیلوبایت (نام + مقدارِ همهی set/add) |
۴ کیلوبایت جا برای یک Content-Security-Policy واقعی میدهد و در عین حال زیر سقف
۸ کیلوبایتی میماند که nginx و Apache بهصورت پیشفرض برای هر هدر میگذارند. هر سه
سقف هنگام ذخیره بررسی میشوند تا یک قانون بزرگتر از حد با پیامی روشن رد شود، نه
اینکه بعداً به 431 از سمت سرور خودتان تبدیل شود.
قوانین هدر با هم ترکیب میشوند — هر قانونی که مطابقت داشته باشد اعمال میشود، نه
فقط اولی — بنابراین مجموعی که یک درخواست واقعاً حمل میکند، جمعِ همهی قوانین مطابق
است. لبه این مجموعِ ترکیبشده را هم روی ۸ کیلوبایت در هر جهت محدود میکند و عملیاتی
را که از آن فراتر برود کنار میگذارد، تا انباشتی از قوانین هم نتواند به 431 تبدیل
شود. حذفها هرگز در این سقف حساب نمیشوند و هرگز کنار گذاشته نمیشوند.
هدرهایی که نمیتوانید تغییر دهید، و چرا
Section titled “هدرهایی که نمیتوانید تغییر دهید، و چرا”nsin مجموعهی کوچکی از نامها را رد میکند — نه برای سختگیری، بلکه چون خودِ لبه همان چیزی است که آنها را محاسبه میکند و یک مقدار دستی یا نادیده گرفته میشود یا بیسروصدا چیزی را خراب میکند. بررسی هم بر اساس جهت است و هم بر اساس کنش، پس یک نام میتواند برای یک کنش رد و برای کنش دیگری مجاز باشد.
هر رد شدن، یک 400 است که نام هدر و دلیل را میگوید.
روی درخواست:
| هدر | چرا |
|---|---|
Host | روی لبه یک هدر معمولی نیست — نام TLS و خانهی کش را هم تعیین میکند. آن را روی رکورد، یا روی قانون مسیر/استخر مبدأ تغییر دهید، جایی که مقدارش با زون شما اعتبارسنجی میشود. |
Content-Length | از روی بایتهایی که واقعاً منتقل میشوند دوباره محاسبه میشود و بهعنوان نشانهای برای بافرشدن بدنه خوانده میشود. مقدار اشتباه میتواند صفحهای ناقص را در کش بگذارد. |
Transfer-Encoding، Connection، Upgrade، Keep-Alive، Proxy-Connection، TE، Trailer | اینها گامبهگاماند: ارتباط میان بازدیدکننده و لبه را توصیف میکنند و در هر حال جلوتر نمیروند. |
X-Forwarded-For، X-Forwarded-Proto، X-Forwarded-Host، X-Forwarded-Port، X-Real-IP، True-Client-IP، Forwarded | nsin اینها را از همان اتصالی پر میکند که واقعاً پذیرفته است. مقدار ثابت یعنی دادن یک نشانی جعلی از بازدیدکننده به سرور شما. |
CDN-Loop | شمارندهی حلقه که CDNهای دیگر میخوانند. فرستادن نشانهی یک CDN دیگر به مبدأیی که پشت CDN است، راهی اثباتشده برای گرفتن 502 است. |
Cache-Control، If-None-Match، If-Modified-Since، If-Match، If-Range، Range، Accept-Encoding | لبه این مجموعه را در هر مسیر واکشی به شکل متفاوتی بازنویسی میکند، پس یک قانون سه رفتار مختلف پیدا میکرد. |
Sec-WebSocket-* | ساختن کلید دستدادن با قانون، تشخیص تونلی را که همان کلید را میخواند بیاثر میکند. |
Nsn-*، X-Nsin-*، X-Mafar-* | فضاینام خود nsin. مبدأها به اینها اعتماد میکنند، پس قانونی که بتواند یکی را بنویسد یعنی جعل. |
روی پاسخ:
| هدر | چرا |
|---|---|
Content-Length | از روی بایتهایی که واقعاً نوشته میشوند دوباره محاسبه میشود. |
Transfer-Encoding، Connection، Upgrade، Keep-Alive | باز هم گامبهگام. |
Content-Encoding | متعلق به فشردهساز لبه است. آنچه ذخیره میشود همیشه بدون فشردهسازی است و مقدار ذخیرهشده هرگز دوباره پخش نمیشود. |
Vary | کش روی آن کلید نمیخورد، پس اعلام تنوعی که nsin رعایتش نمیکند یعنی دادن صفحهی یک بازدیدکننده به دیگری. |
Server | عمداً آخر از همه زده میشود، بهعنوان آخرین تغییر پیش از خروج پاسخ. |
Strict-Transport-Security | HSTS بعد از اینکه مرورگر آن را دید پسگرفتنی نیست، پس متعلق به نردبان صفحهی امنیت ← HSTS است که مدت را در هر ذخیره یک پله بالا میبرد. به هدرهای امنیتی ببینید. |
Nsn-* | سطح آنالیتیکس و عیبیابی خود nsin. |
استثنا: حذفشان مجاز است
Section titled “استثنا: حذفشان مجاز است”سه هدر درخواست برای set و add رد میشوند اما برای remove مجازند:
Cookie، Authorization و Nsn-Connecting-IP.
دلیل مسدودبودنشان این است که nsin پیش از تازهکردن یک صفحهی کششده اعتبارنامهها را حذف میکند، و قانونی که یکی از آنها را بعدش برگرداند، صفحهی شخصیشدهی یک نفر را در خانهای میگذارد که همه از آن میخوانند. یک remove چنین کاری نمیتواند بکند — فقط میتواند با همان حذف همداستان شود.
و حذف واقعاً به کار میآید: انداختن Cookie پیش از رسیدن درخواست به سرور شما،
همان راهی است که صفحهای را کشپذیر میکند که وگرنه نبود؛ و انداختن
Nsn-Connecting-IP پیش از یک مبدأ شخص ثالث، نشانی بازدیدکنندگان شما را پیش خودتان
نگه میدارد.
هدرهایی که nsin برای شما مدیریت میکند
Section titled “هدرهایی که nsin برای شما مدیریت میکند”بعضی هدرها بهجای جعبهی متن، یک کلید هستند، چون اشتباهکردنشان گران تمام میشود:
X-Content-Type-Options،Referrer-Policyو حذف هدرهای افشاگر، کلیدهای هر دامنهاند — به هدرهای امنیتی ببینید.Strict-Transport-Securityو کمینهی نسخهی TLS به همین دلیل در امنیت ← HSTS هستند.- هدرهایی که nsin همیشه به ترافیک پراکسیشده اضافه میکند، مثل
Nsn-Connecting-IP، در هدرهای پراکسی فهرست شدهاند.
قوانین هدر برای هدرهای شماست. آن صفحهها برای هدرهای nsin.
چیزهایی که قانون هدر به آنها نمیرسد
Section titled “چیزهایی که قانون هدر به آنها نمیرسد”- قوانین خودتان. قوانین هدر آخر از همه اجرا میشوند، بعد از WAF، تشخیص ربات، اثر انگشت و بازنویسی. هدر درخواستی که اضافه میکنید برای هیچکدام از آنها دیده نمیشود — عمداً، تا نشود با یک قانون از محافظت خودتان رد شد یا آن را بیجهت بهصدا درآورد.
- ارتقای WebSocket. دستدادن
101از نقطهای که هدرهای پاسخ اعمال میشوند عبور نمیکند، پس عملیات پاسخ روی آن اثری ندارد. عملیات درخواست اثر دارد. - صفحههای خود nsin. صفحههای خطا، صفحههای چالش، پنجرهی احراز هویت پایه و پاسخهای مسدودسازی از لبه میآیند، نه از سرور شما، و قوانین شما به آنها دست نمیزنند.
نمونهها
Section titled “نمونهها”هدرهای امنیتی برای کل سایت
- پاسخ · set ·
X-Frame-Options·SAMEORIGIN- پاسخ · set ·
X-XSS-Protection·0- پاسخ · set ·
Permissions-Policy·camera=(), microphone=()
اثبات اینکه ترافیک از nsin آمده
- درخواست · set ·
X-Edge-Secret·یک-رشتهی-تصادفی-بلندبعد سرورتان را طوری تنظیم کنید که هرچه این هدر را ندارد رد کند — همان ایدهای که در هدرهای پراکسی هست: فقط به ترافیکی اعتماد کنید که واقعاً از لبه آمده.
کشپذیر کردن یک صفحهی تبلیغاتی
- مسیر:
/landing/*- درخواست · remove ·
Cookieسرور شما دیگر برای آن صفحهها نشستی نمیبیند، پس شخصیسازیشان نمیکند، پس میشود برای همه کششان کرد.
افشا نکردن فریمورک
- پاسخ · remove ·
X-Powered-By- پاسخ · remove ·
X-AspNet-*
سوالهای رایج
Section titled “سوالهای رایج”یک هدر پاسخ اضافه کردم اما نمیبینمش. اول ببینید رکورد پراکسیشده است — قوانین فقط روی ترافیکی اجرا میشوند که از nsin عبور میکند. اگر هست، بررسی کنید قانون در حالت آزمایشی نباشد، و یادتان باشد صفحههای خطا و چالش از nsin میآیند نه از سرور شما.
بعد از تغییر یک هدر پاسخ باید کش را پاک کنم؟ نه. هدرهای پاسخ بعد از کش اعمال میشوند، پس تغییر از همان درخواست بعدی زنده است.
دو قانون یک هدر را ست میکنند. کدام برنده است؟ آنکه پایینتر است — چون آخر اجرا میشود. به مرور قوانین ببینید.
میتوانم کشور بازدیدکننده یا شناسهی درخواست را بهعنوان مقدار بگذارم؟ فعلاً نه. مقدارها امروز متن ثابتاند.
قانون هدر میتواند جای تنظیمات CORS یا CSP روی مبدأ را بگیرد؟ میتواند آن هدرها را اضافه یا جایگزین کند، و برای یک سایت ایستا معمولاً همین سادهترین راه است. اما اگر اپلیکیشن شما آنها را برای هر پاسخ جداگانه میسازد، کار را به اپلیکیشن بسپارید — یک قانون لبه همهی پاسخها را به یک مقدار واحد صاف میکند.