
ارزیابی تنظیمات زیرساخت و شبکه
در این بخش از دوره آموزشی OWASP-OTG به دومین بخش از استاندارد OTG با شناسه OTG-CONFIG-001 می پردازیم که مربوط به ارزیابی تنظیمات زیرساخت و شبکه می باشد.
مقدمه
پیچیدگی ذاتی زیرساختهای متنوع و بهم متصل شده وب سرور، که میتوان شامل صدها اپلیکیشن شود، باعث میشود تا مدیریت پیکربندی و بازبینی آن یک امر اساسی در تست و پیادهسازی هر اپلیکیشن محسوب شود. یک آسیبپذیری به تنهایی میتواند امنیت کل زیرساخت را ضعیف کند. حتی مشکلاتی که به نظر بیاهمیت و کوچک میآیند نیز میتوانند به یک تهدید بزرگ برای اپلیکیشنهای روی وب سرور تبدیل شود. برای حل این مشکلات، بعد از رسم نقشه معماری، بایستی بازبینی جامع از پیکربندی و مسائل امنیتی معلوم، انجام شود.
به منظور حفظ امنیتی اپلیکیشن، پیکربندی درست زیرساخت وب سرور خیلی مهم است. اگر عناصری مانند نرمافزار وب سرور، سرورهای پایگاهداده بکاند یا سرورهای احراز هویت به درستی بازبینی و امن نشوند، میتوانند منجر به خطراتی ناخواسته یا آسیبپذیریهای جدید شده و اپلیکیشن را به خطر بیاندازند.
به عنوان مثال، آسیبپذیری وب سروری که اجازه دسترسی نفوذگر به کدهای منبع اپلیکیشن را میدهد، میتواند اپلیکیشن را به خطر انداخته و کاربران بیهویت با استفاده از اطلاعات فاش شده از این طریق، حملاتی را در مقابل اپلیکیشن یا کابرانش انجام دهند. مراحل زیر بایستی برای تست زیرساخت مدیریت پیکربندی طی شوند:
• اجزاء مختلف زیرساخت باید به منظور کشف چگونگی نحوه ارتباط آن با وب اپلیکیشن و تاثیرش بر امنیت، شناسایی شوند.
• تمامی عناصر زیرساخت باید بازبینی شوند تا از وجود هیچ نوع آسیبپذیری شناخته شده اطمینان حاصل شود.
• ابزارهای مدیریتی که به منظور حفظ عناصر زیرساخت استفاده میشوند، باید بررسی شوند.
• سیستمهای احراز هویت باید به منظور اطمینان حاصل از اینکه به درخواستهای اپلیکیشن پاسخ میدهند و توسط کاربران خارجی امکان دستکاری شدن ندارند، مورد بررسی قرار بگیرند.
• لیستی از پورتهای تعریف شده مورد نیاز اپلیکیشن باید حفظ شده و تحت کنترل کنترل باشند.
بعد از رسم نقشه عناصر مختلف شکلدهنده زیرساخت، میتوان پیکربندی عناصر یافت شده را برای کشف آسیبپذیری، بازبینی و ارزیابی کرد.
اهداف تست
رسم نقشه زیرساخت اپلیکیشن و درک نحوه و چگونگی تاثیر آن بر امنیت اپلیکیشن
چگونه تست و ارزیابی کنیم؟
آسیبپذیریهای سرور شناخته شده
آسیبپذیریهای یافت شده در قسمتهای مختلف اپلیکیشن، خواه در وب سرور یا پایگاهداده، میتوانند امنیت آن را به خطر بیاندازند. به عنوان مثال، آسیبپذیری سروری را در نظر بگیرید که به یک کاربر از راه دور و احراز هویت نشده، اجازه بارگذاری فایل به وب سرور و حتی تغییر آن را بدهد.
این آسیبپذیری امنیتی اپلیکیشن را تهدید میکند، زیرا یک کاربر زیرک میتواند اپلیکیشن را تغییرا داده یا کدهای جدیدی بارگذاری کند. از آنجایی که کدهای او همانند سایر کدهای اپلیکیشن اجرا خواهند شد، میتواند سرورهای بکاند را تحت تاثیر قرار داده و دستکاری کند.
اگر قصد انجام تست نفوذ کور دارید، بازبینی آسیبپذیریهای سرور کار سخت و دشواری خواهد بود. در این موارد، آسیبپذیریها را باید از طریق یک سایت خارجی و غالباً توسط ابزار خودکار، ارزیابی کرد. با این حال، تست بعضی از آسیبپذیریها نتایج پیشبینی نشدهای را به همراه خواهند داشت. احتمالاً تست سایر آسیبپذیریها (همانند آسیبپذیریهای مرتبط با انکار سرویس) به دلیل مسائلی مانند از کار افتادگی سرور، ممکن نباشد
بعضی از ابزارهای خودکار، آسیبپذیریها را بر اساس نسخه وب سرور مشخص میکنند. این امر نتایج مثبت کاذب و منفی کاذب به همراه خواهد داشت. از یک سو، اگر نسخه وب سرور توسط مدیر حذف یا مخفی شده باشد، ابزار اسکن آسیبپذیری را، حتی در صورت وجود آن، شناسایی نخواهد کرد.
از سوی دیگر، اگر مالک نرمافزار بعد از رفع آسیبپذیریها، آن را به روز رسانی نکند، ابزار اسکن آسیبپذیریهایی را شناسایی خواهد کرد که وجود خارجی ندارند. سناریو دوم بیشتر رایج است، زیرا بعضی از فروشندگان سیستمعامل، وصلههای امنیتی را به نرمافزار ارائه شده در سیستمعامل پیشانتقال کرده و نرمافزار را به آخرین نسخه موجود به روز رسانی نمیکنند.
این حالت بیشتر در توزیعهای لینوکسی مانند Debian، Red Hat و SuSe اتفاق میافتد. در بیشتر موارد، اسکن آسیبپذیریهای اپلیکیشن تنها آسیبپذیریهای عناصر درگیر مستقیم مانند وب سرور را شناسایی کرده و آسیبپذیریهای عناصر درگیر غیرمستقیم مانند سرورهای احراز هویت، پایگاهداده بکاند و پراکسیهای معکوس را پیدا نخواهد کرد.
همه صاحبان نرمافزار، آسیبپذیریها را برای عموم مردم فاش نمیکنند. به همین علت است که آسیبپذیریها در پایگاهدادههای عمومی شناخته شده، ثبت نمیشوند. اطلاعات آسیبپذیریها فقط در اختیار مشتریان قرار داده شده یا از در قالب رفع باگهایی که توضیح اضافی ندارند، منتشر میشوند.
این امر، کاربرد و کارایی ابزارهای اسکن آسیبپذیری را کم میکند. البته، این ابزارها بیشتر آسیبپذیریهای محصولات معروف مانند وب سرور آپاچی، IIS مایکروسافت و IBM Lotus Domino را پوشش میدهند، اما در اسکن سایر محصولات که شهرت چندانی ندارند، کاربرد چندانی ندارند.
به این دلیل، بهترین تست و بازبینی زمانی اتفاق میافتد که ارزیاب امنیتی اطلاعاتی از نرمافزار استفاده شده مانند نسخه و وصلههای اعمال شده داشته باشد. با داشتن این اطلاعات، ارزیاب امنیتی میتواند مستقیماً از فروشنده نرمافزار، نسخهای از آن را تهیه کرده و آسیبپذیریهای آن را به منظور کشف نحوه تاثیر آن بر امنیت اپلیکیشن، بررسی کند.
در صورت امکان، برای تشخیص اثر واقعی آسیبپذیریها و کشف عناصر خارجی دفاعی در برابر حملات مانند سیستمهای تشخیص و جلوگیری از نفوذ، آسیبپذیریها در محیط واقعی تست شوند. ارزیابان امنیتی حتی از طریق بازبینی پیکربندی نیز بعضی از آسیبپذیریها را تشخیص نمیدهند، زیرا آن آسیبپذیریها مربوط به عناصر بدون کاربرد اپلیکیشن هستند.
لازم به ذکر است که گاهی اوقات فروشندگان نرمافزار، ایرادات امنیتی را به طور مخفیانه حل کرده و در نسخههای به روزتر آنها را اعمال میکنند. فروشندگان مختلف چرخه و روندهای به روز رسانی متفاوتی خواهند داشت. این چرخهها نحوه پشتیبانی آنها از نسخههای قدیمیتر را نشان میدهد.
ارزیاب امنیتی با در دست داشتن اطلاعات جزئی و دقیق نسخه نرمافزار استفاده شده توسط معماران زیرساختی و شبکهای، میتواند خطرات مرتبط با نسخههای قدیمیتر پشتیبانی نشده توسط معماران را ارزیابی کند. توجه کافی به این امر حیاتی داشته باشید، چرا که اگر در یک نرمافزار قدیمی پشتیبانی نشده آسیبپذیری وجود داشته باشد، احتمالاً مدیران و پرسنل سیستمها از وجود آن بیخبر باشند.
امکان دارد هیچ گونه وصله امنیتی برای آنها در نظر گرفته نشده باشند و مشاوران، به دلیل اینکه این نسخه از نرمافزارها دیگر پشتیبانی نمیشوند، در لیست نسخههای آسیبپذیر آنها را ذکر نکنند. در صورتی که از وجود آسیبپذیری باخبر باشند، باید در طی یک به روز رسانی کامل، سیستم را به آخرین نسخه ارتقا دهند. البته عواقبی مانند از کار افتادگی سیستم یا ناسازگاری کدهای قدیمی با نسخه جدید را باید قبل از انجام به روز رسانی در نظر گرفت.
ابزارهای مدیریتی
هر زیرساخت وب سروری برای حفظ و به روز رسانی اطلاعات استفاده شده توسط اپلیکیشن، به ابزارهای مدیریتی نیاز دارد. این اطلاعات شامل محتوای ایستا (صفحات وب و فایلهای گرافیکی)، کدهای اپلیکیشن، پایگاهدادههای احراز هویت کاربران و … میباشد.
ابزارهای مدیریتی بر حسب سایت، فنآوری یا نرمافزار استفاده شده، متفاوت خواهند بود. به عنوان مثال، بعضی از وب سرورها از طریق رابطهای مدیریتی که خودشان نیز مانند iPlanet وب سرور هستند، مدیریت میشوند. از انواع دیگر ابزارها میتوان به فایلهای متنی مدیریتی در وب سرور آپاچی و ابزارهای گرافیکی مدیریتی تحت سیستمعامل در IIS مایکروسافت اشاره کرد.
آشنایی با جمع آوری اطلاعات در وب
در بسیاری از مواقع، پیکربندی سرور از طریق ابزارهای گوناگون استفاده شده توسط وب سرور، اداره میشوند. این ابزارها توسط سرورهای FTP، WebDAV، فایلسیستمهای شبکه (NFS و CIFS) و سایر مکانیزمها، مدیریت میشوند. واضح است که سیستمعاملهای عناصر شکلدهنده معماری اپلیکیشن نیز توسط ابزارهای دیگری مدیریت خواهند شد. ممکن است اپلیکیشنها در داخل خودشان رابطهای مدیریتی برای مدیریت اطلاعات اپلیکیشن مانند کاربران و محتوا، داشته باشند.
بعد نگاشت و رسم نقشه رابطهای مدیریتی استفاده شده برای مدیریت بخشهای مختلف معماری، ضروری است که یک بازبینی از آنها انجام دهیم، زیرا اگر یک نفوذگر به هر کدام از آنها دسترسی پیدا کند، میتواند معماری اپلیکیشن را به خطر انداخته یا از بین ببرد. برای همین منظور، انجام اقدامات زیر ضروری است:
• مکانیزمهایی که دسترسی به این رابطها و نقاط حساسشان را کنترل میکنند، شناسایی شوند. ممکن است این اطلاعات به صورت آنلاین موجود باشند.
• نام کاربری و رمز عبور پیشفرض عوض شوند.
بعضی از شرکتها خودشان همه بخشهای اپلیکیشنهای وب سرور را مدیریت نمیکنند، بلکه از شرکتهای ثالث برای مدیریت محتوای وب اپلیکیشن استفاده میکنند. شرکتهای ثالث، با توجه به فرایند کاری و سیاست خودشان، میتوانند بخشی از محتوا یا کل وب سرور را مدیریت کنند.
در چنین شرایطی، استفاده از رابطهای موجود در اینترنت سادهترین، و در مقایسه با اختصاص خط اختصاصی بین شرکت ثالث و زیرساخت اپلیکیشن، ارزانترین راه است. توجه داشته باشید که تست آسیبپذیریهای این رابطهای مدیریتی نیز مهم و ضروری است.
مطالب این بخش توسط جناب آقای امیر ثروتی تهیه شده است.