پروتکل X-Forwarded-For چیست

مهشید نصوحی

تیر 10, 1403

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

از این رو برای جلوگیری از این حملات، پروتکل های زیادی در حال ارائه و یا بروزرسانی هستند تا بتوانند از کسب و کار شما محافظت کرده و امنیت شبکه شما را فراهم سازند. از طرف دیگر برای هر یک از تجهیزات شبکه همچون سرور، روتر، فایروال، سوئیچ و … پروتکل جداگانه ای ارائه می گردد که تنها قابل نصب و پیکربندی بر روی همان دستگاه می باشد. در این مقاله قصد داریم در رابطه با ” پروتکل X-Forwarded-For چیست” صحبت کنیم و این پروتکل را مورد بررسی قرار دهیم؛

پروتکل X-Forwarded-For چیست:

X-Forwarded-For یا XFF یک پروتکل بسیار رایج است که برای شناسایی آدرس IP مبدا یک کلاینت از طریق پروکسی HTTP که به وب سرور متصل می شود، به کار می رود. این روش برای حفظ امنیت و جلوگیری از حملات در فضای اینترنتی است.

فرایند عملیاتی این پروتکل به این صورت است که ریکوئست هدر X-Forwarded-For، به طور خودکار اضافه شده و به شما کمک می کند تا آدرس IP یک کلاینت را هنگام استفاده از متعادل کننده بار HTTP یا HTTPS شناسایی کنید.

از آنجا که متعادل کننده های بار ترافیک بین کلاینت ها و سرورها را رهگیری می کنند، گزارش های دسترسی سرور شما فقط حاوی آدرس IP متعادل کننده بار هستند. در نتیجه برای مشاهده آدرس IP مشتری، از ریکوئست هدر X-Forwarded-For استفاده کنید.

Elastic Load Balancing آدرس IP کلاینت را در ریکوئست هدر X-Forwarded-For ذخیره می کند و هدر درخواست آن را به سرور شما ارسال می کند. اگر درخواست توسط X-Forwarded-For گنجانده نشده باشد، متعادل کننده بار، یک درخواست را با آدرس IP کلاینت به عنوان مقدار درخواست، ایجاد می کند. در غیر این صورت، متعادل کننده بار، آدرس IP کلاینت را به هدر موجود اضافه می کند و هدر را به سرور شما ارسال می کند.

هدر X-Forwarded-For ممکن است حاوی چندین آدرس IP باشد که با کاما از هم جدا شده اند. سمت چپ ترین آدرس IP کلاینت است که در آن درخواست برای اولین بار انجام شده است که توسط هر شناسه پروکسی بعدی، در یک زنجیره دنبال می شود.

به طور کلی می توان گفت، XFF تنها زمانی راه درست برای دریافت IP کلاینت است که شما مطمئن باشید از طریق پروکسی آن را دریافت کرده اید، اگر مقدار قابل استفاده در آن وجود ندارد باید متغیر REMTE_ADDER را به صورت پیش فرض انتخاب کنید.

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

XFF زمانی نتیجه می دهد که سرور پروکسی به درستی آدرس IP میزبان اصلی را گزارش کند. به همین دلیل، استفاده مؤثر از XFF مستلزم آگاهی از این است که کدام پروکسی‌ها قابل اعتماد هستند. مثلا شما می توانید آدرس های IP را در لیست سفید سرورهایی که به آن ها اعتماد دارید جست و جو کنید.

فرمت کلی فیلد باید به صورت زیر باشد:

X-Forwarded-For: client, proxy1, proxy2, proxy3

به این فیلد دقت کنید؛ فهرستی از آدرس های IP را مشاهده می کنید که با علامت “,” از یکدیگر جدا شده اند. آدرسی که در چپ ترین قسمت فیلد است را کلاینت اصلی می گویند و به ترتیب پروکسی های متوالی که درخواست ارسال کرده اند را مشاهده می کنید، هر آدرس IP از جایی که درخواست دریافت می کند، بعد از کاما اضافه می شود. مثلا در فیلد بالا، درخواست از طریق proxy1 سپس proxy2 و در نهایت Proxy3 ارسال شده است.

X-Forwarded-For: 203.0.113.195:41237, 198.51.100.100:38523

X-Forwarded-For: [2001:db8::1a2b:3c4d]:41237, 198.51.100.100:26321

X-Forwarded-For: [2001:db8::aa:bb]

از آنجایی که هدر X-Forwarded-For به طور رسمی استاندارد نشده است، هنوز برخی تغییرات در قالب آدرس IP وجود دارد. به عنوان مثال، برخی از پیاده‌سازی‌هایی که در [ ] می بینید، شامل شماره پورت کلاینت‌ها و یا آدرس‌های IPv6 که حتی بدون شماره پورت در براکت‌های مربع قرار می‌دهند، مشابه فرمت بالا؛

X-Forwarded-For توسط پروکسی های HTTP هنگام ارسال درخواست، اضافه یا ویرایش می شود. سرور، آدرس سرویس گیرنده را به یک هدر X-Forwarded-For موجود که با کاما از هم جدا شده است، اضافه می کند، یا یک هدر X-Forwarded-For جدید با آدرس مشتری به عنوان یک مقدار جدید ایجاد می کند.

از آنجایی که جعل فیلد X-Forwarded-For آسان است، اطلاعات داده شده باید با دقت مورد استفاده قرار گیرد. سمت راست ترین آدرس IP، همیشه آدرس IP است که به آخرین پروکسی متصل می شود، به این معنی که مطمئن ترین منبع اطلاعات به حساب می آید. داده های X-Forwarded-For را می توان در سناریوی پروکسی رو به جلو یا معکوس استفاده کرد. اگر سرور پشت یک پروکسی معکوس قابل اعتماد باشد و فقط اتصالات از آن پروکسی را مجاز کند، معمولاً می توان مقدار هدر را قابل اعتماد فرض کرد.

فقط وارد کردن مقدار فیلد X-Forwarded-For همیشه کافی نیست، زیرا آخرین آدرس IP پروکسی در یک زنجیره در قسمت X-Forwarded-For موجود نیست، بلکه در هدر IP واقعی موجود است. یک وب سرور باید هم آدرس IP منبع درخواست و هم اطلاعات فیلد X-Forwarded-For را برای کامل بودن، ثبت کند.

از نکات مثبت این پروتکل می توان به این نکته اشاره کرد که، زمانی که برنامه پشتیبان درخواست دریافتی را مشاهده می کند، آدرس IP مشتری اصلی مدت زیادی فراموش می شود. اینجاست که هدر X-Forwarded-For می تواند کمک کند. هدف در اینجا این است که به یک پروکسی این فرصت را بدهیم که بگوید “صبر کن، من یک درخواست را برای شما ارسال می کنم، و من می دانم این تاریخچه از کجا آمده است”.

توجه داشته باشید که آخرین پروکسی آدرس IP خود را به لیست اضافه نمی کند، زیرا این آدرس از قبل در دسترس است: اگر گیرنده درخواست به این موضوع اهمیت دهد که چه کسی مستقیماً با آن تماس می گیرد، می تواند X-Forwarded-For را با آدرس IP منبع درخواست ترکیب کند.

X-Forwarded-For: 28.178.124.142, 198.40.10.101

X-Forwarded-For چه کاربردی دارد؟

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

احراز هویت کاربر: از اطلاعات سرصفحه یا هدر استفاده کنید تا اطمینان حاصل کنید که تلاش‌های ورود به سیستم از مکان‌های شناخته شده و مجاز سرچشمه می‌گیرند، در غیر اینصورت ورود به سیستم را به‌عنوان مشکوک علامت‌گذاری کنید و بررسی‌های 2FA را آغاز کنید.
Load Balancing: ترافیک ورودی را به طور یکنواخت بین سرورها توزیع می کند تا از عملکرد بهینه در دوره های شلوغ اطمینان حاصل کند.
محلی سازی داده ها: اتحادیه اروپا، برزیل، چین و سایرین قوانین حفظ حریم خصوصی در مورد محل نگهداری داده ها را دارند و این می تواند به شناسایی آن دسته از کاربرانی که نیاز به رفتار ویژه دارند کمک کند.
تحویل محتوای جغرافیایی: CDN ها از X-Forwarded-For برای تعیین موقعیت کاربر و ارائه محتوا از نزدیکترین سرور برای کاهش تأخیر استفاده کنند.
کنترل دسترسی و امنیت: وب‌سایت‌ها از X-Forwarded-For برای تأیید مشروعیت درخواست‌ها و پیاده‌سازی کنترل‌های دسترسی بر اساس آدرس‌های IP استفاده می‌کنند، مانند یک اینترنت شرکتی که فقط به کارمندانی که از محدوده IP شناخته‌شده دفتر می‌آیند، اجازه دسترسی به منابع خاصی را می‌دهد.
فایروال های برنامه کاربردی وب (WAF): ترافیک ورودی را فیلتر می کند، درخواست های مشکوک را از یک آدرس IP مخرب شناخته شده فهرست می کند و در X-Forwarded-For مسدود می نماید.
پیشگیری از کلاهبرداری: موسسات مالی از X-Forwarded-For برای شناسایی و جلوگیری از فعالیت های کلاهبرداری بر اساس مکان کاربر استفاده می کنند، به عنوان مثال: شناسایی یک تلاش غیرعادی برای ورود به سیستم از مکانی که با الگوهای دسترسی معمولی کاربر ناسازگار است.
API Rate Limiting: از X-Forwarded-For برای اعمال محدودیت نرخ بر اساس هر مشتری استفاده می کنند. یک ارائه‌دهنده API تعداد درخواست‌های یک آدرس IP خاص را در یک بازه زمانی معین محدود می‌کند تا از سوء استفاده جلوگیری کند.
تبلیغات محلی: پلتفرم های تبلیغاتی از X-Forwarded-For برای سفارشی سازی و هدف قرار دادن تبلیغات بر اساس موقعیت جغرافیایی کاربر استفاده می کنند.
Logging و Analytics: امکان ورود به سیستم جهت تجزیه و تحلیل الگوها و رفتارهای ترافیک کاربر در جهت برآورد اهداف آماری، همچون توزیع جغرافیایی کاربران در یک دوره زمانی خاص.

آیا X-Forwarded-For قابل اعتماد است؟

شما هرگز نباید به درخواست HTTP که از دنیای بیرون می آید و شامل هدرهای X-Forwarded-For می شود، کاملاً اعتماد کنید. ممکن است این اطلاعات مخرب باشند یا پیکربندی نادرست داشته باشند، اما در هر صورت محتویات یک درخواست HTTP می‌تواند به طور کامل ساخته شود و هر کسی می‌تواند از X-Forwarded-For استفاده کند تا وانمود کند که چون IP را می دانند از داخل VPN شرکت شما می‌آیند و یا وانمود کنند در همان منطقه جغرافیایی هستند که کاربری با حساب بانکی‌اش سعی در ورود به آن را دارند و مواردی مشابه به این فرایند.

بیشتر بخوانید: تفاوت بین VPN و VPS

اگر صفحه ورودی کورکورانه قابل اعتماد باشد، اتفاقی همچون تصویر زیر رقم می خورد که در اینجا مثالی از نحوه ظاهر آن آمده است:

در این حالت، کلاینت یک درخواست اولیه را برای ما ارسال می کند که قبلاً شامل یک هدر X-Forwarded-For با مقدار 1.1.1.1 است. این می‌تواند آدرس داخلی واقعی مشتری باشد که توسط پروکسی سرور مربوط به کلاینت اضافه شده است، یا می‌تواند تلاشی از سوی مشتری برای گیج کردن سرور در مورد IP مشتری باشد. تشخیص تفاوت برای ما غیرممکن است، بنابراین باید این را نادیده بگیریم و آدرس مشتری را که زیرساخت ما می بیند (28.178.124.142) به عنوان IP منبع واقعی در نظر بگیریم.

یکی از راه‌های به دست آوردن کنترل روی هدر X-Forwarded-For، درگیر کردن یک پراکسی معکوس قابل اعتماد و غیرفعال کردن دسترسی مستقیم در سطح شبکه به سرور باطن و سایر پراکسی‌ها /سرورها /بالانس‌کننده‌های بار از طریق آن پراکسی است. برای توسعه دهندگان API، معمولاً توسط یک دروازه API مدیریت می شود، اما می تواند یک CDN مانند Fastly ،Squid Proxy ،Cloudflare و غیره نیز باشد.

به طور کلی، هرچه در هدر به سمت چپ تر نگاه کنید، فضای بیشتری برای اشتباهات وجود دارد، زیرا سرورهای بیشتری وجود دارند که ممکن است به اشتباه پیکربندی شده باشند و هر چیزی که از سمت چپ ترین پروکسی که کنترل می کنید می آید باید با شک و تردید برخورد شود.

برای کمک به این امر، می توانید در سطح پروکسی معکوس تصمیماتی بگیرید که نحوه ساخت هدر را تغییر می دهد. به عنوان مثال، nginx می تواند هدر X-Forwarded-For را به طور کامل لغو کند، هر چیزی را که مشتری ارائه می دهد حذف کند و آدرس IP را که می بیند جایگزین کند. اگر همه درخواست‌ها از طریق nginx ارائه شوند، این کار به طور موثر یک خط را در اطراف زیرساخت شما ترسیم می‌کند و تمام مقادیر غیرقابل اعتماد دریافت‌شده از خارج را حذف می‌کند و به همه سرویس‌های دیگر در زیرساخت شما اجازه می‌دهد به هدر اعتماد کنند.

می توانید این کار را برای nginx با استفاده از تنظیمات زیر انجام دهید:

;proxy_set_header X-Forwarded-For $remote_addr

این هدر X-Forwarded-For را با آدرس IP واقعی مشتری جایگزین می کند و هر چیز دیگری را حذف می کند.

با این کار مشکل مشتری بالا که به نظر می‌رسد سعی می‌کند آدرس IP خود را مخفی کند، یا وانمود می‌کند که شخص دیگری است، با ارسال یک هدر X-Forwarded-For جعلی، مشکل را حل می‌کند. این هدر توسط CDN نادیده گرفته می شود و مقدار درخواست فقط با آدرس IP واقعی که توسط آن سرور مشاهده می شود جایگزین می شود تا اینکه کورکورانه پذیرفته شود، مانند این:

حذف همه مقادیر خارجی، ایمن‌ترین رویکرد است، زمانی که مطمئن نیستید بقیه زنجیره تماس شما چقدر امن و قابل اعتماد خواهد بود. اگر سایر پروکسی‌ها و برنامه‌های باطن احتمالاً کورکورانه به اطلاعات دریافتی اعتماد می‌کنند، یا عموماً انتخاب‌های ناامنی انجام می‌دهند (که بعداً به آن‌ها خواهیم پرداخت)، احتمالاً جایگزین کردن کامل هدر X-Forwarded-For در آن دنیای خارج، ایمن‌تر است. پروکسی را معکوس کنید و هر گونه داده غیرقابل اعتماد را در فرآیند حذف کنید.

از سوی دیگر، اگر مطمئن هستید که برنامه Backend قادر به مدیریت آن است، می توانید مقادیر ورودی را بپذیرید و به سادگی آدرس IP را که توسط سرور مشاهده می شود در انتهای زنجیره اضافه کنید. این می تواند مفید باشد اگر زیرساخت شما لزوماً یک نقطه ورودی ندارد و تضمین این نوع پاکسازی هدر را دشوارتر می کند.

برای اینکه به سادگی آدرس ورودی را به هدر اضافه کنید، اما مقادیر اصلی را نیز حفظ کنید، می توانید از این پیکربندی nginx استفاده کنید:

;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for

این یک عملکرد ویژه در nginx است، اما اکثر پروکسی های معکوس منطق مشابهی دارند. این هدر را ایجاد می کند تا هر آنچه را که کلاینت در ابتدا ارسال کرده است حفظ کند، و اگر آنها از طریق هر پروکسی واسطه ای متصل شوند، تا زمانی که آن پراکسی ها از X-Forwarded-For پشتیبانی می کنند، آن اطلاعات نیز به همراه خواهد داشت.

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

پیاده سازی X-Forwarded-For:

در این قسمت از مقاله قصد داریم تا پیاده سازی این قابلیت را به شما آموزش دهیم؛ به تصاویر زیر توجه کرده و نکات مورد نیاز را بررسی کنید:

در قسمت server object می توانید گزینه X-Forwarded-For را ببینید، حالا بر روی گزینه Create New کلیک کنید.

وقتی بر روی گزینه create New کلیک کردید، منویی برایتان باز می شود که حاوی عنوان های زیر است:

Add X-Forwarded-For
Add X-Real-IP
Add X-Forwarded-Proto
Use X-Header to identify Original Client’s IP

هر یک از این آیتم ها را می خواهیم به صورت مجزا توضیح مختصری بدهیم؛

–Add X-Forwarded-For: در این قسمت IP اصلی بسته ها به سرور داده می شود و IP ها به صورت یک آرایه ارسال می شوند این به ما کمک می کند اگر دستگاهی در فورتی وب از قبل موجود باشد، IP آن هم ارسال می شود.

– Add X-Real-IP: اگر این گزینه را فعال کردید، IP اصلی را دریافت خواهید کرد ولی تنها IP مشتری را خواهید داشت.

-Add X-Forwarded-Proto: این قسمت به شما می گوید که کلاینت از چه پروتکل اورجینالی استفاده کرد است.

–Use X-Header to identify Original Client’s IP: اگر قبل از فورتی وب دستگاه دیگری این کار را انجام داده باشد، همه درخواست های قبلی به وسیله IP آن دستگاه ارسال می شود. در این صورت اگر حمله ای اتفاق بی افتد IP هایی که مربوط به درخواست های قبل هستند مسدود می شود. اگر این آیتم را فعال کنید، موجب می شود که IP اصلی را از X-Forwarded-For بخواند و بر اساس IP اصلی مسدود کند. گزینه left و right که در این قسمت می بینید نشان دهنده این است که IP را از سمت راست بخواند یا از سمت چپ.

در نهایت بر روی دکمه OK کلیک کنید سپس می بینید که Create New برایتان فعال می شود و می توانید IP دستگاهی که درخواست است و کار X-Forwarded-For را می خواهد انجام دهد را وارد کنید.