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

در این مطلب از فراست به بررسی 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: faraasat.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 استفاده کنید.

<?php header ( $header , $replace ); ?>

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

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

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

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

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

<?phpheader(“Content-Type: image/jpeg”);header(“Content-Disposition: attachment; filename=ComputerCoffie.jpeg”);readfile(“http://gnutec.net/images/comcoff.jpg”);

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 بازیابی کنند:

<a href=”https://_SERVER[‘HOST’]/support”>Contact support</a>

البته ممکن است از 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 به دامنه‌های داخلی دسترسی پیدا کنند.