متعادل کننده بار نقش مهمی در امنیت اطلاعات بازی می کند، اما همچنین می تواند منجر به مشکلاتی در مورد جعل IP و موارد دیگر شود.
یکی از مزایای متخصص امنیت کار کردن با تیم های متعدد است. پس از ممیزی، متخصصان امنیتی این فرصت را خواهند داشت که با مدیران و تحلیلگران پایگاه داده کار کنند. برای اینکه یک اپلیکیشن به درستی و ایمن کار کند، این تیم ها سعی می کنند با آسیب پذیری های امنیتی که مبنای مشترکی دارند، مقابله کنند. گفتگوهای بین این تیم ها برخی از مشکلات را در مورد IP واقعی ایجاد می کند.
پروکسی و مفاهیم IP واقعی
برنامه های کاربردی وب امروزی بر روی چندین سرور برنامه و سیستم های پایگاه داده اجرا می شوند. تصور کنید دو سرور برنامه یک کد منبع را به اشتراک می گذارند. درخواست‌های کاربر بسته به وضعیت بارگذاری، برای هر یک از این سرورها آماده است. مکانیسم متعادل کننده بار، که درخواست های HTTP را در مقابل سرورهای برنامه مدیریت می کند، تصمیم می گیرد که کدام درخواست به کدام سرور برنامه ارسال شود. این یک سوال بزرگ برای مدیران سیستم میان افزار و توسعه دهندگان نرم افزار ایجاد می کند: آدرس IP واقعی کاربر چیست؟
پروکسی ها وظیفه انتقال داده ها بین دو سیستم را بر عهده دارند. متعادل کننده بار مکانیزمی است که مسئول پروکسی است. به عبارت دیگر، فقط یک سیستم هم با کاربر و هم با سرور برنامه ارتباط برقرار می کند. از نظر ترافیک شبکه، سرورهای وب A یا وب B همیشه با آدرس IP متعادل کننده بار در ارتباط هستند. همین امر ممکن است در مورد کاربران نیز گفته شود. برای متخصصان امنیتی، متعادل کننده های بار مشکلات جدی در حملات تزریق SQL مبتنی بر زمان ایجاد می کنند. اما تمرکز اصلی در اینجا جعل IP است.
X-Forwarded-For و IP Relationship
رابطه بین X-Forwarded-For، توسعه دهنده و میان افزار را در نظر بگیرید. به عنوان مثال، فرض کنید که وظیفه توسعه دهنده یک برنامه این است که تمام فعالیت ها، مانند تلاش های اشتباه برای رمز عبور توسط کاربران را با آدرس IP آنها ثبت کند. در ابتدا، توسعه دهنده آدرس IP کاربر را زمانی که درخواست HTTP با فرصتی که توسط زبان برنامه نویسی استفاده می کند برآورده شد، تعیین می کند و سعی می کند به استفاده از این داده ها در برنامه ادامه دهد.
از آنجایی که آدرس IP آن در طول فرآیند توسعه ثابت می‌شود، همیشه در طول آزمایش‌ها آدرس یکسانی را مشاهده می‌کند زیرا به طور کلی، رایانه‌های کاربر در شبکه‌های شرکتی با IP ثابت از طریق آدرس MAC کار می‌کنند. واحد برخی از آزمون های پذیرش را انجام خواهد داد. با این حال، مشکلاتی با این وجود خواهد داشت. واحد تست این مشکل را به توسعه دهنده نرم افزار ارسال می کند.
در این مرحله، توسعه‌دهنده ممکن است یک کنترل‌کننده در محیط توسعه بنویسد و درخواست HTTP را به صورت خام به برنامه ارسال کند، زیرا همه آدرس IP یکسانی دارند. این منجر به کار با X-Forwarded-For خواهد شد.
اطلاعات هدر به نام X-Forwarded-For به سرور برنامه ارسال می شود. در این مرحله، توسعه‌دهنده نرم‌افزار آدرس IP خود را که با ipconfig کنترل می‌کند، می‌بیند، نه متعادل‌کننده بار را که در گزارش‌ها می‌بینند. بسیاری از برنامه نویسان فکر می کنند که می توانند این مشکل را با یک بلوک کد مانند زیر حل کنند:
function getIPaddress() {
$ipKeys = array(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
foreach ($ipKeys as $key) {
if (array_key_exists($key, $_SERVER) === true) {
foreach (explode(',', $_SERVER[$key]) as $ip) {
$ip = trim($ip);
if (validate_ip($ip)) {
return $ip;
}
}
}
}
return isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : false;
}
این کافی نخواهد بود – توسعه دهنده باید بررسی کند که آیا مقدار ورودی یک آدرس IP معتبر است یا خیر.
همه چیز در بالا متعلق به بخشی بود که توسط توسعه دهنده اداره می شد. اما برای اینکه یک برنامه کاربردی به درستی و ایمن کار کند، تیم‌ها – که در تئوری با هم کار می‌کنند، اما در واقعیت، در نقاط بسیار زیاد از یکدیگر کار می‌کنند – سعی می‌کنند با آسیب‌پذیری‌های امنیتی که مبنای مشترکی دارند مقابله کنند. حال سعی کنید از منظر شخصی که مسئول پیکربندی بار متعادل کننده است به موضوع نگاه کنید.
مدیران سیستم ممکن است فکر کنند که توسعه دهندگان اطلاعاتی مانند X-Forwarded-For را ضبط می کنند زیرا داده های موجود در درخواست HTTP قابل اعتماد نیستند. این مدیران اغلب X-Forwarded-For را ارسال می کنند. با این حال، آنها همچنین آدرس منبع TCP سیستمی را که درخواست را به عنوان مقدار هدر دوم ارسال کرده است، ارسال می کنند. ساختار True-Client-IP مثال خوبی برای این موضوع است.
وقتی همه این موارد را کنار هم قرار می دهید، دو واحد مختلف مسیرهای متفاوتی را برای یک مشکل دنبال می کنند که به عنوان جعل IP کلاینت شناخته می شود. نتیجه یک مسئله حیاتی است که در آن هیچ ثبت IP و مجوز مبتنی بر IP کار نخواهد کرد.
چگونه جعل IP مشتری در تست های نفوذ شناسایی می شود؟
اکثر تسترهای نفوذ از فایرفاکس برای بررسی های امنیتی خود استفاده می کنند. آنها فایرفاکس را با یک افزونه ساده، X-Forwarded-For: 127.0.0.1 برای همه درخواست های HTTP پیکربندی می کنند. و به این ترتیب، امکان شناسایی چنین آسیب‌پذیری‌هایی در تمامی تست‌های نفوذ افزایش می‌یابد. انجام ممیزی بر اساس چک لیست OWASP تضمین می کند که چنین آسیب پذیری هایی را بررسی می کنید. با این حال، برای شناسایی آسیب‌پذیری X-Forwarded-For، به یک ماژول در برنامه نیاز دارید که آدرس IP شما یا اقدامات انجام شده را نشان دهد.
چگونه آسیب پذیری X-Forwarded-For را حل کنیم
سازمان‌ها برای همه تیم‌های نرم‌افزاری و شرکت‌های برون‌سپاری به یک سند توسعه نرم‌افزار ایمن اجباری نیاز دارند. به عنوان مثال، اگر به یک آدرس IP کاربر نیاز دارید، شرکت باید از قبل برنامه ریزی کند و آن را به عنوان یک قانون در مورد اطلاعات هدر که در اینجا استفاده می کند، قرار دهد. در غیر این صورت، تیم های مختلف راه حل های متفاوتی را ارائه خواهند کرد. اگر با چنین وضعیتی نتوان برخورد کرد، برنامه های کاربردی برون سپاری وارد عمل می شوند و اندازه گیری کدهای منبع را دشوار می کند. به طور کلی شرکت ها نمی خواهند چنین مسیری را طی کنند.
اما برای حل این مشکل می توانید از قانون F5 زیر استفاده کنید:
when HTTP_REQUEST {
HTTP::header remove X-Forwarded-For
HTTP::header insert X-Forwarded-For [IP::remote_addr]
}
این قسمت X-Forwarded-For را در درخواست HTTP از دنیای خارج حذف می کند. سپس با افزودن آدرس IP سیستمی که درخواست را به آن ارسال کرده است، درخواست را ارسال می کند. به این ترتیب، یک لیست قابل اعتماد برای نرم افزارهایی که طبق X-Forwarded-For عمل می کنند، ایجاد می شود.
به طور خلاصه، بزرگترین هدف در اینجا انجام برخی بررسی ها بر روی درخواست های HTTP و ایجاد یک محیط قابل اعتماد است. بلوک کد بالا مثال خوبی است که می توانید برای این کار استفاده کنید.
چارچوب ها و اسناد امنیت سایبری برای شرکت ها
واحدهایی که مستقل از یکدیگر به نظر می رسند در واقع جزئی از یک کل هستند. به همین دلیل است که همه چیز باید به طور سیستماتیک کار کند. قوانین تعیین شده از قبل باید بین هر واحد اعمال شود. اگر چنین سیستم کاری اتخاذ نشود، مشکلات زیادی مانند آسیب‌پذیری X-Forwarded-For ممکن است رخ دهد. برای این کار باید از قبل همه چیز در نظر گرفته شود و از مستندات تا حد امکان جامع استفاده شود.
و هر واحد در این سیستم بزرگ نیاز به اتخاذ و پیاده سازی چارچوب های امنیت سایبری دارد. نقطه شروع شما باید تحقیق و یادگیری منطق کار این چارچوب ها باشد.