HTTP header و باورنکردنی ترین حقایقی که اغلب نادیده گرفته می‌شوند - XNET | اخبار مقالات امنیت سایبری

در این مطلب از به بررسیHTTP headerچیست وانواع HTTP headerو هر آن چیزی که باید در مورد آن بدانید از پیکربندی نادرست و منطق کسب‌وکاری نامناسب چگونه می‌تواند باعث قرارگرفتن وب‌سایت‌ها در معرض حملات مخرب از طریق HTTP Host Header شود. همچنین روشی را نیز برای تشخیص آسیب‌پذیری‌های HTTP header معرفی خواهیم کرد. در نهایت هم توصیه‌هایی را برای محافظت از وب‌سایت‌ها در برابر چنین حملاتی بیان می‌کنیم.

HTTP Host headerچیست؟

Headerها ارتباط بین سرورها و کلاینت‌ها را در پروتکل HTTP کنترل می‌کنند. در واقع زمانی که درخواستی از یک کلاینت به سرور ارسال می‌شود Headerها دربرگیرنده اطلاعاتی هستند که میان سرور و کلاینت ارسال می‌شود.

HTTP header یکی از درخواست‌های الزامی برای برقراری ارتباط کلاینت با سرور است. HTTP header، نام دامنه‌ای که کلاینت قصد دسترسی به آن را دارد مشخص می‌کند. برای مثال وقتی کاربری از سایتhttps://portswigger.net/web-securityبازدید می‌کند، مرورگر وی درخواستی حاوی HTTP header را به‌صورت زیر ایجاد می‌کند

GET/ web-security HTTP/1.1
Host: XNET.com

البته این احتمال وجود دارد زمانی که درخواستی توسط یک سیستم واسطه (که توسط هکری کنترل می‌شود) دوباره ارسال شود، مقدار و ارزش Host پیش از رسیدن به Back End تغییر کند.

کاربردHTTP Hostچیست؟

کاربرد HTTP Host تشخیص بخشی از Back End است که کلاینت قصد برقراری ارتباط با آن را دارد. اگر درخواست‌ها حاوی HTTP header نبوده یا HTTP header نوشته شده در درخواست درست نباشد، ممکن است در مسیریابی درخواست‌های ورودی به سمت سامانه‌های موردنظر مشکل ایجاد شود.

ازآنجاکه در گذشته هر آدرس IP فقط شامل محتوای Host یک دامنه بود، این ابهامات وجود نداشت. امروزه به دلیل گسترش میزان استفاده از راهکارهای مبتنی بر ابر و برون‌سپاری معماری‌های مرتبط، امکان دسترسی به چندین وب‌سایت و سامانه نرم‌افزاری از طریق یک آدرس IP وجود دارد. همچنین یکی دیگر از دلایل افزایش محبوبیت چنین روشی این است که آدرس‌های IP ورژن 4 دیگر روبه‌اتمام هستند.

زمانی که چند سامانه از طریق یک آدرسIPقابل‌دسترس باشند، یکی از شرایط زیر رخ خواهد داد

میزبانی مجازی

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

درهرصورت، اگر چه هر یک از این وب‌سایت‌های مجزا نام دامنه متفاوتی دارند؛ ولی باز هم همه آن‌ها از یک آدرس IP مشترک استفاده می‌کنند. وب‌سایت‌هایی که با این روش و توسط یک سرور میزبانی می‌شوند، با عنوان «میزبان‌های مجازی» شناخته می‌شوند. معمولاً برای یک کاربر عادی که به چنین وب‌سایت‌هایی دسترسی دارد، میزبان مجازی آن از وب‌سایتی که در سرور اختصاصی شرکت میزبانی می‌شود، تفاوتی ندارد.

مسیریابی ترافیک باواسطه

یکی دیگر از روش‌های رایج، زمانی است که وب‌سایت‌ها توسط سرورهای Back End متمایز میزبانی می‌شوند؛ اما تمام ترافیک بین کلاینت‌ها و سرورها از طریق یک سیستم واسط مسیریابی می‌شود. این سرور واسط ممکن است یک تعدیل‌کننده بار به‌منظور مدیریت درخواست‌های ارسالی به سرورها بوده یا یک سرور پروکسی معکوس خاص که درخواست‌ها را کنترل و مدیریت می‌کند، باشد. این نوع تنظیمات در شرایطی که کلاینت‌ها از طریق یک شبکه تحویل محتوا (CDN) به وب‌سایت دسترسی پیدا می‌کنند بیشتر رایج است.

در این حالت هر چند وب‌سایت‌ها بر روی سرورهای مجزا میزبانی می‌شوند؛ ولی نام دامنه همه آنها به IP سرور سیستم واسط تبدیل می‌شود. همچنین ازآنجاکه سرور پروکسی معکوس یا تعدیل‌کننده بار باید قادر به تشخیص Back End مناسب برای هدایت درخواست به سمت آن باشد، بنابراین چالش‌های این روش با روش میزبانی مجازی تقریباً یکسان است.

تقسیم بندی HTTP header بر اساس محتوا

هدرهای درخواست (Request HTTP header) و هدرهای پاسخ (Response HTTP header) نقش مهمی در ارتباط بین کلاینت و سرور دارند. در واقع، هر درخواستی که از سمت کلاینت به سمت سرور ارسال می‌شود و همچنین هر پاسخی که از سمت سرور به سمت کلاینت ارسال می‌شود، شامل یک بسته اطلاعاتی می‌شوند. این بسته‌ها شامل بدنه اصلی (Entity Body) و همچنین اطلاعات اضافی از جمله هدرهای HTTP است.

نحوه ارسال درخواست از سمت کلاینت (مانند مرورگر وب) به سمت سرور به این صورت است که ابتدا یک درخواست کلی به URL مقصد ارسال می‌شود. پس از ارسال این درخواست، کلاینت منتظر پاسخ کلی از سرور می‌ماند که شامل محتوای اصلی است. سپس، برای هر منبع (مانند تصاویر، فایل‌های CSS، و اسکریپت‌ها)، یک درخواست جداگانه ایجاد می‌شود و این درخواست‌ها همگی با مشخصه اتصال keep-alive ارسال می‌شوند.

هدرهای درخواست HTTP (HTTP Request Headers)

HTTP header به هنگام ارسال درخواست به سرور از سمت درخواست‌کننده (کلاینت) ارسال می‌شوند. این HTTP header به سرور اطلاعات مهمی را ارائه می‌دهد تا سرور بتواند به درخواست به‌درستی پاسخ دهد.برخی از هدرهای رایج در این دسته عبارت‌اند از

Acceptنوع‌های ممکن محتوای درخواستی که کلاینت قبول می‌کند را مشخص می‌کند.

Hostنام دامنه سرور مقصد که به آن درخواست ارسال می‌شود.

Accept-Languageزبان موردنظر کلاینت برای درخواست.

User-Agentاطلاعات مربوط به دستگاه و مرورگر درخواست‌کننده.

Refererمشخص می‌کند از کجا به این صفحه آمده‌اید. به‌عنوان‌مثال، اگر شما از صفحه اصلی به یک صفحه دیگر رفته‌اید، این هدر نشان می‌دهد که از کجا آمده‌اید.

Cookieلیست کوکی‌های موجود در مرورگر که باید به سرور ارسال شوند.

Authorizationبرای اعتبارسنجی درخواست با اطلاعات ورودی کاربر. نوع اصلی این هدر Basic است که اطلاعات ورودی به‌صورت رمزنگاری شده (base64) ارسال می‌شوند.

هدرهای عمومی HTTP (HTTP General Headers)

این هدرها هم در درخواست و هم در پاسخ وجود دارند و اطلاعاتی کلی در مورد درخواست یا پاسخ ارائه می‌دهند. برخی از هدرهای معروف در این دسته شامل

Cache-Controlمشخص می‌کند آیا محتوا قابل کش شدن (caching) است یا خیر، و در صورت کش شدن، مدت‌زمان زنده آن را مشخص می‌کند.

Connectionوضعیت ارتباط، که می‌تواند مقدار close یا keep-alive داشته باشد. این مقدار تعیین می‌کند که ارتباط باید بعد از اتمام درخواست بسته شود یا باز بماند.

Dateزمان ارسال درخواست یا دریافت پاسخ.

Content-Typeنوع محتوای Entity Body که در پاسخ وجود دارد. این هدر هم در درخواست و هم در پاسخ ارسال می‌شود و به مشتری (کلاینت) اطلاع می‌دهد که محتوای پیام با چه فرمتی ارسال می‌شود.

هدرهای پاسخ HTTP (HTTP Response Headers)

این هدرها توسط سرور ارسال می‌شوند و اطلاعات مربوط به پاسخ به کلاینت را ارائه می‌دهند. برخی از هدرهای معروف در این دسته عبارت‌اند از

Serverاطلاعاتی در مورد نوع سروری که پاسخ را ایجاد کرده است.

Set-Cookieکوکی‌هایی که باید در مرورگر کاربر ذخیره شوند.

Locationآدرس URL مقصد که کاربر باید به آن منتقل شود. معمولاً برای انتقال کاربر به مکان دیگر پس از انجام پردازش استفاده می‌شود.

Content-Lengthطول محتوای Entity Body مربوط به پاسخ.

WWW-Authenticateنوع الگوریتم اعتبارسنجی را مشخص می‌کند که می‌تواند مقادیری مانند “Basic” و “Bearer” باشد. این هدر برای اعتبارسنجی اطلاعات کاربری استفاده می‌شود.

هدرهای مربوط به محتوا (Entity Headers)این نوع هدرها حاوی اطلاعاتی در مورد متن منبع (مانند بدنه پیام) هستند. این اطلاعات می‌توانند شامل طول محتوا یا نوع MIME باشند.

HTTP RequestوHTTP Responseبه‌عنوان درخواست و پاسخ در ارتباطات بر اساس پروتکل HTTP (Hypertext Transfer Protocol) عمل می‌کنند. این درخواست و پاسخ‌ها می‌توانند برای ارتباط بین نرم‌افزارهای مختلف و در زبان‌های مختلف مانند PHP و Java استفاده شوند.

همچنین، هدرهای HTTP گاهی اوقات بر اساس کارکرد پروکسی‌ها نیز دسته‌بندی می‌شوند. این دسته‌بندی‌ها بر اساس فاکتورهای مرتبط با پروکسی‌ها عمل می‌کنند و به‌عنوان‌مثال، می‌توان به هدرهای زیر اشاره کرد

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• TE
• Trailer
• Transfer-Encoding
• Upgrade

اطلاعات مذکور در هر یک از این دسته‌ها اهمیت خاص خود را دارند و نقش‌های مختلفی در مکانیزم عملکرد HTTP ایفا می‌کنند.

استفاده از Header در نرم‌افزارهای PHP

وقتی شما روی یک سرور کد می‌نویسید، به واقعیت نرم‌افزاری ایجاد می‌کنید که به درخواست‌های کلاینت‌ها پاسخ می‌دهد و شما در اینجا نقش سرور را دارید. شما می‌توانید در این نقش، Header پاسخ (Response Header) را تنظیم کنید. برای انجام این کار، می‌توانید از تابع `header` در PHP استفاده کنید.

پارامتر‌های این تابع عبارت‌اند از

headerیک مقدار Key:value از هدرهای HTTP با فرمت raw HTTP header.

replaceمقدار true یا false که نشان‌دهنده این است که در صورت وجود هدری با همان نام، آیا باید آن را جایگزین کنید یا به‌عنوان هدر جدید اضافه کنید. به‌عنوان‌مثال، وقتی که کوکی تنظیم می‌کنید، می‌توانید تصمیم بگیرید که آیا باید هدر موجود با همان نام را جایگزین کنید یا به‌عنوان هدر جدید اضافه کنید.

نکته مهم: این تابع همانند توابع set_cookie و session_start باید قبل از هر خروجی چاپ شده فراخوانی شود. در غیر این صورت با خطای “Cannot modify header information – headers already sent” مواجه خواهید شد.

به‌عنوان‌مثال، وقتی یک کاربر یک لینک را باز می‌کند و یک تصویر را برای او نمایش می‌دهیم

2 دسته اصلی HTTP header

هدرهای HTTP به دودسته اصلی تقسیم می‌شوند: “end-to-end” و “hop-by-hop”. هر دسته از این هدرها نحوه کارکرد و انتقال خود را دارند

هدرهای “End-to-End” (پایان به پایان)

این نوع هدرها باید از طرف فرستنده HTTP (سرور برای درخواست یا مشتری برای پاسخ) به گیرنده نهایی پیام HTTP ارسال شوند. این هدرها نباید توسط پروکسی‌های میانی تغییر داده شوند و باید توسط حافظه پنهان (caches) ذخیره شوند. به‌عبارت‌دیگر، این هدرها از سرور یا مشتری مستقیماً به گیرنده نهایی ارسال می‌شوند و اطلاعاتی مربوط به پیام درخواست یا پاسخ را نمایان می‌کنند.

هدرهای “Hop-by-Hop” (گام‌به‌گام)

این نوع هدرها فقط برای اتصال در سطح حمل‌ونقل (transport-level connection) استفاده می‌شوند و نباید توسط پروکسی‌ها دوباره انتقال داده یا توسط حافظه پنهان ذخیره شوند. هدرهای “hop-by-hop” تنها توسط هدرهای عمومی مربوط به پروکسی “Connection” تنظیم می‌شوند. این هدرها به‌عنوان ابزار کمکی برای مدیریت اتصالات و ارتباطات در اطراف پروکسی‌ها عمل می‌کنند.

در کل، هدرهای “end-to-end” معمولاً اطلاعات مرتبط با خود پیام HTTP را ارائه می‌دهند و تا گیرنده نهایی حفظ می‌شوند، درحالی‌که هدرهای “hop-by-hop” به پروکسی‌ها کمک می‌کنند تا ارتباطات بین خود و با سرورها را مدیریت کنند و باید توسط هدر “Connection” تعیین شوند.

ساختار درخواست HTTP header

هر درخواستی که از سمت مشتری (Client) به سمت سرور (Server) ارسال می‌شود، در قالب یک درخواست HTTP قرار دارد. این درخواست شامل یک بدنه که اطلاعات مربوط به درخواست را به نام “Request Body” حاوی می‌شود، همچنین یک سری اطلاعات مربوط به درخواست در قالب “Request Header” است. ساختار این اطلاعات برای تمامی درخواست‌ها یکسان است و به‌اصطلاح قوانین حاکم بر درخواست‌های HTTP استفاده می‌شود.

فرمت پیامی که در پروتکل HTTP از سمت مشتری به سمت سرور ارسال می‌شود یا به‌عبارت‌دیگر، “قالب پیام درخواست HTTP” به شکل زیر است

در ابتدا، ما با متد (Method) روبرو هستیم که به آن “فعل HTTP” هم می‌گویند. این متد همان متد ارسالی است که در فرم‌ها یا در دستورات CURL استفاده می‌شود. متد مورداستفاده بر اساس نسخه HTTP متفاوت است

• برای HTTP 1.0: POST، GET، HEAD
• برای HTTP 1.1: POST، GET، HEAD، PUT، DELETE

سپس، URL (همان لینک درخواست) آمده است که نشان‌دهنده مسیری است که مشتری از آن خواهد درخواست می‌کرد. به‌عبارت‌دیگر، مثلاً “gnutec.net/download” که در مرورگر یا هر کلاینت دیگری که از آن استفاده می‌کنید، یک درخواست به سروری خاص ارسال می‌کنید.

در ادامه، هدرهای HTTP (HTTP header) واقع می‌شوند. این هدرها به‌صورت Key: Value به یکدیگر مرتب شده‌اند و اطلاعات مختلفی را در خود جای‌داده‌اند. این هدرها دارای اطلاعاتی هستند که توسط مشتری (که ممکن است یک مرورگر وب یا یک برنامه) مشخص و تنظیم می‌شوند. در نهایت، ما بخش Entity Body را داریم که ممکن است بسته به نوع درخواست متفاوت باشد، اما به‌طورکلی اطلاعات مانند فیلدهای فرم یا فایل‌های آپلودی را در خود جای‌داده است.

به‌عنوان‌مثال، برای یک درخواست POST که از سمت مشتری (کلاینت) ارسال شده است، معمولاً یک سری رشته‌ها به نام “Query String” در آن وجود دارد. این Query String معمولاً مقادیر متغیرها را شامل می‌شود و در اینجا مثالی از آن آمده است

username=ali&password=secret$submit=submit+Query

نکته: برای درخواست‌های GET، Entity Body خالی است. این به این دلیل است که اطلاعات Query String در درخواست‌های GET به‌صورت مستقیم در URL قرار دارد.

ساختار پاسخ HTTP header

همچنین، هر پاسخی که از سمت سرور به سمت مشتری ارسال می‌شود، با رعایت یک ساختار کلی (پروتکل HTTP) قرار دارد. این پاسخ شامل یک بدنه (Entity Body) که معمولاً خروجی است (مانند متن HTML، JSON یا XML)، همچنین اطلاعات مربوط به پاسخ در قالب “Response Header” به همراه می‌آید.

یک ردیف وضعیت HTTP (HTTP Status Line) شامل کد وضعیت را داریم که نتیجه درخواست ارسالی از سمت سرور به کلاینت است. کدهای وضعیت بر اساس نوع درخواست به شرح زیر هستند

200 OKدرخواست HTTP به‌درستی اجرا شده و پاسخ به‌درستی به سمت مشتری ارسال شده است.

301 Moved Permanentlyپاسخ ارسال می‌شود، اما منبع درخواستی به طور دائمی منتقل شده است (معمولاً برای موتورهای جستجو استفاده می‌شود).

302 Foundصحت پاسخ و منبع درخواستی به‌صورت موقت منتقل شده (معمولاً برای موتورهای جستجو استفاده می‌شود).

400 Bad Requestاستاندارد درخواست به‌درستی رعایت نشده و درخواست نامعتبر است.

401 Unauthorizedعدم اجازه اجرای درخواست به دلیل عدم مجوز تشخیص‌داده‌شده توسط مجوز (authorization).

403 Forbiddenسرور به دلایل مختلف درخواست شما را غیرمجاز می‌داند و پاسخی ارسال نمی‌کند (مثلاً وب‌سایت‌هایی که آی‌پی‌های ایران را غیرمجاز می‌دانند مثل ORACLE).

404 Not Foundمنبع درخواستی بر اساس درخواست شما یافت نشد.

500 Internal Server Errorخطای داخلی بر روی سرویس‌دهنده رخ‌داده است.

سپس، هدرهای پاسخ HTTP (HTTP Response Headers) آمده‌اند. این هدرها به‌صورت Key: Value مرتب شده‌اند و اطلاعات مختلفی را در خود جای‌داده‌اند. این هدرها شامل اطلاعاتی مانند فرمت محتوا (Content-Type)، طول پیام، و زمان پاسخ هستند. در نهایت، بخش Entity Body (به‌عنوان‌مثال محتوای مربوط به خروجی) در پاسخ وجود دارد. این بخش ممکن است با فرمت‌های مختلفی مانند text/html، text/xml و یا application/json باشد.

4 روش تأیید اعتبار HTTP header

HTTP header ها شامل اطلاعات متنوعی هستند که دانستن آن‌ها می‌تواند ارتباط با HTTP را بهبود بخشد. مواردی که برای تأیید اعتبار در HTTP header ها استفاده می‌شوند، به چهار دسته تقسیم می‌شوند

WWW-Authenticateاین هدر به‌منظور تأیید اعتبار برای دسترسی به یک منبع مورداستفاده قرار می‌گیرد.

Authorizationاین هدر به‌عنوان یک روش برای تأیید اعتبار میان کاربر و سرور مورداستفاده قرار می‌گیرد.

Proxy-Authenticateاین هدر برای تأیید اعتبار منبع اصلی پروکسی استفاده می‌شود.

Proxy-Authorizationاین هدر به‌عنوان یک روش برای تأیید اعتبار بین کاربر و سرور پروکسی استفاده می‌شود.

Caching در HTTP header

مواردی که به‌صورت پنهان شده یا Caching در HTTP header ها وجود دارند، عبارت‌اند از

Ageاین هدر به مدت زمانی که یک شی در حافظه پنهان پروکسی بوده است اشاره می‌کند.

Cache-Controlاین هدر دستوراتی برای مکانیسم‌های ذخیره شده در هدر درخواست و در هدر پاسخ مشخص می‌کند.

Expiresاین هدر تاریخ یا زمان معینی را مشخص می‌کند که بعد از آن پاسخ تلقی شده منقضی می‌شود.

Pragmaاین هدر یک هدر خاص پیاده‌سازی را نمایان می‌کند که در هر جای زنجیره درخواست – پاسخ ممکن است اثرات مختلفی داشته باشد. معمولاً برای سازگاری معکوس با حافظه پنهان HTTP/1.0 که توی آن هدر Cache-Control هنوز وجود ندارد، استفاده می‌شود.

Warningاین هدر اخطارهای عمومی را در مورد اطلاعات در صورت بروز هر گونه مشکلی نمایان می‌کند.

این موارد در HTTP header ها برای مدیریت و اطلاعات بیشتر در ارتباطات و انتقال داده‌ها بین سرور و مشتری‌ها بسیار مفید هستند.

گیرنده در HTTP header

نکات مهم مرتبط با گیرنده‌ها در دنیای هدرهای HTTP در حال تکمیل‌شدن است و به‌صورت کامل نیست. در اینجا تعدادی از اطلاعاتی که تا به امروز جمع‌آوری شده‌اند را خدمتتان عنوان می‌کنیم.

Accept-CH

این هدر به سرورها اجازه می‌دهد که پشتیبانی از ویژگی‌های “Client Hints” را تبلیغ کنند، سرورها می‌توانند از قسمت “Accept-CH” یا عنصر معادل در HTML با ویژگی “http-Equiv” که توسط HTML5 معرفی شده است، برای ارتباط با مشتری‌ها استفاده کنند.

Accept-CH-Lifetime

این هدر به سرورها اجازه می‌دهد از مشتری خواسته شود که مجموعه ویژگی‌های مشتری را که توسط سرور پشتیبانی می‌شوند، برای مدت‌زمان مشخصی به یاد داشته و در درخواست‌های بعدی به سرور ارسال کنند.

Early-Data

این هدر نشان می‌دهد که درخواست به داده‌های اولیه ارسال شده است.

Content-DPR

این عدد نسبت پیکسل‌های فیزیکی به پیکسل‌های CSS از تصویر انتخاب شده را نشان می‌دهد.

DPR

این عدد نسبت Pixel Ratio (DPR) فعلی مشتری را نشان می‌دهد، به‌عبارت‌دیگر نسبت پیکسل‌های فیزیکی به پیکسل‌های CSS روی دستگاه است.

Device-Memory

این هدر نمایانگر مقدار تقریبی حافظه RAM دستگاه است و جزء API حافظه دستگاه محسوب می‌شود.

Viewport-Width

این عدد عرض نمایش طرح را در واحد پیکسل‌های CSS نشان می‌دهد و مقدار پیکسل ارائه شده به نزدیک‌ترین عدد صحیح کمتر (بیشینه) گرد می‌شود. اگر این هدر در یک پیام بیش از یک‌بار ظاهر شود، آخرین مقدار اعتباردار خواهد بود.

Width

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

موارد مشروط در HTTP header

Last-Modified

وجود تاریخ اصلاح اطلاعات یک منبع بسیار حیاتی است. تاریخ آخرین تغییرات در منبع برای مقایسه نسخه‌های مختلف همان منبع استفاده می‌شود. این نوع مقایسه به کمک دو هدر “If-Modified-Since” و “If-Unmodified-Since” انجام می‌شود و برای اعمال تغییر در درخواست‌ها استفاده می‌شود.

ETag

ETag یک‌رشته یکتا برای شناسایی نسخه‌های مختلف یک منبع است. درخواست‌های مشروط با استفاده از هدرهای “If-Match” و “If-None-Match” مورد بررسی قرار می‌گیرند. این اطلاعات برای تعیین تغییرات در رفتار درخواست‌ها مورداستفاده قرار می‌گیرد.

If-Match

این هدر درخواست را مشروط می‌کند و تنها در صورتی اعمال می‌شود که نسخه منبع با یکی از ETagهای اعلام شده مطابقت داشته باشد.

If-None-Match

این هدر درخواست را مشروط می‌کند و تنها در صورتی اعمال می‌شود که نسخه منبع با هیچ یک از ETagهای اعلام شده مطابقت نداشته باشد. این مورد معمولاً برای به‌روزرسانی حافظه پنهان (برای درخواست‌های ایمن) یا جلوگیری از بارگذاری منبع جدید هنگام وجود منبع موجود استفاده می‌شود.

If-Modified-Since

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

If-Unmodified-Since

این هدر درخواست را مشروط به شرایط می‌کند و انتظار دارد منبع تنها در صورتی انتقال داده شود که پس از تاریخ مشخصی تغییر نکرده باشد. این هدر اصلی برای تضمین انسجام‌بخش جدیدی از یک محدوده خاص با نسخه‌های قبلی یا برای پیاده‌سازی یک سیستم کنترل موقع اصلاح اسناد موجود استفاده می‌شود.

Vary

این هدر چگونگی مطابقت با هدرهای درخواست HTTP را تعیین می‌کند تا تصمیم گرفته شود که آیا می‌توان از یک پاسخ پنهان شده به‌جای درخواست پاسخ جدید از سرور مبدأ استفاده کرد یا خیر.

مدیریت اتصالات یا Connection Management در HTTP header

• Connectionاین مورد تصمیم می‌گیرد که آیا اتصال شبکه باید پس از پایان معامله فعلی باز بماند یا نه.
• Keep-Aliveاین مورد تعیین می‌کند که اتصال مداوم باید چقدر طول کشد.

تصمیم درباره محتوا در HTTP header

Acceptانواع داده‌های قابل‌ارسال به سرور را مشخص می‌کند.

Accept-Charsetمسئولیت کدگذاری کاراکترهایی که مشتری می‌تواند درک کند را بر عهده دارد.

Accept-Encodingالگوریتم کدگذاری، معمولاً یک الگوریتم فشرده‌سازی که می‌تواند در منبع ارسالی استفاده شود را مشخص می‌کند.

Accept-Languageسرور را از زبان انسانی که انتظار دارد سرور به آن ارسال کند مطلع می‌سازد. این نکته مهم است که تحت کنترل کامل کاربر نیست: سرور همیشه باید توجه داشته باشد که یک انتخاب صریح کاربر را نادیده نگیرد (مانند انتخاب زبان از لیست زبان‌های کشورها).

Cookie ‌ها در HTTP header

Cookieحاوی کوکی‌های ذخیره شده در HTTP header است که قبلاً توسط سرور با عنوان Set-Cookie ارسال شده‌اند.

Set-Cookieکوکی‌ها را از سرور به عامل کاربر ارسال می‌کند.

Cookie2حاوی کوکی HTTP است که قبلاً توسط سرور با هدر Set-Cookie2 ارسال شده اما منسوخ شده است. به‌جای آن از کوکی استفاده کنید.

Set-Cookie2کوکی‌ها را از سرور به عامل کاربر می‌فرستد، اما منسوخ شده است. به‌جای آن از Set-Cookie استفاده کنید.”

COR ها در HTTP header

Access-Control-Allow-Originنشان می‌دهد آیا می‌توان پاسخ را به اشتراک گذاشت یا خیر.

Access-Control-Allow-Credentialsنشان می‌دهد آیا می‌توان پاسخ درخواست را وقتی پرچم اعتبارنامه درست استفاده کرد یا خیر.

Access-Control-Allow-Headersدر پاسخ به درخواست قبل از ارسال پیشین برای نمایش اینکه از کدام هدرهای HTTP می‌توان در درخواست واقعی استفاده کرد، استفاده می‌شود.

Access-Control-Allow-Methodsروش‌های مجاز برای دسترسی به منبع در پاسخ به درخواست قبل از ارسال پیشین را مشخص می‌کند.

Access-Control-Expose-Headersنشان می‌دهد کدام عناوین می‌توانند به‌عنوان بخشی از پاسخ با ذکر نام آن‌ها در معرض دید قرار بگیرند.

Access-Control-Max-Ageنشان می‌دهد که نتایج یک درخواست قبل از ارسال پیشین می‌توانند در چه مدت زمانی ذخیره شوند.

اطلاعات بدنه پیام‌ها در HTTP header

Content-Lengthاندازه منبع، به تعداد بایت.

Content-Typeنوع رسانه منبع را نشان می‌دهد.

Content-Encodingبرای تعیین الگوریتم فشرده‌سازی استفاده می‌شود.

Content-Languageزبان‌های انسانی را که برای مخاطبان در نظر گرفته شده است توصیف می‌کند. نحوه عملکرد آن به کاربر اجازه می‌دهد تا باتوجه‌به زبان ترجیحی خود، تفاوت قائل شود.

Content-Locationمکان جایگزین برای داده‌های بازگشتی را نشان می‌دهد.

پروکسی‌ها

Forwardedاین اطلاعات از طریق پروکسی‌ها به مشتری ارسال می‌شود و نشان می‌دهد که آیا پروکسی‌ها در مسیر درخواست دخالت داشته‌اند و آیا تغییراتی روی آدرس منبع اعمال شده یا نه.

X-Forwarded-Forاین هدر، آدرس‌های IP اصلی مشتری را که از طریق پروکسی‌ها یا توازن‌دهنده‌ها به وب سرور متصل شده‌اند، شناسایی می‌کند.

X-Forwarded-Hostاین هدر میزبان اصلی درخواست ارسالی توسط مشتری را برای اتصال به پروکسی یا توازن‌دهنده بار مشخص می‌کند.

X-Forwarded-Protoاین هدر پروتکل (HTTP یا HTTPS) را که مشتری برای اتصال به پروکسی یا توازن‌دهنده بار استفاده کرده است، شناسایی می‌کند.

Viaاین هدر به پروکسی‌های مورداستفاده در مسیر درخواست و هدرهای پاسخ اضافه می‌شود.

درخواست‌های محدوده‌ها در HTTP header

Accept-Rangesاین هدر نشان می‌دهد آیا سرور از درخواست‌های محدوده پشتیبانی می‌کند یا خیر و اگر پشتیبانی می‌کند، در چه واحدی می‌توان دامنه محدوده را مشخص کرد.

Rangeاین هدر بخشی از محتوای یک منبع را نمایش می‌دهد که سرور باید بازگرداند.

If-Rangeاین هدر یک درخواست محدوده مشروط ایجاد می‌کند که فقط زمانی امکان‌پذیر است که ETag یا تاریخ مشخص شده با منبع از راه دور تطابق داشته باشد. این برای جلوگیری از بارگیری دوباره منبع ناسازگار استفاده می‌شود.

Content-Rangeاین هدر نشان می‌دهد که تمام بدنه پیام، جزئی از یک کل است.

انتقال کدگذاری در HTTP header

Transfer-Encodingاین هدر فرم رمزگذاری استفاده شده برای انتقال امن موجودیت را مشخص می‌کند.

2TEاین هدر، اگر کاربر تمایل داشته باشد، رمزگذاری‌های انتقال را تعیین می‌کند.

Trailerاین هدر به فرستنده امکان می‌دهد قسمت‌های اضافی را به پایان پیام اضافه کند.

WebSocket ها در HTTP header

• Sec-WebSocket-Key
• Sec-WebSocket-Extensions
• Sec-WebSocket-Accept
• Sec-WebSocket-Protocol
• Sec-WebSocket-Version

HTTP Host headerچه کمکی به رفع این مشکل می‌کند؟

در هر کدام از موارد بالا، از Host Header برای مشخص کردن دریافت کننده درخواست استفاده می‌شود. برای روشن ‌تر شدن این موضوع فرض کنید قرار است به شخصی که در یک آپارتمان زندگی می‌کند، نامه ای ارسال کنید. از آنجا که در خیابان محل زندگی شخص مورد نظر، آپارتمان های مشترکی وجود دارد بنابراین برای هر کدام از این آپارتمان ها باید از یک آدرس دقیق و مشخص استفاده شود. یکی از راهکارها برای حل این مسأله این است که در آدرس، شماره پلاک آپارتمان یا نام گیرنده نامه نوشته شود. Host Header نیز برای پیام های دریافتی HTTP، کاربرد مشابهی با نوشتن شماره پلاک یا نام گیرنده در آدرس دارد.

هنگامی که مرورگر یک درخواست را ارسال می‌کند، نشانی وب (URL) مقصد تبدیل به آدرس IP سرور می‌شود. سرور پس از دریافت این درخواست به Host Header مراجعه می‌کند تا Back End موردنظر را تشخیص داده و درخواست را متناسب با آن به سمت مقصد موردنظر مسیریابی کند.

حملهHTTP Host headerچیست؟

حملات HTTP header، وب‌سایت‌های آسیب‌پذیری که HTTP header در آن‌ها با یک روش ناامن مدیریت می‌شود را مورد سوءاستفاده قرار می‌دهند. اگر سرور به Host header اعتماد داشته و درخواست ورودی را اعتبارسنجی نکند، مهاجم می‌تواند از طریق این ورودی برای تزریق پی‌ لودهای مخربی استفاده کند که باعث تغییر رفتار در سمت سرور می‌شوند. به حملاتی که شامل تزریق مستقیم پی ‌لود به HTTP header هستند، حمله «تزریق HTTP header» گفته می‌شود.

معمولاً برای سامانه‌های نرم‌افزاری تحت وب آماده که مشخص نیست بر روی چه دامنه‌هایی نصب می‌شوند؛ در هنگام راه‌اندازی، دامنه موردنظر را به‌صورت دستی در فایل پیکربندی آن مشخص می‌کنند. به‌این‌ترتیب وقتی این سامانه‌ها نیازمند اطلاع از دامنه جاری باشند (برای مثال جهت تولید URL موجود در یک ایمیل) باید آن را از HTTP header بازیابی کنند

Contact support

البته ممکن است از header در تعاملات مختلفی که بین سیستم‌های متفاوت در زیرساخت وب‌سایت نیز وجود دارد، استفاده شود.

ازآنجاکه کاربر امکان کنترل HTTP header را دارد، این موضوع می‌تواند منجر به ایجاد مشکلات زیادی شود. اگر ورودی به شکل مناسبی اعتبارسنجی یا رد نشود، HTTP header می‌تواند مسیری را ایجاد کند که توسط آسیب‌پذیری‌های مختلف مورد سوءاستفاده قرار گیرد.

تعدادی از این آسیب‌پذیری‌ها عبارت‌اند از

• ایجاد آسیب‌پذیری در حافظه پنهان (Cache) وب
• ایجاد نقص در بعضی از عملکردهای خاص منطق تجاری (Business Logic)
• اجرای حملات SSRF (ارسال درخواست جعلی به سرور) از طریق مسیریابی
• آسیب‌پذیری‌های سنتی که در سمت سرور وجود دارند، مثل تزریق کدهای SQL.

آسیب‌پذیری‌هایHTTP Hostچگونه ایجاد می‌شوند؟

معمولاً آسیب‌پذیری‌های HTTP Host با این تصور اشتباه ایجاد می‌شوند که Header، تحت کنترل کاربر قرار ندارد. این تصور باعث ایجاد اطمینان کامل به Host header و عدم بررسی یا رد آن می‌شود. درحالی‌که مهاجمان به‌راحتی می‌توانند با استفاده از ابزارهایی همچون Burp Proxy اطلاعات آن را تغییر دهند.

حتی اگر Host header توسط یک روش امنیتی مدیریت و استفاده شود باتوجه‌به نوع پیکربندی سرورهایی که با درخواست‌های ورودی سروکار دارند، باز هم امکان تغییر Host از طریق تزریق سایر Headerها وجود دارد. گاهی پیش می‌آید مالک یک وب‌سایت از این که Headerها به‌صورت پیش‌فرض پشتیبانی می‌شوند، اطلاعی نداشته باشد؛ بنابراین احتمال دارد که بادقت کافی با آن برخورد نکند.

در واقع دلیل بروز بسیاری از این آسیب‌پذیری‌ها استفاده از روش‌های کدنویسی ناامن نیست؛ بلکه این است که یک یا چند مورد از اجزای زیرساخت مرتبط، با روش‌های نادرست و غیر امن پیکربندی شده‌اند. دلیل این مشکلات در پیکربندی هم این است که وب‌سایت‌ها از سایر فناوری‌های شخص ثالث در معماری‌شان استفاده می‌کنند، بدون این که از گزینه‌های مختلف پیکربندی و پیامدهای امنیتی آن مطلع باشند.

روش‌های مقابله با حملاتHTTP Host header

ساده‌ترین راه برای مقابله با حملات HTTP Host header، عدم استفاده از Host header در کد سمت سرور است. ابتدا مطمئن شوید آیا تمام آدرس‌های URL باید به‌صورت مطلق باشند یا خیر (یعنی آدرس، به‌صورت کامل و به همراه پروتکل، نام دامنه و… استفاده شود)؟ معمولاً امکان استفاده از آدرس URL نسبی به‌جای آدرس مطلق وجود دارد. همین یک تغییر کوچک می‌تواند به پیشگیری از ایجاد آسیب‌پذیری در حافظه کش وب (web cache poisoning) کمک کند.

سایر روش‌ها برای جلوگیری از انجام حملاتHTTP Host headerعبارت‌اند از

محافظت از آدرس‌هایURLمطلق

زمانی که از آدرس‌های URL مطلق استفاده می‌کنید بایستی تنظیمات را به صورتی تغییر دهید که مشخص‌کردن نام دامنه فعلی در فایل پیکربندی و ارجاع به آن به‌جای Host header الزامی باشد. این روش باعث برطرف‌کردن مخاطراتی همچون آسیب‌پذیری تنظیم مجدد کلمه عبور توسط مهاجمان می‌شود.

اعتبارسنجیHost header

اگر لازم است از Host header استفاده کنید، حتماً آن را با روش مناسبی اعتبارسنجی کنید. برای انجام این کار می‌توانید آن را با یک لیست سفید (Whitelist) که شامل دامنه‌های مجاز است، مقایسه کرده و درخواست‌های ارسالی برای Hostهایی که خارج از این لیست هستند را تغییر مسیر داده یا رد کنید.

برای کسب اطلاعات بیشتر درباره نحوه انجام این کار، به مستندات چارچوبی که با آن کار می‌کنید مراجعه کنید. برای مثال در چارچوب Django گزینه ALLOWED_HOSTS در فایل تنظیمات قرار دارد. این روش به کاهش میزان احتمال حمله در Host header کمک می‌کند.

عدم پشتیبانی ازHeaderهای اضافه

علاوه بر موارد بالا باید مطمئن شوید از Headerهایی که برای اجرای این حملات استفاده می‌شوند، به‌ویژه “X-Forwarded-Host” پشتیبانی نمی‌شود. توجه داشته باشید که ممکن است در حالت پیش‌فرض، این Headerها پشتیبانی شوند.

دامنه‌های مجاز

به‌منظور جلوگیری از انجام حملات مبتنی بر مسیریابی بر ضد زیرساخت‌های داخلی سازمان باید تعدیل‌کننده بار یا پروکسی معکوس را به‌گونه‌ای پیکربندی کنید که تنها با درخواست‌های مجاز کار کند.

مراقبت از میزبان‌های مجازی «فقط داخلی»

هنگام استفاده از میزبان‌های مجازی باید از میزبانی وب‌سایت‌ها و سامانه‌های «فقط داخلی» بر روی سروری که با محتوای عمومی سروکار دارد، خودداری کنید. در غیر این صورت ممکن است هکرها از طریق دست‌کاری Host header به دامنه‌های داخلی دسترسی پیدا کنند.

برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمای پشتیبانی شبکه را نیز مطالعه کنید.