هاست‌های اشتراکی

یک چالش رایج در میان برنامه نویسان PHP رسیدن به درصد قابل قبولی از امنیت در هاست‌های اشتراکی است.
تلاش‌هایی برای حل برخی مسائل امنیتی در هاست‌های اشتراکی شده است، اما هیچ کدام از این تلاش‌ها نمی‌توانند باعث شوند که یک هاست اشتراکی همانند یک هاست اختصاصی امن شود.

دو گزینه برای حل مسائل تنظیمات Safe_mode و open_basedir می‌باشند.
تنظیم safe_mode به صورت کارآمد، فایل‌هایی را که یک اسکریپت PHP می تواند بخواند را به فایل‌هایی که اجازه دسترسی همانند اجازه دسترسی اسکریپت PHP دارند، محدود می‌کند. این کار می‌تواند مانع کاربران در پیمایش تمامی فایل‌های سیستم توسط یک اسکریپت PHP شود. اما این کار نمی‌تواند برای کدهایی که بدین منظور توسط زبان های دیگر نوشته شده‌اند کارآیی داشته باشد.

تنظیم open_basedir نیز مشابه safe_mode است غیر از آن که به جای استفاده از حق دسترسی فایل‌ها، محدودیت باز کردن فایل‌ها را به یک پوشه‌ی مشخص اختصاص می‌دهد. بنابراین PHP نمی‌تواند فایل‌هایی که خارج پوشه‌ی تعریف شده در open_basedir وجود دارند را باز کند.

یکی از خاصیت‌های جالب open_basedir این است که می‌توانید از قسمتی از نام‌ها برای تطبیق کردن بیشتر از یک پوشه استفاده نمایید. برای مثال، مقدار /tmp/saheb هر دو پوشه ی /tmp/saheb و /tmp/sahebi را تطبیق می‌کند. اگر می‌خواهید که باز شدن فایل‌ها را فقط به /tmp/saheb محدود کنید، از یک اِسلَش استفاده کنید(/tmp/saheb/) . هر دوی این تنظیمات به دسترسی مدیریتی نیاز دارد. اما یک برنامه نویس می‌تواند این تنظیمات را بازنویسی کند.

هنگام استفاده از میزبان‌های مشترک، مسائل امنیتی مختلفی در این خصوص به وجود می‌آیند. در گذشته PHP توسط safe_mode سعی در حل کردن برخی از این مسائل داشت. اما براساس ساختاری، صحیح نیست که این مشکل را در سطح PHP حل کنیم و safe_mode در PHP6 وجود نخواهد داشت.

البته برخی تنظیمات در php.ini هنوز در محیط های میزبان مشترک اهمیت دارند:
Open_basedir، disable_functions و disable_classes. این تنظیمات به Safe_mode بستگی ندارند و فعلا وجود خواهند داشت.

تنظیم open_basedir قابلیت محدود ساختن فایل هایی که PHP می خواند به یک درخت پوشه های معین ارائه می‌دهد. زمانی که PHP سعی در باز کردن فایلی – مثلا با fopen() یا include – می کند، ابتدا مکان فایل را بررسی می کند. اگر آن فایل در آن درخت پوشه‌ی معین شده توسط base_dir نباشد، فایل باز نمی‌شود. می‌توانید open_basedir را در php.ini تنظیم کنید یا برای هر میزبان مجازی در httpd.conf . در مثال میزبان مجازی httpd.conf زیر، اسکریپت های PHP تنها می توانند فایل های زیر شاخه /home/user/www و /usr/local/lib/php را باز کنند.( دمی اغلب مکان کتابخانه‌ی PEAR است(
<VirtualHost*>
DocumentRoot /home/user/www
ServerName AriaCoders Company ™ | گروه طراحان آریاکدرز
<Directory /home/user/www>
Php_admin_value open_basedir “/home/user/www/:/usr/local/lib/php/”
</Directory>
</VirtualHost>
تنظیمات disable_functions و disable_classes به طرز مشابهی کار می کنند و اجازه می دهند تا بعضی توابع و کلاس های بومی PHP را به دلیل مسائل امنیتی غیر فعال کنید. توابع و کلاس‌هایی که در این تنظیمات مشخص شده اند، برای برنامه های PHP که در آن سیستم اجرا می شوند، قابل استفاده نمی‌باشد. این تنظیمات فقط باید در php.ini تنظیم شوند.
مثال زیر شیوه استفاده از این تنظیمات برای غیرفعال کردن توابع و کلاس ها را نشان می دهد.
;Disable functions
Disable_functions=exec,passthru,shell_exec,system
;Disable classes
Disable_classes=DirectoryIterator,Directory

معایب هاست‌های اشتراکی
اگر سرور شما یک هاست اشتراکی است، بقیه‌ی کاربران یک تهدید محسوب می شوند. حتی اگر به دیگر کاربران اعتماد داشته باشید، به برنامه‌های آنها نمی‌توانید اعتماد کنید. نقاط ضعفی همانند تزریق کد، تمام سرور را تهدید می کند.
بیشتر هکرها معمولا وقتی سایتی آسیب پذیر می‌باشد و امکان اپلود اسکریپت یا همان شِل را برای مهاجم فراهم می‌کند با اجرای اسکریپت خودشان بر روی سرور می‌توانند کل سایت‌های میزبانی شده توسط آن سرور را mass deface کنند.
یک راه حل استفاده از یک سرور اختصاص یافته یا یک سرور خصوصی مجازی VPS ( Virtual Private Server ) می باشد. این سرورها به هر کاربر یک محیط خصوصی ارائه می‌دهند که کاربر کنترل کامل بر آن محیط دارد.

برای مثال یک VPS می تواند به صورتی پیکربندی شود که سرور وب را تحت عنوان صاحب سایت به اجرا در آورد. این کار باعث رسیدن به امنیت و کارآیی بالا می شود. اگر تعداد کمی سایت میزبانی می‌شوند، می‌توان برای هر سایت، یک نمونه‌ی جداگانه از سرور وب اجرا نمود. در این صورت اگر یکی از سرورهای وب مورد حمله قرار گیرد، خود سرور هنوز امن است.( اجرای 20 یا 30 نمونه از سرور وب در یک میزبان مشترک زیاد جالب نیست).
در پایان، زمانی که یک محیط مشترک در نظر می‌گیرید، باید توجه داشته باشید که حتی اگر کد شما 100% امن است، هنوز امن نیستید. حتی اگر محیط شما به گونه‌ای پیکربندی شده است که از دسترسی مستقیم به فایل‌ها توسط برنامه‌های مورد حمله قرار گرفته جلوگیری می‌کند، نمی‌توان گفت که یک مهاجم از شکاف امنیتی برای تهاجم به کل سیستم استفاده نخواهد کرد. در یک محیط اختصاص داده شده که تنها شما در آن اجرا می شود، ریسک به شدت پایین می آید و مدیریت آن آسان‌تر می شود. در کل، اگر داده های حسّاسی دارید، بهتر است از سرورهای اختصاصی استفاده نمایید.

منابع :
Phparchitect’s Guide Security by Ilia Alshanetsky
Zend PHP 5 Certification Study Guide. Davey Shafik with Ben Ramsey
Zend PHP Certification Study Guide