اگر صفحه ورودی کورکورانه قابل اعتماد باشد، اتفاقی همچون تصویر زیر رقم می خورد که در اینجا مثالی از نحوه ظاهر آن آمده است:
در این حالت، کلاینت یک درخواست اولیه را برای ما ارسال می کند که قبلاً شامل یک هدر X-Forwarded-For با مقدار 1.1.1.1 است. این میتواند آدرس داخلی واقعی مشتری باشد که توسط پروکسی سرور مربوط به کلاینت اضافه شده است، یا میتواند تلاشی از سوی مشتری برای گیج کردن سرور در مورد IP مشتری باشد. تشخیص تفاوت برای ما غیرممکن است، بنابراین باید این را نادیده بگیریم و آدرس مشتری را که زیرساخت ما می بیند (28.178.124.142) به عنوان IP منبع واقعی در نظر بگیریم.
یکی از راههای به دست آوردن کنترل روی هدر X-Forwarded-For، درگیر کردن یک پراکسی معکوس قابل اعتماد و غیرفعال کردن دسترسی مستقیم در سطح شبکه به سرور باطن و سایر پراکسیها /سرورها /بالانسکنندههای بار از طریق آن پراکسی است. برای توسعه دهندگان API، معمولاً توسط یک دروازه API مدیریت می شود، اما می تواند یک CDN مانند Fastly ،Squid Proxy ،Cloudflare و غیره نیز باشد.
به طور کلی، هرچه در هدر به سمت چپ تر نگاه کنید، فضای بیشتری برای اشتباهات وجود دارد، زیرا سرورهای بیشتری وجود دارند که ممکن است به اشتباه پیکربندی شده باشند و هر چیزی که از سمت چپ ترین پروکسی که کنترل می کنید می آید باید با شک و تردید برخورد شود.
برای بررسی ادامه مقاله به لینک زیر مراجعه کنید:
منبع : پروتکل X-Forwarded-For چیست