ارزیابی پیکربندی پلتفرم اپلیکیشن
در این بخش از دوره آموزشی OWASP-OTG به دومین بخش از استاندارد OTG با شناسه OTG-CONFIG-002 می پردازیم که مربوط به ارزیابی پیکربندی پلتفرم اپلیکیشن می باشد.
خلاصه
پیکربندی درست عناصر سازنده معماری اپلیکیشن، به منظور جلوگیری از اشتباهاتی که امنیت کل معماری را به خطر می‌اندازد، امری ضروری است.
بازبینی پیکربندی و ارزیابی آن در ایجاد و حفظ معماری، یک کار حیاتی است، زیرا تنظیمات پیش‌فرض بسیاری از سیستم‌ها، مناسب کار مد نظر نیستند.
بسیاری از تنظیمات اولیه وب سرور یا اپلیکیشن سرور، قابلیت‌ها و عملکردهای زیادی دارند. اما، آن دسته از موارد غیر ضروری، قبل از نصب و راه‌اندازی سرور، به منظور جلوگیری از اکسپلویت‌های احتمالی بعد نصب، باید حذف شوند.
چگونه تست و ارزیابی کنیم؟
تست جعبه سیاه
دایرکتوری‌ها و فایل‌های نمونه و شناخته شده
بسیاری از وب سرورها و اپلیکیشن سرورها، بعد از نصب اولیه، فایل‌های آماده به منظور تست و ارزیابی اولیه سرور از لحاظ عملکرد آن، در اختیار توسعه‌دهنده می‌گذارد. با این حال، بیشتر اپلیکیشن‌های پیش‌فرض وب سرورها آسیب‌پذیر هستند. از مثال‌های این قبیل می‌توان به CVE-1999-0419 (انکار سرویس در IIS)، CAN-2002-1744 (پیمایش دایرکتوری در IIS 5.0)، CAN-2002-1630 (استفاده از sendmail.jsp در اوراکل) و CAN-2003-1172 (پیمایش دایرکتوری در آپاچی) اشاره کرد.
اسکنرهای CGI حاوی لیستی از فایل‌ها و دایرکتوری‌های وب سرورها و اپلیکیشن سرورهای متعدد هستند. استفاده از آن‌ها می‌تواند شناسایی فایل‌های موجود را تسریع بخشد. با این حال، تنها راه اطمینان کامل، بازبینی کلی و جامع محتوای وب سرور یا اپلیکیشن سرور و تشخیص فایل‌های مرتبط با اپلیکیشن است.
بازبینی کامنت‌ها
بسیاری از برنامه‌نویسان هنگام توسعه اپلیکیشن‌های تحت وب بزرگريال کامنت‌گذاری می‌کنند. با این حال، کامنت‌های داخل کد HTML، ممکن است اطلاعات داخلی که نباید در دسترس نفوذگر باشد را فاش کنند. گاهی اوقات، یک کد منبع، به علت عدم کاربرد آن و غفلت از اینکه اطلاعات صفحات HTML بازگردانده شده به کاربر را به طور ناخواسته فاش کند،کامنت می‌شود.
بازبینی کامنت بایستی به منظور تشخیص اطلاعات فاش شده از طریق کامنت‌ها، انجام گیرد. این کار را می‌توان طریق بررسی محتوای ایستا و پویای وب سرور و جست و جوی فایل‌ها انجام داد. مرور خودکار سایت و ذخیره محتوای به دست آمده از این راه، می‌تواند مفید باشد. این محتوا را بعداً می‌توان به منظور یافتن کامنت‌ها در داخل کد HTML، بررسی کرد.
پیکربندی سیستم
CIS-CAT یک راه ارزیابی سریع و دقیق تطابق سیستم‌های مورد نظر با استانداردهای CIS در اختیار متخصصان فناوری اطلاعات و امنیت گذاشته است. همچنین، CIS توصیه‌های لازم برای برقراری امنیت پیکربندی سیستم‌ها، اهم از پایگاه‌داده، سیستم‌عامل و وب سرور، ارائه داده است.
تست جعبه خاکستری
بازبینی پیکربندی
پیکربندی و تنظیمات وب سرور یا اپلیکیشن سرور نقش مهمی در تامین امنیت محتوای سایت دارد. در نتیجه، باید پیکربندی آن‌ها را به منظور کشف هر گونه خطا و اشتباه تنظیماتی، به دقت بررسی کرد. بدیهی است که پیکربندی، وابسته به سیاست سایت و نوع خدمات ارائه شده توسط نرم‌افزار سرور بوده و متغیر با آن است. در بسیاری از مواقع، باید به راهنما و توصیه‌های ارائه شده توسط فرونشده اصلی یا سایر صاحب نظران را برای اطمینان از پیکربندی صحیح و امنیت سرور، عمل کنیم.
روش جامع و کلی برای پیکربندی سرور وجود ندارد، اما در در پیکربندی آن به نکات زیر توجه کنید:
• تنها ماژول‌های مورد نیاز اپلیکیشن را فعال کنید. این امر نقاط حمله را کاهش می‌دهد، زیرا به علت غیرفعال کردن ماژول‌های بدون کاربرد، حجم و پیچیدگی سرور و اپلیکیشن کم شده و از آسیب‌پذیری‌های مرتبط با آن ماژول‌ها نیز جلوگیری می‌شود.
• خطاهای سرور مانند 40x و 50x را با صفحات سفارشی، به جای استفاده از صفحات پیش‌فرض، مدیریت کنید. مطمئن شوید که هیچ گونه خطای اپلیکیشن به سمت کاربر بازگردانده نشده و کدهای آن‌ها از طریق فاش نمی‌شود. بسیاری از توسعه‌دهندگان این مورد را فراموش می‌کنند، زیرا در مرحله تست و توسعه، قبل از انتشار نهایی محصول، به این اطلاعات نیاز دارند.
• مطمئن شوید که نرم‌افزار سرور با کمترین سطح دسترسی در سیستم‌عامل اجرا می‌شود. انجام این کار باعث می‌شود تا خطای سرور به طور مستقیم سیستم را به خطر نیاندازد، علی‌رغم اینکه یک نفوذگر می‌تواند سطح دسترسی خود را با اجرای کد مخرب همانند کد سرور بالا ببرد.
• از اینکه نرم‌افزار سرور، خطاها و دسترسی‌های قانونی را لاگ می‌کند، اطمینان حاصل نمایید.
• مطمئن شوید که سرور و عملکرد آن به گونه‌ای که بتواند حجم‌های زیاد را مدیریت کرده و از حملات انکار سرویس جلوگیری کند، تنظیم شده باشد.
• هرگز امکان دسترسی خواندن یا نوشتن به applicationHost.config، redirection.config و administration.config را برای هویت‌های غیر از مدیران، فراهم ننماید. NT SERVICE\WMSvc از این مورد مستثنی است. این هویت‌ها شامل مواردی اعم از Network Service، IIS_IUSRS، IUSR و هر گونه هویت سفارشی استفاده شده توسط استخر اپلیکیشن IIS می‌باشد. فرایندهای کارگری IIS نباید دسترسی مستقیم به این فایل‌ها را داشته باشند.
• هرگز applicationHost.config، redirection.config و administration.config را بر روی شبکه به اشتراک نگذارید. اگر قصد استفاده از تنظیمات مشترک دارید، applicationHost.config را به فضای دیگری صادر نمایید.
• توجه داشته باشید که به طور پیش‌فرض، تمامی کاربران می‌توانند فایل‌های machine.config فریم‌ورک دات‌نت و web.config اصلی را بخوانند. بنابراین، هیچ گونه اطلاعات حساس و مدیریتی را در این فایل‌ها ذخیره نکنید.
• اطلاعاتی که به غیر از فرایندهای کارگر IIS، هیچ کاربر دیگری روی ماشین، حق خواندن آن‌ها را ندارند، را رمزگذاری کنید.
• دسترسی نوشتن به هویتی که وب سرور از آن برای دسترسی به applicationHost.config مشترک استفاده می‌کند، ندهید. این هویت باید فقط دسترسی خواندن داشته باشد.
• از یک هویت مجزا برای به اشترک‌گذاری applicationHost.config استفاده کنید. از این هویت برای تنظیم سطح دسترسی به تنظیمات مشترک سرورها استفاده نکنید.
• از یک کلمه عبور قوی موقع صادر کردن کلیدهای رمزنگاری استفاده شده در تنظیمات مشترک، استفاده کنید.
• دسترسی محدود برای فضای اشتراکی حاوی پیکربندی مشترک و کلیدهای رمزنگاری، اعمال و حفظ کنید. اگر این فضای اشتراکی به خطر بیفتد، نفوذگر می‌تواند فایل‌های پیکربندی سرور را خوانده یا تغییر دهد، ترافیک را از به سمت یک منبع مخرب هدایت کند و در بعضی از مواقع، با اجرای کدهایی در فرایندهای کارگر IIS، کنترل سرورها را در دست بگیرد.
• برای محافظت از این فضای اشتراکی و اعطای مجوز برای سرورهای عضو، از قوانین دیوارآتش و سیاست‌های IPsec استفاده کنید.
لاگ‌برداری
لاگ‌برداری یکی از ویژگی‌های امنیتی مهم معماری اپلیکیشن است، زیرا می‌توان از طریق آن آسیب‌پذیری‌ها و نقص‌های اپلیکیشن را پیدا کرده و از حملات نفوذگران ممانعت شود. لاگ‌ها توسط وب سرور و سایر نرم‌افزارهای آن تولید می‌شوند. هدف از لاگ‌های اپلیکیشن، عیب‌یابی خطاها توسط برنامه‌نویس است، اما با این حال، اغلب اپلیکیشن‌ها لاگ‌برداری نمی‌کنند.
در هر دو حالت (لاگ‌های اپلیکیشن و سرور)، موارد زیر باید بررسی و ارزیابی شوند:
- آیا لاگ‌ها حاوی اطلاعات حساس می‌باشند؟
- آیا لاگ‌ها در یک سرور مجزا ذخیره می‌شوند؟
- آیا لاگ‌ها می‌توانند منجر به انکار سرویس بشوند؟
- چگونه روتیت می‌شوند؟ آیا به مدت زمانی ذخیره و نگهداری می‌شوند؟
- چگونه بازبینی می‌شوند؟ آیا مدیران، از طریق بازبینی آن‌ها، می‌توانند حملات را شناسایی کنند؟
- از بک‌آپ لاگ‌ها چگونه محافظت می‌شود؟
- آیا قبل از لاگ‌برداری، اعتبارسنجی داده‌ها صورت می‌پذیرد؟
اطلاعات حساس در لاگ‌ها
احتمالاً بعضی از اپلیکیشن‌ها، به عنوان مثال، از درخواست‌های GET برای ارسال اطلاعات فرم، استفاده کنند. این اطلاعات در لاگ‌ها ذخیره خواهند شد. در نتیجه، اطلاعات حساس اعم از کلمات کاربری، رمزهای عبور و اطلاعات حساب‌های بانکی، در لاگ‌ها قابل مشاهده شد. اگر نفوذگر به لاگ‌ها و در نتیجه اطلاعات حساس، از طریق رابط‌های مدیریتی یا آسیب‌پذیری‌های شناخته شده سرور، دسترسی پیدا کند، می‌تواند از آن‌ها به نفع خود استفاده کند.
لاگ‌های اتفاقات غالباً حاوی اطلاعات مفید برای نفوذگر یا قابل استفاده در اکسپلویت هستند. این اطلاعات شامل موارد زیر هستند:
• اطلاعات عیب‌یابی
• گزارش پشته‌های فعال
• کلمات عبور
• اسامی اجزای سیستم
• آدرس‌های IP داخلی
• اطلاعات شخصی با حساسیت کمتر مانند ایمیل، اطلاعات پستی و شماره تلفن
• داده‌های کسب و کار
همچنین، ذخیره اطلاعات حساس همانند اطلاعات شخصی در فایل‌های لاگ، می‌تواند شرکت را به اعمال قوانین و سیاسیت‌های حفاظت اطلاعات بر لاگ‌ها، همانند پایگاه‌داده‌های بک‌اند، وادار کند. در صورت عدم موفقیت در انجام این امر، متحمل جرایم حقوقی خواهند شد.
لیست کاملی از اطلاعات حساس عبارتند از:
• کد منبع اپلیکیشن
• مقادیر هویتی نشست‌ها
• توکن‌های دسترسی
• داده‌های حساس و اطلاعات شناسایی شخصی
• رمزهای عبور
• رشته‌های اتصالی پایگاه‌داده‌ها
• کلیدهای رمزنگاری
• اطلاعات حساب‌ها و کارت‌های بانکی
• اطلاعات امنیتی که سیستم لاگ‌برداری مجاز به ذخیره آن‌ها نیست
• اطلاعات حساس تجاری
• اطلاعاتی که جمع‌آوری آن‌ها غیر قانونی است
• اطلاعاتی که کاربر از آن‌ها صرف نظر کرده، مجوز استفاده از آن‌ها را نداشته یا منقضی شده است
محل لاگ
معمولاً سرورها از عملیات و خطاهایشان لاگ تولید کرده و فضای دیسک را اشغال می‌کنند. با این حال، اگر سرور در خطر بیفتد، نفوذگر می‌تواند لاگ‌های آن را به منظور پاک کردن رد پای خود و روش‌های حملاتی استفاده شده، محو کند. اگر چنین اتفاقی بیفتد، مدیر سیستم از چگونگی حملات و موقعیت آن‌ها، بی‌خبر خواهد بود. در واقع، بسیاری از جعبه‌ابزارهای نفوذگران ابزارهای پاک‌کننده لاگ‌ها و رد پای نفوذکننده را دارند. از این ابزارها بیشتر در روت‌کیت‌های سطح سیستمی استفاده می‌شود.
بهتر است لاگ‌ها در فضای مجزایی غیر از وب سرور ذخیره شوند. این امر موجب می‌شود تا لاگ‌ها منابع مختلف در یک فضای واحد تجمیع شوند. در نتیجه، بررسی لاگ آسان‌تر شده، مصرف پردازشگر را کاهش داده و تاثیری بر روی سرور گذاشته نمی‌شود.
فضای لاگ
اگر لاگ‌ها به طور صحیح ذخیره نشوند، می‌توانند منجر به انکار سرویس شوند. هر نفوذگری که منابع کافی در دست داشته باشد و از او جلوگیری نشود، می‌تواند با ایجاد درخواست‌های زیاد، فضای اختصاص یافته به فایل‌های لاگ را اشغال کند. اگر پیکربندی و تنظیمات سیستم درست نباشد، فایل‌های لاگ در پارتیشن مورد استفاده سیستم‌عامل یا اپلیکیشن ذخیره می‌شوند و در صورت اشغال شدن کامل آن، سیستم‌عامل یا اپلیکیشن از کار خواهند افتاد، زیرا نخواهند توانست اطلاعات خود را بر روی دیسک بنویسند.
فضای لاگ سیستم‌های یونیکسی معمولاً /var است. البته بعضی از سرورها نیز از /opt یا /usr/local استفاده می‌کنند. دایرکتوی ذخیره لاگ‌ها باید در پارتیشن مجزایی باشند. گاهی اوقات نیز، به منظور جلوگیری از تحت تاثیر قرار گرفتن لاگ‌های سیستمی، دایرکتوری لاگ‌های سیستم، مانند /var/log/apache در آپاچی، نیز باید در پارتیشن اختصاصی قرار بگیرند.
البته این به معنی عدم جلوگیری از اشغال کردن کل فضای سیستم توسط لاگ‌ها نیست. رشد حجم لاگ‌ها باید کنترل شود، زیرا رشد بی‌رویه و ناگهانی آن می‌تواند نشانه‌ای از حملات احتمالی باشد.
تست این مورد نه تنها آسان، بلکه در محیط واقعی، خطرناک نیز است. کافی است چند درخواست به سمت سرور ارسال کرده و لاگ شدن آن‌ها و اشغال احتمالی فضای سرور توسط درخواست‌ها را بررسی کنیم. یک درخواست ساده، که حاوی اطلاعاتی از قبیل تاریخ و ساعت، آدرس IP منبع، درخواست URI و نتایج سرور است، فضای کوچکی را اشغال می‌کند. زمانی که پارامترهای QUERY_STRING لاگ می‌شوند، از کوئری‌های حجیم می‌توان برای اشغال سریع فضای لاگ استفاده کرد.
لاگ روتیشن
بسیاری از سرورها، لاگ‌ها را به منظور جلوگیری از اشغال فضای سیستم، روتیت می‌کنند. هنگام روتیشن، فرض بر این است که اطلاعات موجود در لاگ‌ها برای مدت زمان معلوم و مشخصی کاربرد دارد.
این قابلیت به منظور اطمینان حاصل از موارد زیر، باید مورد ارزیابی قرار بگیرد:
• لاگ‌ها دقیقاً برای مدت زمان مشخص شده در سیاست‌های امنیتی نگهداری می‌شوند.
• موقع روتیشن، لاگ‌ها فشرده‌سازی می‌شوند. این امر موجب می‌شود تا در فضای ثابت، حجم بیشتری از لاگ بتوان ذخیره کرد.
• سطح دسترسی و مجوزهای داده شده برای لاگ‌های روتیت شده، همانند لاگ‌های معمولی یا محدودتر از آن‌ها باشد. به عنوان مثال، وب سرور نیاز به نوشتن بر روی لاگ‌ها روتیت شده را ندارد و می‌توان سطح دسترسی و مجوز آن‌ها را بعد از روتیت کردن، تغییر داد.
دوره آموزشی تست نفوذ وب – SEC542
بعضی از سرورها، لاگ‌ها را با رسیدن به یک حجم مشخص، روتیت می‌کنند. در این صورت، باید از اینکه یک نفوذگر نمی‌تواند با روتیت کردن لاگ‌ها، رد پای خود را پاک کند، اطمینان لازم و کافی حاصل شود.
کنترل دسترسی لاگ
اطلاعات لاگ‌های رخدادها نباید برای کاربران قابل مشاهده باشد. حتی مدیران وب نیز نباید به لاگ‌ها دسترسی داشته باشند، زیرا آن‌ها را از انجام وظایفشان دور می‌کند. مطمئن شوید که طرح کنترل دسترسی اعمال شده برای محافظت از لاگ‌ها و هر گونه اپلیکیشنی که امکان خواندن و جست و جوی لاگ‌ها را می‌دهد، ارتباطی با طرح‌های کنترل دسترسی سایر نقش‌های کاربری اپلیکیشن ندارند.
بازبینی لاگ
هدف از بازبینی لاگ‌ها فراتر از استخراج اطلاعات آماری میزان استفاده از فایل‌های وب سرور (کاری که بیشتر اپلیکیشن‌های مرتبط با لاگ بر روی آن تمرکز دارند) است. همچنین، از طریق بازبینی لاگ‌ها، می‌توان حملات احتمالی انجام شده در مقابل وب سرور را تشخیص داد.
برای شناسایی حملات انجام شده بر روی وب سرور، فایل‌های لاگ خطایی وب سرور باید بررسی شوند. این بررسی باید بر روی نکات زیر تمرکز داشته باشد:
• پیام‌های خطای 40x. مقدار زیاد این پیام‌ها از یک منبع مشخص می‌تواند نشانه‌ای از ابزار اسکنر CGI باشد.
• پیام‌های خطای 50x. این پیام‌ها نشانه‌ای از سوء استفاده یک نفوذگر از قسمت‌هایی از اپلیکیشن است. به عنوان مثال، در مراحل اولیه حملات تزریق SQL، به دلیل ساختار نادرست درخواست‌ها و عدم اجرای صحیح آن‌ها در پایگاه‌داده، پیام‌های 50x تولید می‌شوند.
آمار و نتایج بررسی لاگ‌ها نباید در سروری که لاگ‌ها ساخته می‌شوند، تولید یا ذخیره شوند. در غیر این صورت، یک نفوذگر می‌تواند از طریق آسیب‌پذیری وب سرور یا پیکربندی نادرست، به آن‌ها دسترسی پیدا کرده و اطلاعاتی، مشابه اطلاعات فایل‌های لاگ، کسب کند.
مطالب این بخش توسط جناب آقای امیر ثروتی تهیه شده است.
