امنیت PHP چیست؟ مهم‌ترین تنظیمات php.ini برای افزایش امنیت سایت

امنیت PHP به مجموعه اقداماتی گفته می‌شود که برای محافظت از کدهای PHP، اطلاعات کاربران، فایل‌های سرور و عملکرد برنامه‌های تحت وب انجام می‌شوند. یکی از مهم‌ترین روش‌های افزایش امنیت PHP، تنظیم صحیح فایل php.ini است؛ زیرا این فایل رفتار PHP را در زمینه نمایش خطاها، دسترسی به فایل‌ها، آپلود اطلاعات، مدیریت نشست کاربران و مصرف منابع سرور کنترل می‌کند.

اگر وب‌سایت شما با وردپرس، ووکامرس، لاراول یا هر سیستم مبتنی بر PHP ساخته شده است، پیکربندی نادرست PHP می‌تواند خطر افشای اطلاعات حساس، اجرای کدهای ناخواسته، سوءاستفاده از قابلیت‌های آپلود و اختلال در عملکرد سایت را افزایش دهد.

بسیاری از مدیران سایت تصور می‌کنند نصب گواهی SSL، فعال‌کردن فایروال یا استفاده از افزونه‌های امنیتی برای محافظت کامل از وب‌سایت کافی است. درحالی‌که امنیت واقعی به تنظیمات لایه‌های مختلف زیرساخت نیز وابسته است و PHP یکی از مهم‌ترین این لایه‌ها محسوب می‌شود.

فایل php.ini امکان مدیریت ده‌ها تنظیم مهم را فراهم می‌کند؛ اما تغییر تمام گزینه‌ها به حالت محدودکننده، لزوماً امنیت بیشتری ایجاد نمی‌کند. برخی تنظیمات در صورت انتخاب نادرست می‌توانند باعث اختلال در وردپرس، افزونه‌ها، پردازش فایل‌ها یا ارتباط با سرویس‌های خارجی شوند.

در این راهنمای جامع از رخنه‌کاو، بررسی می‌کنیم امنیت PHP چیست، فایل php.ini چه نقشی در محافظت از وب‌سایت دارد، کدام تنظیمات امنیتی ضروری هستند و چگونه می‌توان بدون ایجاد اختلال در عملکرد سایت، پیکربندی PHP را ایمن‌تر کرد.

امنیت PHP چیست و چرا اهمیت دارد؟

PHP یک زبان برنامه‌نویسی سمت سرور است که برای توسعه وب‌سایت‌ها، سیستم‌های مدیریت محتوا، فروشگاه‌های اینترنتی و برنامه‌های تحت وب استفاده می‌شود.

برخلاف JavaScript که معمولاً بخشی از آن در مرورگر کاربر اجرا می‌شود، کدهای PHP در محیط سرور پردازش می‌شوند. نتیجه اجرای این کدها می‌تواند به‌صورت HTML، JSON یا سایر قالب‌های پاسخ به مرورگر ارسال شود.

این ویژگی باعث می‌شود PHP به اطلاعات و منابع مهمی دسترسی داشته باشد؛ از جمله پایگاه داده، فایل‌های برنامه، تنظیمات سایت و اطلاعات موردنیاز برای پردازش درخواست کاربران.

بنابراین، اگر یک برنامه PHP آسیب‌پذیر باشد یا محیط اجرای آن به‌درستی محدود نشده باشد، احتمال دسترسی غیرمجاز به منابع سرور افزایش پیدا می‌کند.

امنیت PHP فقط به کدنویسی مربوط نیست

امنیت برنامه‌های PHP را می‌توان در چند سطح بررسی کرد.

اولین سطح، امنیت کدنویسی است. در این بخش باید ورودی‌های کاربران اعتبارسنجی شوند، دسترسی‌ها کنترل شوند و داده‌ها به‌صورت امن پردازش شوند.

دومین سطح، امنیت محیط اجرای PHP است. تنظیمات php.ini، سطح دسترسی فرایندها، محدودیت منابع و امکانات PHP-FPM در این گروه قرار می‌گیرند.

سطح سوم، امنیت زیرساخت است که شامل سیستم‌عامل، وب‌سرور، پایگاه داده، فایروال و شبکه می‌شود.

برای دستیابی به امنیت مناسب، هر سه سطح باید در کنار یکدیگر مدیریت شوند.

چه سایت‌هایی به تنظیمات امنیتی PHP نیاز دارند؟

تقریباً تمام وب‌سایت‌هایی که PHP را برای پردازش درخواست‌های کاربران اجرا می‌کنند، باید تنظیمات آن را بررسی کنند.

این موضوع به‌ویژه برای سایت‌های زیر اهمیت دارد:

• فروشگاه‌های اینترنتی مبتنی بر ووکامرس
• وب‌سایت‌های وردپرسی با افزونه‌های متعدد
• سامانه‌های دارای حساب کاربری
• سایت‌های دارای فرم آپلود فایل
• برنامه‌های تحت وب با اطلاعات محرمانه
• سیستم‌های مالی و پنل‌های مدیریتی
• سرورهای اشتراکی دارای چند وب‌سایت
• برنامه‌هایی که به APIهای خارجی متصل می‌شوند

میزان سخت‌گیری تنظیمات باید متناسب با نوع سایت، نیازهای عملیاتی و سطح حساسیت اطلاعات تعیین شود.

مهم‌ترین تهدیدات امنیتی در برنامه‌های PHP

برای تنظیم صحیح php.ini، ابتدا باید بدانیم چه تهدیداتی می‌توانند برنامه‌های PHP را هدف قرار دهند.

آسیب‌پذیری اجرای کد از راه دور

اجرای کد از راه دور یا Remote Code Execution که با نام RCE شناخته می‌شود، یکی از خطرناک‌ترین انواع آسیب‌پذیری‌های برنامه‌های تحت وب است.

در چنین شرایطی، یک ضعف امنیتی ممکن است امکان اجرای دستورها یا کدهای ناخواسته را در محیط سرور فراهم کند.

پیکربندی PHP می‌تواند در بعضی سناریوها دامنه تأثیر این آسیب‌پذیری را کاهش دهد؛ اما تنظیمات php.ini به‌تنهایی نمی‌توانند مانع تمام انواع RCE شوند.

مهم‌ترین اقدامات پیشگیرانه شامل به‌روزرسانی نرم‌افزارها، اعتبارسنجی ورودی، مدیریت وابستگی‌ها و اجرای برنامه با حداقل سطح دسترسی است.

آسیب‌پذیری File Inclusion

آسیب‌پذیری File Inclusion زمانی رخ می‌دهد که برنامه مسیر فایل‌های مورد استفاده را به‌صورت ناامن مدیریت کند.

دو اصطلاح رایج در این حوزه عبارت‌اند از:

• Local File Inclusion یا LFI: استفاده ناامن از فایل‌های محلی
• Remote File Inclusion یا RFI: بارگذاری یا اجرای ناامن محتوای فایل از منابع خارجی

بعضی تنظیمات PHP مانند open_basedir و allow_url_include می‌توانند به محدودسازی برخی سناریوهای مرتبط کمک کنند.

بااین‌حال، مهم‌ترین راهکار همچنان طراحی امن برنامه و جلوگیری از انتخاب مسیر فایل براساس ورودی کنترل‌نشده کاربر است.

آپلود فایل‌های مخرب

فرایند آپلود فایل یکی از بخش‌های حساس سایت‌های PHP محسوب می‌شود.

اگر یک برنامه بدون اعتبارسنجی مناسب، فایل‌های کاربران را دریافت و در مسیر قابل اجرا ذخیره کند، احتمال سوءاستفاده افزایش پیدا می‌کند.

تنظیمات php.ini امکان محدودسازی اندازه و تعداد فایل‌های آپلودی را فراهم می‌کنند.

اما تشخیص نوع واقعی فایل، بررسی محتوای آن و جلوگیری از اجرای فایل‌های آپلودشده باید در سطح برنامه و وب‌سرور نیز انجام شود.

افشای اطلاعات از طریق پیام‌های خطا

پیام‌های خطای PHP ممکن است شامل مسیر فایل‌ها، نام کلاس‌ها، اطلاعات مربوط به برنامه یا جزئیات فنی باشند.

نمایش این اطلاعات در محیط عملیاتی می‌تواند شناخت بیشتری از ساختار برنامه در اختیار افراد غیرمجاز قرار دهد.

به همین دلیل، غیرفعال‌کردن نمایش عمومی خطاها و فعال‌سازی ثبت امن رویدادها از مهم‌ترین اقدامات امنیت PHP محسوب می‌شود.

حملات مرتبط با نشست کاربران

نشست یا Session برای نگهداری وضعیت کاربر میان درخواست‌ها استفاده می‌شود.

در برنامه‌هایی که از نشست‌های داخلی PHP استفاده می‌کنند، تنظیمات نامناسب کوکی‌ها یا شناسه نشست ممکن است خطر سرقت نشست و Session Fixation را افزایش دهند.

امن‌سازی نشست‌ها باید همراه با استفاده از HTTPS، کنترل دسترسی و مدیریت صحیح احراز هویت انجام شود.

فایل php.ini چیست و چه کاربردی دارد؟

فایل php.ini یکی از فایل‌های اصلی پیکربندی PHP است که تنظیمات محیط اجرای این زبان را مشخص می‌کند.

بسته به نوع نصب و معماری سرور، این فایل می‌تواند بر مواردی مانند مدیریت خطاها، محدودیت حافظه، قابلیت آپلود، رفتار نشست‌ها و برخی امکانات دسترسی تأثیر بگذارد.

هر تنظیم در php.ini معمولاً با یک نام و مقدار مشخص تعریف می‌شود.

برای مثال:

display_errors = Off

این تنظیم نمایش خطاهای PHP در خروجی برنامه را غیرفعال می‌کند.

نمونه دیگر:

memory_limit = 256M

این مقدار محدودیت حافظه یک اجرای PHP را مشخص می‌کند.

البته همه گزینه‌ها را نمی‌توان از هر محلی تغییر داد و بعضی تنظیمات فقط در سطح پیکربندی اصلی یا سرویس قابل تعریف هستند.

آیا تمام تنظیمات php.ini امنیتی هستند؟

خیر. فایل php.ini شامل تنظیمات امنیتی، عملکردی، سازگاری و عملیاتی است.

برای مثال، display_errors مستقیماً با افشای اطلاعات ارتباط دارد؛ اما memory_limit بیشتر برای کنترل مصرف منابع استفاده می‌شود.

همچنین upload_max_filesize سقف اندازه فایل‌های آپلودشده را تعیین می‌کند، ولی نمی‌تواند مخرب یا سالم‌بودن محتوا را تشخیص دهد.

در نتیجه، باید هر گزینه براساس نقش واقعی آن بررسی شود.

فایل php.ini در سرور کجا قرار دارد؟

محل فایل php.ini به سیستم‌عامل، نسخه PHP و روش اجرای آن بستگی دارد.

در بسیاری از سرورهای لینوکسی، PHP از طریق PHP-FPM اجرا می‌شود؛ اما بعضی سرورها از Apache Module یا سایر روش‌ها استفاده می‌کنند.

پیدا کردن php.ini در Ubuntu و Debian

در نصب‌های رایج Ubuntu و Debian ممکن است مسیر پیکربندی PHP-FPM به شکل زیر باشد:

/etc/php/8.4/fpm/php.ini

این مسیر فقط یک نمونه است و شماره نسخه باید با نسخه نصب‌شده جایگزین شود.

برای محیط خط فرمان یا CLI نیز ممکن است فایل جداگانه‌ای وجود داشته باشد:

/etc/php/8.4/cli/php.ini

نکته مهم این است که تنظیمات PHP خط فرمان الزاماً همان تنظیمات مورد استفاده وب‌سایت نیستند.

پیدا کردن فایل با php --ini

یکی از روش‌های بررسی پیکربندی، استفاده از دستور زیر است:

php --ini

این دستور فایل پیکربندی بارگذاری‌شده و برخی فایل‌های تنظیمات تکمیلی را برای PHP خط فرمان نمایش می‌دهد.

بااین‌حال، چون PHP وب‌سایت ممکن است از سرویس متفاوتی استفاده کند، خروجی این دستور را نباید بدون بررسی، معادل پیکربندی وب‌سرور دانست.

استفاده از phpinfo برای شناسایی تنظیمات

تابع phpinfo() می‌تواند اطلاعات گسترده‌ای درباره محیط PHP نمایش دهد.

این اطلاعات شامل نسخه PHP، افزونه‌های فعال، تنظیمات و مسیر فایل‌های پیکربندی است.

به دلیل حساسیت این اطلاعات، نباید صفحه phpinfo را به‌صورت عمومی در دسترس اینترنت قرار داد.

اگر برای عیب‌یابی از آن استفاده می‌شود، بهتر است در محیط کنترل‌شده و با دسترسی محدود باشد و پس از پایان بررسی حذف شود.

تفاوت php.ini و .user.ini

در بعضی سرویس‌های CGI و FastCGI، فایل .user.ini امکان اعمال بخشی از تنظیمات را در سطح مسیرهای مشخص فراهم می‌کند.

این فایل نمی‌تواند تمام گزینه‌های موجود در php.ini را تغییر دهد.

برای مثال، بعضی تنظیمات فقط در سطح سیستم یا پیکربندی اصلی PHP قابل تعریف هستند.

همچنین تغییرات .user.ini ممکن است به دلیل سازوکار کش تنظیمات، بلافاصله اعمال نشوند.

در هاست‌های اشتراکی، پنل مدیریت هاست نیز ممکن است رابطی برای تغییر بخشی از این تنظیمات فراهم کند.

قبل از تغییر تنظیمات امنیتی PHP چه کارهایی انجام دهیم؟

تغییر مستقیم تنظیمات PHP روی سایت عملیاتی، بدون شناخت وابستگی‌ها، می‌تواند باعث بروز خطا شود.

به همین دلیل بهتر است قبل از اعمال تغییرات، وضعیت فعلی ثبت و برنامه بازگشت مشخص شود.

بررسی نسخه PHP

ابتدا نسخه PHP مورد استفاده سایت را شناسایی کنید.

برای PHP خط فرمان می‌توان از دستور زیر استفاده کرد:

php -v

اما نسخه CLI ممکن است با نسخه PHP-FPM متفاوت باشد.

در وردپرس نیز بخش سلامت سایت یا اطلاعات سرور می‌تواند در تشخیص نسخه مورد استفاده وب‌سایت کمک کند.

تهیه نسخه پشتیبان از تنظیمات

پیش از ویرایش php.ini، نسخه‌ای از فایل فعلی تهیه کنید.

بهتر است مسیر فایل، تاریخ تغییر و تنظیماتی که قرار است اصلاح شوند مستند شوند.

در سرورهای حساس، نگهداری نسخه‌های پیکربندی در سامانه مدیریت تغییرات می‌تواند مفید باشد.

بررسی سازگاری افزونه‌ها

بعضی افزونه‌های وردپرس برای انجام وظایف خود به قابلیت‌هایی مانند آپلود فایل، پردازش تصویر، درخواست HTTP یا اجرای ابزارهای کمکی نیاز دارند.

غیرفعال‌کردن گسترده توابع و امکانات PHP ممکن است عملکرد این افزونه‌ها را مختل کند.

بنابراین تنظیمات باید ابتدا در محیط آزمایشی بررسی شوند.

مهم‌ترین تنظیمات امنیتی php.ini

تنظیمات امنیتی PHP را می‌توان به چند گروه تقسیم کرد: جلوگیری از افشای اطلاعات، محدودسازی قابلیت‌های حساس، مدیریت فایل‌ها، محافظت از نشست‌ها و کنترل منابع.

در ادامه مهم‌ترین گزینه‌ها را به‌صورت جداگانه بررسی می‌کنیم.

غیرفعال‌کردن نمایش خطاها با display_errors

یکی از مهم‌ترین تنظیمات امنیت PHP، گزینه display_errors است.

این گزینه مشخص می‌کند خطاهای PHP در خروجی برنامه نمایش داده شوند یا خیر.

چرا نمایش خطاها خطرناک است؟

در محیط توسعه، نمایش خطاها برای شناسایی مشکلات کدنویسی کاربرد دارد.

اما در محیط عملیاتی، پیام‌های خطا ممکن است مسیر فایل‌ها، نام کتابخانه‌ها، اطلاعات مربوط به ساختار برنامه یا جزئیات دیگری را افشا کنند.

برای مثال، نمایش مسیر یک فایل داخلی می‌تواند اطلاعات غیرضروری درباره ساختار سرور آشکار کند.

به همین دلیل توصیه می‌شود نمایش خطاها در سایت اصلی غیرفعال باشد.

تنظیم پیشنهادی:

display_errors = Off

غیرفعال‌کردن خطاهای زمان راه‌اندازی

گزینه display_startup_errors نمایش خطاهای مربوط به راه‌اندازی PHP را کنترل می‌کند.

برای محیط عملیاتی:

display_startup_errors = Off

این تنظیم نباید با غیرفعال‌کردن ثبت خطاها اشتباه گرفته شود.

هدف آن جلوگیری از نمایش عمومی جزئیات فنی است، نه پنهان‌کردن مشکلات از مدیر سرور.

آیا غیرفعال‌کردن نمایش خطاها مشکل را حل می‌کند؟

خیر. اگر برنامه دارای خطای فنی باشد، غیرفعال‌کردن display_errors آن خطا را برطرف نمی‌کند.

این گزینه فقط نحوه نمایش پیام‌های خطا را تغییر می‌دهد.

به همین دلیل باید هم‌زمان سیستم ثبت لاگ فعال باشد تا خطاها قابل شناسایی و اصلاح باشند.

فعال‌کردن ثبت امن خطاها با log_errors

گزینه log_errors امکان ثبت پیام‌های خطای PHP را فراهم می‌کند.

در محیط عملیاتی، ثبت خطاها معمولاً گزینه مناسب‌تری نسبت به نمایش آن‌ها به کاربران است.

تنظیم پیشنهادی:

log_errors = On

تعیین سطح ثبت خطا با error_reporting

گزینه error_reporting تعیین می‌کند کدام دسته از خطاها و هشدارهای PHP گزارش شوند.

برای دریافت اطلاعات کامل‌تر در محیط مدیریتی، می‌توان از مقدار زیر استفاده کرد:

error_reporting = E_ALL

فعال‌بودن این گزینه به معنای نمایش خطاها در سایت نیست؛ زیرا display_errors به‌صورت مستقل کنترل می‌شود.

ثبت کامل خطاها به شناسایی ناسازگاری افزونه‌ها، مشکلات نسخه PHP و ایرادهای برنامه کمک می‌کند.

تنظیم مسیر error_log

گزینه error_log امکان تعیین مقصد ثبت خطا را فراهم می‌کند.

برای مثال:

error_log = /var/log/php/site-error.log

این مسیر باید متناسب با سیستم واقعی انتخاب شود.

فایل لاگ باید برای فرایند مربوط قابل نوشتن باشد و در عین حال دسترسی عمومی به آن محدود شود.

قرارگرفتن فایل‌های لاگ در مسیر عمومی وب‌سایت می‌تواند خطر افشای اطلاعات ایجاد کند.

جلوگیری از ثبت اطلاعات حساس در لاگ‌ها

ثبت خطاها نیز نیازمند ملاحظات امنیتی است.

گاهی پیام‌های خطا ممکن است اطلاعات ورودی کاربران، مسیرهای داخلی یا داده‌های حساس را شامل شوند.

به همین دلیل بهتر است دسترسی به لاگ‌ها محدود باشد، دوره نگهداری مشخص شود و اطلاعات محرمانه در پیام‌های خطای برنامه ثبت نشوند.

برای سرورهای پرترافیک نیز باید از انباشته‌شدن کنترل‌نشده فایل‌های لاگ جلوگیری کرد.

جلوگیری از نمایش نسخه PHP با expose_php

گزینه expose_php مشخص می‌کند PHP اطلاعات شناسایی خود را در برخی پاسخ‌های HTTP منتشر کند یا خیر.

در بعضی پیکربندی‌ها، فعال‌بودن این گزینه باعث نمایش هدر X-Powered-By می‌شود.

تنظیم پیشنهادی:

expose_php = Off

چرا پنهان‌کردن نسخه PHP مفید است؟

انتشار جزئیات غیرضروری درباره فناوری سرور می‌تواند به شناسایی زیرساخت کمک کند.

غیرفعال‌کردن این گزینه نوعی کاهش افشای اطلاعات است.

بااین‌حال، نباید آن را یک مانع امنیتی قدرتمند تصور کرد؛ زیرا فناوری و نسخه نرم‌افزارها ممکن است از مسیرهای دیگری قابل شناسایی باشند.

مهم‌ترین اقدام، استفاده از نسخه‌های پشتیبانی‌شده و نصب به‌روزرسانی‌های امنیتی است.

مدیریت قابلیت‌های حساس با disable_functions

گزینه disable_functions امکان غیرفعال‌کردن برخی توابع داخلی PHP را فراهم می‌کند.

بعضی مدیران سرور از این قابلیت برای محدودسازی توابعی استفاده می‌کنند که برنامه‌هایشان به آن‌ها نیازی ندارند.

کدام توابع ممکن است حساس باشند؟

توابعی مانند موارد زیر در بعضی سناریوها امکان تعامل با فرایندها یا اجرای برنامه‌های خارجی را فراهم می‌کنند:

• exec
• shell_exec
• system
• passthru
• proc_open
• popen

وجود این توابع به‌خودی‌خود آسیب‌پذیری نیست.

خطر زمانی ایجاد می‌شود که یک برنامه آسیب‌پذیر، ورودی غیرقابل اعتماد را به شکلی ناامن به عملیات حساس منتقل کند.

آیا باید همه این توابع غیرفعال شوند؟

خیر. غیرفعال‌کردن گسترده توابع PHP برای همه سایت‌ها توصیه نمی‌شود.

بعضی برنامه‌ها و ابزارهای مدیریتی ممکن است برای عملیات معتبر خود به این قابلیت‌ها نیاز داشته باشند.

برای مثال، سیستم پردازش ویدئو، تولید فایل یا اجرای برنامه‌های کمکی ممکن است از توابع مرتبط استفاده کند.

بنابراین باید وابستگی‌های واقعی برنامه مشخص شوند.

اگر پس از بررسی ثابت شود یک تابع برای برنامه ضروری نیست، می‌توان غیرفعال‌کردن آن را به‌عنوان یک اقدام تکمیلی بررسی کرد.

محدودیت امنیتی disable_functions

نکته بسیار مهم این است که disable_functions یک محیط ایزوله یا Sandbox کامل ایجاد نمی‌کند.

این قابلیت جایگزین محدودسازی مجوزهای سیستم‌عامل، اجرای فرایندها با کاربر مستقل یا کنترل دسترسی به منابع نیست.

حتی در مستندات PHP نیز تأکید شده است که این مکانیزم نباید به‌تنهایی به‌عنوان حفاظت کافی در محیط‌های میزبانی اشتراکی در نظر گرفته شود.

در نتیجه، استفاده از disable_functions باید بخشی از یک راهبرد دفاع چندلایه باشد.

محدودسازی دسترسی به فایل‌ها با open_basedir

گزینه open_basedir برای محدودکردن دسترسی برخی عملیات فایل PHP به مسیرهای مشخص استفاده می‌شود.

این قابلیت می‌تواند از دسترسی اتفاقی یا ناخواسته برنامه به بعضی مسیرهای خارج از محدوده تعریف‌شده جلوگیری کند.

open_basedir چگونه کار می‌کند؟

فرض کنید برنامه PHP در مسیر مشخصی قرار دارد.

با تعریف محدودیت مناسب، می‌توان تعیین کرد عملیات فایل PHP فقط در مسیرهای مجاز انجام شوند.

برای مثال، یک الگوی فرضی می‌تواند شامل مسیر برنامه و پوشه موقت اختصاصی آن باشد:

open_basedir = /var/www/example.com:/var/tmp/example.com

این مسیرها صرفاً نمونه هستند.

برای استفاده واقعی باید تمام مسیرهای موردنیاز برنامه، کتابخانه‌ها، فایل‌های موقت، نشست‌ها و عملیات نگهداری مشخص شوند.

آیا open_basedir مانع نفوذ می‌شود؟

خیر. open_basedir یک کنترل تکمیلی است و نباید به‌عنوان مرز امنیتی کامل در نظر گرفته شود.

این قابلیت تمام روش‌های دسترسی به منابع سیستم‌عامل را محدود نمی‌کند.

برای مثال، محدودیت‌های آن الزاماً مانع دسترسی از طریق همه سازوکارهای ارتباطی مانند Unix Socket نمی‌شوند.

همچنین اجرای فرایند با مجوزهای گسترده همچنان خطرآفرین است.

آیا open_basedir باعث کندشدن سایت می‌شود؟

فعال‌سازی open_basedir می‌تواند روی عملکرد بعضی عملیات فایل تأثیر بگذارد.

یکی از نکات مهم این است که فعال‌شدن این محدودیت باعث غیرفعال‌شدن Realpath Cache در PHP می‌شود.

در برنامه‌هایی که فایل‌های زیادی را بارگذاری می‌کنند، این موضوع ممکن است سربار ایجاد کند.

بنابراین بهتر است قبل از فعال‌سازی، نیاز امنیتی و اثر عملکردی آن بررسی شود.

خطر تنظیم بیش‌ازحد محدود

اگر مسیرهای مجاز به‌درستی تعریف نشده باشند، برنامه ممکن است نتواند فایل‌های موقت بسازد، فایل‌های موردنیاز را بخواند یا بعضی عملیات وردپرس را انجام دهد.

به همین دلیل، نباید یک مقدار ثابت open_basedir را برای تمام سایت‌ها کپی کرد.

تنظیم allow_url_fopen و allow_url_include

PHP امکاناتی برای کار با منابع و آدرس‌های اینترنتی دارد.

دو تنظیم مهم در این حوزه عبارت‌اند از allow_url_fopen و allow_url_include.

این گزینه‌ها عملکرد یکسانی ندارند.

نقش allow_url_fopen

گزینه allow_url_fopen اجازه استفاده از بعضی URL Wrapperها برای دسترسی به منابع خارجی را فراهم می‌کند.

برای مثال، برخی توابع فایل می‌توانند با استفاده از این قابلیت به محتوای منابع HTTP یا FTP دسترسی داشته باشند.

غیرفعال‌کردن آن ممکن است سطح قابلیت‌های برنامه را محدود کند.

اما در بعضی سیستم‌های مدیریت محتوا و افزونه‌ها، این تغییر می‌تواند باعث اختلال عملکرد شود.

بنابراین مقدار زیر نباید بدون بررسی وابستگی‌ها اعمال شود:

allow_url_fopen = Off

آیا allow_url_fopen در وردپرس باید غیرفعال شود؟

پاسخ قطعی برای تمام سایت‌های وردپرسی وجود ندارد.

وردپرس و افزونه‌های آن ممکن است برای دریافت اطلاعات یا فایل‌ها از روش‌های مختلف ارتباطی استفاده کنند.

بعضی کتابخانه‌ها نیز ممکن است به URL Wrapperهای PHP وابسته باشند.

به همین دلیل، غیرفعال‌سازی این گزینه تنها زمانی مناسب است که نیاز برنامه بررسی و سازگاری آن آزمایش شده باشد.

نقش allow_url_include

گزینه allow_url_include به قابلیت بارگذاری منابع URL در عملیات Include مربوط است.

این قابلیت با خطرات امنیتی خاصی همراه است و در نسخه‌های جدید PHP نیز به‌عنوان گزینه‌ای منسوخ‌شونده شناخته می‌شود.

برای پیکربندی‌هایی که هنوز از این گزینه پشتیبانی می‌کنند، غیرفعال‌ماندن آن رویکرد مناسبی است:

allow_url_include = Off

این تنظیم نباید با پیشگیری کامل از آسیب‌پذیری File Inclusion اشتباه گرفته شود.

طراحی امن مسیرهای فایل همچنان ضروری است.

افزایش امنیت آپلود فایل در PHP

یکی از مهم‌ترین بخش‌های امنیت PHP، مدیریت فایل‌هایی است که کاربران در سایت آپلود می‌کنند.

وردپرس، ووکامرس و بسیاری از برنامه‌های PHP از قابلیت آپلود برای تصاویر، اسناد و سایر فایل‌ها استفاده می‌کنند.

تنظیمات php.ini امکان محدودسازی بخشی از رفتار آپلود را فراهم می‌کنند.

گزینه file_uploads

این گزینه مشخص می‌کند قابلیت آپلود فایل از طریق HTTP در PHP فعال باشد یا خیر.

برای برنامه‌ای که به هیچ نوع آپلود نیاز ندارد، غیرفعال‌کردن آن قابل بررسی است.

اما در بیشتر سایت‌های وردپرسی، قابلیت آپلود برای رسانه‌ها، قالب‌ها یا برخی افزونه‌ها موردنیاز است.

بنابراین مقدار زیر معمولاً باید برای چنین سایت‌هایی فعال بماند:

file_uploads = On

گزینه upload_max_filesize

این گزینه حداکثر اندازه هر فایل آپلودی را مشخص می‌کند.

برای مثال:

upload_max_filesize = 32M

در این حالت، محدودیت اندازه فایل در سطح PHP برابر ۳۲ مگابایت تعریف می‌شود.

عدد مناسب به نوع سایت بستگی دارد.

یک سایت خبری ممکن است فایل‌های تصویری کوچک دریافت کند، درحالی‌که یک سامانه آموزشی ممکن است به آپلود فایل‌های بزرگ‌تر نیاز داشته باشد.

گزینه post_max_size

گزینه post_max_size سقف حجم داده‌های درخواست POST را تعیین می‌کند.

برای مثال:

post_max_size = 40M

این مقدار باید با اندازه فایل‌های موردنیاز و سایر داده‌های فرم هماهنگ باشد.

اگر post_max_size کوچک‌تر از حجم درخواست باشد، برنامه ممکن است اطلاعات مورد انتظار را دریافت نکند.

در نمونه بالا، مقدار ۴۰ مگابایت برای POST از سقف ۳۲ مگابایتی هر فایل بیشتر است.

این اعداد صرفاً مثال هستند و باید با نیاز واقعی انتخاب شوند.

گزینه max_file_uploads

این گزینه تعداد فایل‌هایی را که می‌توان در یک درخواست به‌صورت هم‌زمان آپلود کرد محدود می‌کند.

برای نمونه:

max_file_uploads = 10

کاهش این مقدار ممکن است در بعضی برنامه‌ها مفید باشد.

اما اگر کاربران یا افزونه‌ها به آپلود هم‌زمان تعداد زیادی فایل نیاز داشته باشند، مقدار بسیار پایین می‌تواند مشکل ایجاد کند.

گزینه upload_tmp_dir

PHP برای مدیریت آپلود ممکن است از فضای ذخیره‌سازی موقت استفاده کند.

با upload_tmp_dir می‌توان مسیر مربوط را تعیین کرد.

این مسیر باید برای فرایند PHP قابل نوشتن باشد و مجوزهای فایل آن به‌درستی تنظیم شده باشند.

بهتر است فایل‌های موقت در مسیر عمومی قابل دسترسی از طریق وب قرار نگیرند.

در صورت استفاده از open_basedir نیز باید سازگاری مسیر موقت با محدودیت‌های تعریف‌شده بررسی شود.

چرا محدودیت حجم آپلود کافی نیست؟

حتی اگر اندازه آپلود را به چند مگابایت محدود کنیم، همچنان ممکن است فایل نامناسب یا مخرب بارگذاری شود.

برای محافظت بهتر باید اقدامات زیر در سطح برنامه و سرور انجام شوند:

1. فقط پسوندهای موردنیاز مجاز باشند.
2. نوع واقعی فایل بررسی شود.
3. صرفاً به هدر Content-Type ارسالی کاربر اعتماد نشود.
4. نام فایل‌ها توسط برنامه به شکل ایمن مدیریت شود.
5. دسترسی آپلود به کاربران مجاز محدود شود.
6. فایل‌ها در صورت امکان خارج از مسیر اجرای کد ذخیره شوند.
7. اجرای اسکریپت در پوشه‌های آپلود ممنوع باشد.
8. برای فایل‌های حساس، اسکن و بررسی محتوای مناسب انجام شود.

این اقدامات مکمل محدودیت‌های php.ini هستند.

تنظیمات امنیتی Session در PHP

نشست‌ها یکی از بخش‌های مهم مدیریت وضعیت کاربران هستند.

برنامه‌های PHP ممکن است از Session داخلی PHP یا سازوکار احراز هویت اختصاصی استفاده کنند.

بنابراین ابتدا باید مشخص شود برنامه واقعاً از نشست‌های داخلی PHP استفاده می‌کند یا خیر.

فعال‌سازی session.use_strict_mode

این گزینه باعث می‌شود PHP شناسه‌های نشست مقداردهی‌نشده را نپذیرد.

تنظیم پیشنهادی برای برنامه‌هایی که از Session داخلی PHP استفاده می‌کنند:

session.use_strict_mode = 1

این قابلیت می‌تواند به کاهش خطر بعضی سناریوهای Session Fixation کمک کند.

البته در صورت استفاده از Session Handler سفارشی، باید اطمینان حاصل شود که اعتبارسنجی شناسه نشست به‌درستی پیاده‌سازی شده است.

فعال‌سازی session.cookie_httponly

گزینه session.cookie_httponly امکان افزودن ویژگی HttpOnly به کوکی نشست PHP را فراهم می‌کند.

تنظیم پیشنهادی:

session.cookie_httponly = On

این ویژگی مانع دسترسی مستقیم JavaScript به کوکی دارای HttpOnly می‌شود.

در نتیجه می‌تواند بخشی از خطرات مرتبط با سرقت کوکی از طریق XSS را کاهش دهد.

اما نباید تصور کرد این ویژگی تمام آثار XSS را از بین می‌برد.

فعال‌سازی session.cookie_secure

برای سایت‌هایی که به‌صورت کامل از HTTPS استفاده می‌کنند، تنظیم زیر اهمیت دارد:

session.cookie_secure = On

این گزینه باعث می‌شود کوکی نشست PHP فقط از طریق ارتباط امن ارسال شود.

اگر برنامه روی HTTP اجرا شود، فعال‌سازی این گزینه ممکن است باعث اختلال در عملکرد نشست شود.

در زیرساخت‌های دارای Reverse Proxy یا CDN نیز باید تنظیمات HTTPS و تشخیص صحیح پروتکل درخواست بررسی شوند.

استفاده از session.cookie_samesite

ویژگی SameSite به مرورگر کمک می‌کند درباره ارسال کوکی در درخواست‌های میان‌سایتی تصمیم بگیرد.

یک مقدار رایج:

session.cookie_samesite = Lax

گزینه Strict محدودکننده‌تر است، اما ممکن است در بعضی جریان‌های ورود یا ارتباطات میان‌سایتی اختلال ایجاد کند.

گزینه None نیز برای بعضی یکپارچه‌سازی‌ها لازم است و معمولاً باید همراه با ویژگی Secure استفاده شود.

انتخاب مقدار مناسب به معماری برنامه وابسته است.

استفاده از session.use_only_cookies

این گزینه استفاده از کوکی‌ها برای انتقال شناسه نشست PHP را کنترل می‌کند.

تنظیم پیشنهادی:

session.use_only_cookies = 1

مدیریت نشست از طریق URL می‌تواند خطر افشای شناسه نشست را افزایش دهد.

به همین دلیل، استفاده از کوکی‌ها رویکرد مناسب‌تری برای اکثر برنامه‌های مدرن محسوب می‌شود.

تعیین session.cookie_lifetime

این گزینه طول عمر کوکی نشست را مشخص می‌کند.

مقدار زیر به معنای کوکی نشست مرورگر است:

session.cookie_lifetime = 0

البته زمان حذف واقعی کوکی ممکن است تحت تأثیر رفتار مرورگر و قابلیت بازیابی نشست آن باشد.

مدیریت نشست امن باید شامل انقضای سمت سرور، خروج کاربر، بازتولید شناسه پس از احراز هویت و کنترل فعالیت‌های حساس نیز باشد.

آیا این تنظیمات کوکی‌های ورود وردپرس را امن می‌کنند؟

وردپرس برای احراز هویت کاربران از سازوکار کوکی و نشست مخصوص خود استفاده می‌کند.

بنابراین تنظیمات session.cookie_* الزاماً روی کوکی‌های ورود وردپرس اعمال نمی‌شوند.

این گزینه‌ها بیشتر برای برنامه‌ها یا افزونه‌هایی کاربرد دارند که از Session داخلی PHP استفاده می‌کنند.

برای امنیت ورود وردپرس باید HTTPS، مدیریت کوکی‌های احراز هویت، احراز هویت دومرحله‌ای و به‌روزرسانی‌ها نیز بررسی شوند.

کنترل مصرف منابع با تنظیمات php.ini

مصرف بیش‌ازحد منابع می‌تواند باعث کاهش سرعت یا اختلال در دسترس‌پذیری سایت شود.

PHP چند گزینه برای مدیریت بخشی از این مصرف فراهم می‌کند.

گزینه memory_limit

این گزینه حداکثر حافظه قابل استفاده برای یک اجرای PHP را مشخص می‌کند.

برای مثال:

memory_limit = 256M

مقدار مناسب به نوع برنامه بستگی دارد.

یک وب‌سایت ساده ممکن است حافظه کمتری نیاز داشته باشد؛ اما فروشگاه ووکامرسی با افزونه‌های متعدد ممکن است مصرف بالاتری داشته باشد.

افزایش بی‌رویه این مقدار نیز مناسب نیست.

به‌عنوان مثال، اگر تعداد زیادی فرایند PHP-FPM به‌صورت هم‌زمان فعال باشند، مجموع حافظه مصرفی سرور می‌تواند بسیار بیشتر از مقدار یک اجرای PHP باشد.

گزینه max_execution_time

این گزینه محدودیت زمان اجرای اسکریپت PHP را تعیین می‌کند.

برای مثال:

max_execution_time = 60

مقدار بسیار زیاد می‌تواند در بعضی سناریوها باعث اشغال طولانی‌تر منابع شود.

در مقابل، مقدار بسیار پایین ممکن است باعث اختلال در پردازش‌های معتبر شود.

همچنین رفتار واقعی این محدودیت به سیستم‌عامل و نوع عملیات بستگی دارد و نباید آن را یک محدودیت مطلق برای تمام انواع فعالیت‌های فرایند تصور کرد.

گزینه max_input_time

این گزینه زمان مجاز برای پردازش داده‌های ورودی توسط PHP را کنترل می‌کند.

یک نمونه تنظیم:

max_input_time = 60

مقدار مناسب باید با نوع فرم‌ها، آپلودها و رفتار کاربران هماهنگ باشد.

گزینه max_input_vars

این گزینه سقف تعداد متغیرهای ورودی قابل پردازش را مشخص می‌کند.

برای نمونه:

max_input_vars = 3000

این محدودیت می‌تواند در مدیریت حجم ورودی‌ها نقش داشته باشد.

اما در وردپرس، بعضی افزونه‌ها و فرم‌های مدیریتی دارای تعداد زیادی فیلد هستند.

اگر مقدار بیش‌ازحد پایین باشد، بخشی از داده‌های فرم ممکن است پردازش نشود.

به همین دلیل، انتخاب مقدار مناسب باید پس از بررسی نیازهای واقعی برنامه انجام شود.

افزایش امنیت PHP-FPM

PHP-FPM یکی از روش‌های رایج اجرای PHP در کنار وب‌سرورهایی مانند Nginx و Apache است.

در این معماری، PHP-FPM درخواست‌های PHP را از وب‌سرور دریافت و پردازش می‌کند.

امنیت این سرویس فقط به php.ini وابسته نیست؛ زیرا فایل‌های پیکربندی Pool نیز نقش مهمی دارند.

استفاده از کاربر مستقل برای هر سایت

در سرورهایی که چند وب‌سایت دارند، بهتر است اجرای PHP هر سایت تا حد امکان با هویت و سطح دسترسی مستقل انجام شود.

این موضوع به کاهش خطر دسترسی یک سایت به فایل‌های سایت دیگر کمک می‌کند.

برای مثال، می‌توان برای هر سایت یک Pool اختصاصی PHP-FPM تعریف کرد.

البته صرف ایجاد Pool جداگانه کافی نیست و مجوزهای سیستم‌عامل نیز باید درست باشند.

محدودسازی دسترسی به Socket

PHP-FPM ممکن است از Unix Socket یا اتصال TCP برای ارتباط با وب‌سرور استفاده کند.

اگر از Unix Socket استفاده می‌شود، مجوزهای فایل Socket باید فقط دسترسی فرایندهای مجاز را فراهم کنند.

در پیکربندی Pool، گزینه‌هایی مانند موارد زیر اهمیت دارند:

• listen.owner
• listen.group
• listen.mode

این تنظیمات باید متناسب با کاربر وب‌سرور انتخاب شوند.

کنترل متغیرهای محیطی با clear_env

در پیکربندی PHP-FPM، گزینه clear_env نحوه انتقال متغیرهای محیطی به فرایندهای Worker را کنترل می‌کند.

برای بسیاری از پیکربندی‌ها، مقدار زیر مناسب است:

clear_env = yes

این گزینه به جلوگیری از انتقال ناخواسته بعضی متغیرهای محیطی کمک می‌کند.

بااین‌حال، اگر برنامه به متغیرهای محیطی مشخصی نیاز دارد، باید آن‌ها به روش کنترل‌شده در اختیار برنامه قرار گیرند.

محدودسازی پسوندها با security.limit_extensions

گزینه security.limit_extensions در PHP-FPM مشخص می‌کند چه پسوندهایی برای اسکریپت اصلی قابل پردازش باشند.

برای برنامه‌هایی که فقط به فایل‌های .php نیاز دارند، می‌توان محدودسازی به این پسوند را بررسی کرد.

نمونه:

security.limit_extensions = .php

این اقدام می‌تواند در کاهش خطر بعضی خطاهای پیکربندی وب‌سرور مؤثر باشد.

البته قبل از تغییر باید وابستگی‌های برنامه و پیکربندی Nginx یا Apache بررسی شود.

کنترل تعداد Workerها

گزینه‌هایی مانند pm.max_children بر تعداد فرایندهای هم‌زمان PHP-FPM تأثیر دارند.

تنظیم صحیح این مقدار می‌تواند به مدیریت مصرف حافظه و ظرفیت پردازش کمک کند.

اما انتخاب مقدار آن به میزان RAM، مصرف هر Worker و حجم ترافیک بستگی دارد.

محدودیت بسیار پایین ممکن است باعث ایجاد صف درخواست و کندی سایت شود؛ درحالی‌که مقدار بیش‌ازحد بالا می‌تواند حافظه سرور را تحت فشار قرار دهد.

جلوگیری از اجرای ناخواسته فایل‌های PHP در Nginx و Apache

یکی از مهم‌ترین اصول امنیت سرورهای PHP، کنترل دقیق فایل‌هایی است که اجازه اجرا دارند.

این موضوع به‌ویژه در سایت‌هایی اهمیت دارد که کاربران قادر به آپلود فایل هستند.

چرا پوشه آپلود نباید محل اجرای PHP باشد؟

پوشه‌های آپلود برای نگهداری فایل‌هایی مانند تصویر، سند و رسانه طراحی شده‌اند.

اگر سرور به‌اشتباه اجازه اجرای فایل PHP را در این مسیرها بدهد، یک ضعف امنیتی در فرایند آپلود می‌تواند پیامدهای جدی‌تری داشته باشد.

به همین دلیل، بهتر است اجرای اسکریپت در مسیرهای آپلود توسط تنظیمات وب‌سرور ممنوع شود.

این محدودیت مستقل از upload_max_filesize است.

اهمیت پیکربندی صحیح Nginx

در سرورهای Nginx و PHP-FPM، مسیر فایل اجرایی باید با دقت به PHP-FPM ارسال شود.

تنظیمات مربوط به SCRIPT_FILENAME و مدیریت درخواست فایل‌های موجود اهمیت دارند.

پیکربندی نادرست ممکن است باعث رفتار غیرمنتظره در تفسیر مسیر فایل‌ها شود.

در بعضی معماری‌ها، گزینه cgi.fix_pathinfo نیز باید بررسی شود؛ اما غیرفعال‌کردن آن بدون شناخت نیاز برنامه راهکار عمومی و قطعی نیست.

اهمیت تنظیمات Apache

در Apache نیز باید مشخص باشد کدام مسیرها و پسوندها اجازه اجرای PHP دارند.

همچنین دسترسی مستقیم کاربران به فایل‌های پیکربندی و منابع حساس باید محدود شود.

در محیط‌هایی که چند وب‌سایت روی یک سرور قرار دارند، جداسازی مجوزها اهمیت بیشتری پیدا می‌کند.

نقش OPcache در امنیت و عملکرد PHP

OPcache یکی از امکانات PHP برای ذخیره و استفاده مجدد از کدهای کامپایل‌شده است.

این قابلیت می‌تواند سربار پردازش برنامه را کاهش دهد و عملکرد وب‌سایت را بهبود دهد.

بااین‌حال، تنظیمات نادرست آن ممکن است باعث باقی‌ماندن نسخه قدیمی کد در حافظه شود.

گزینه opcache.validate_timestamps

این گزینه مشخص می‌کند OPcache تغییرات فایل‌های برنامه را بررسی کند یا خیر.

یک مقدار رایج:

opcache.validate_timestamps = 1

در این حالت، OPcache می‌تواند تغییرات فایل‌ها را براساس تنظیمات بررسی مجدد تشخیص دهد.

اگر این قابلیت غیرفعال باشد، معمولاً باید پس از انتشار تغییرات، فرایند بازنشانی مناسب OPcache انجام شود.

خطر باقی‌ماندن کد قدیمی

فرض کنید یک آسیب‌پذیری در افزونه وردپرس اصلاح شده و فایل جدید روی سرور قرار گرفته است.

اگر پیکربندی OPcache مانع شناسایی تغییر شود، ممکن است کد قبلی تا زمان پاک‌سازی کش یا راه‌اندازی مجدد فرایند مربوط همچنان مورد استفاده قرار گیرد.

بنابراین فرایند به‌روزرسانی و انتشار نسخه جدید باید با تنظیمات OPcache هماهنگ باشد.

آیا OPcache یک ابزار امنیتی است؟

OPcache اساساً برای بهبود عملکرد طراحی شده است.

بااین‌حال، مدیریت درست آن می‌تواند از مشکلات ناشی از اجرای نسخه‌های قدیمی کد جلوگیری کند.

این قابلیت جایگزین بررسی آسیب‌پذیری‌ها یا کنترل دسترسی نیست.

مهم‌ترین تنظیمات امنیت PHP برای وردپرس

وردپرس یکی از پرکاربردترین سیستم‌های مدیریت محتوا است که با PHP اجرا می‌شود.

امنیت وردپرس به نسخه PHP، پیکربندی محیط اجرا، کیفیت افزونه‌ها و تنظیمات سرور وابسته است.

استفاده از نسخه پشتیبانی‌شده PHP

یکی از مهم‌ترین اقدامات برای افزایش امنیت PHP، استفاده از نسخه‌ای است که همچنان به‌روزرسانی امنیتی دریافت می‌کند.

در زمان نگارش این مقاله، شاخه‌های PHP 8.2، 8.3، 8.4 و 8.5 در دوره‌های مختلف پشتیبانی قرار دارند.

پشتیبانی امنیتی PHP 8.2 طبق برنامه رسمی در پایان دسامبر ۲۰۲۶ خاتمه پیدا می‌کند.

وردپرس نیز برای میزبانی، PHP نسخه 8.3 یا بالاتر را توصیه می‌کند.

بهتر است نسخه جدید براساس سازگاری هسته وردپرس، قالب، افزونه‌ها و اکستنشن‌های موردنیاز انتخاب شود.

محافظت از wp-config.php

فایل wp-config.php اطلاعات مهمی درباره پیکربندی وردپرس دارد.

امنیت این فایل باید از طریق مجوزهای مناسب سیستم‌عامل و تنظیمات وب‌سرور تأمین شود.

وجود open_basedir یا غیرفعال‌کردن برخی توابع PHP به‌تنهایی برای محافظت از این فایل کافی نیست.

همچنین نباید فایل‌های نسخه پشتیبان یا کپی‌های موقت پیکربندی در مسیر عمومی سایت باقی بمانند.

غیرفعال‌کردن ویرایشگر فایل وردپرس

در بعضی شرایط، امکان ویرایش فایل‌های قالب و افزونه از داخل داشبورد وردپرس می‌تواند خطر سوءاستفاده از حساب مدیریتی را افزایش دهد.

برای محدودکردن این قابلیت می‌توان در فایل پیکربندی وردپرس از ثابت زیر استفاده کرد:

define( 'DISALLOW_FILE_EDIT', true );

این تنظیم مانع تمام روش‌های تغییر فایل‌ها نمی‌شود، اما می‌تواند یک مسیر مدیریتی حساس را محدود کند.

مدیریت صحیح WP_DEBUG

وردپرس دارای تنظیمات اختصاصی برای اشکال‌زدایی است.

در سایت عملیاتی بهتر است وضعیت WP_DEBUG و نمایش خطاهای وردپرس بررسی شود.

نباید تصور کرد غیرفعال‌سازی display_errors در php.ini تمام خروجی‌های اشکال‌زدایی وردپرس را به‌صورت مستقل کنترل می‌کند.

تنظیمات برنامه و محیط PHP باید هماهنگ باشند.

امنیت PHP در ووکامرس

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

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

همچنین تنظیمات مربوط به درخواست‌های خروجی نباید ارتباط معتبر فروشگاه با سرویس‌های پرداخت، ارسال پیام یا سایر APIها را مختل کند.

نمونه تنظیمات پیشنهادی php.ini برای سایت عملیاتی

در این بخش یک نمونه پیکربندی اولیه ارائه می‌شود.

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

نمونه زیر بیشتر برای یک وب‌سایت عمومی مبتنی بر PHP با HTTPS و قابلیت آپلود معمول طراحی شده است.

; PHP Production Security Baseline

; Information disclosure
expose_php = Off
display_errors = Off
display_startup_errors = Off

; Error handling
log_errors = On
error_reporting = E_ALL
zend.exception_ignore_args = On

; Upload settings
file_uploads = On
upload_max_filesize = 32M
post_max_size = 40M
max_file_uploads = 10

; Resource limits
memory_limit = 256M
max_execution_time = 60
max_input_time = 60
max_input_vars = 3000

; Native PHP session security
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = On
session.cookie_httponly = On
session.cookie_samesite = Lax
session.cookie_lifetime = 0

; Opcache
opcache.validate_timestamps = 1

چرا همه تنظیمات امنیتی در این نمونه وجود ندارند؟

بعضی گزینه‌ها مانند disable_functions، open_basedir و allow_url_fopen به نیازهای واقعی برنامه وابسته هستند.

اعمال مقدار یکسان برای این گزینه‌ها در تمام سرورها می‌تواند باعث اختلال شود.

همچنین تنظیمات PHP-FPM مانند security.limit_extensions باید در فایل مناسب Pool اعمال شوند، نه اینکه بدون بررسی در php.ini قرار گیرند.

آیا می‌توان این تنظیمات را مستقیماً کپی کرد؟

این مجموعه یک نقطه شروع برای بررسی است، نه پیکربندی قطعی تمام سایت‌ها.

به‌ویژه تنظیمات Session، محدودیت آپلود و مصرف منابع باید با برنامه هماهنگ شوند.

برای مثال، اگر برنامه به آپلود فایل ۱۰۰ مگابایتی نیاز دارد، مقدار ۳۲ مگابایت مناسب نخواهد بود.

اگر سایت فاقد HTTPS صحیح باشد، فعال‌کردن session.cookie_secure نیز ممکن است نشست‌های داخلی PHP را مختل کند.

آموزش اعمال تغییرات امنیتی php.ini در سرور

پس از انتخاب تنظیمات مناسب، باید تغییرات به‌صورت کنترل‌شده اعمال شوند.

مرحله اول: شناسایی سرویس فعال PHP

ابتدا مشخص کنید وب‌سایت از کدام نسخه و روش اجرای PHP استفاده می‌کند.

در بعضی سرورها چند نسخه PHP به‌صورت هم‌زمان نصب شده‌اند.

بنابراین تغییر فایل اشتباه ممکن است هیچ اثری روی سایت نداشته باشد.

مرحله دوم: ذخیره پیکربندی قبلی

پیش از ویرایش، نسخه پشتیبان از فایل پیکربندی تهیه کنید.

بهتر است تغییرات در یک محیط آزمایشی بررسی شوند و پس از تأیید، روی سایت اصلی اعمال شوند.

مرحله سوم: ویرایش تنظیمات موردنیاز

فایل مناسب را با دسترسی مدیریتی باز کنید.

در Ubuntu ممکن است ویرایش فایل PHP-FPM با دستور مشابه زیر انجام شود:

sudo nano /etc/php/8.4/fpm/php.ini

شماره نسخه و مسیر فایل باید متناسب با سرور واقعی باشد.

پس از اصلاح مقدارها، فایل را ذخیره کنید.

مرحله چهارم: بررسی صحت پیکربندی

برای سرورهای PHP-FPM بهتر است پیش از اعمال تغییرات، اعتبار تنظیمات سرویس بررسی شود.

در بسیاری از نصب‌های نسخه‌دار، دستور مشابه زیر قابل استفاده است:

sudo php-fpm8.4 -t

نام باینری ممکن است در توزیع‌ها و نسخه‌های مختلف متفاوت باشد.

این بررسی باید با همان نسخه PHP-FPM انجام شود که سایت از آن استفاده می‌کند.

مرحله پنجم: بارگذاری مجدد سرویس

پس از اعتبارسنجی تنظیمات، ممکن است لازم باشد سرویس PHP-FPM بازخوانی یا راه‌اندازی مجدد شود.

برای مثال:

sudo systemctl reload php8.4-fpm

این دستور برای همه سرورها یکسان نیست.

در هاست‌های اشتراکی ممکن است تغییرات از طریق پنل اعمال شوند و دسترسی مستقیم به سرویس وجود نداشته باشد.

مرحله ششم: آزمایش عملکرد سایت

بعد از اعمال تغییرات، عملکرد صفحه اصلی، پنل مدیریت، ورود کاربران، آپلود رسانه و سایر قابلیت‌های مهم را بررسی کنید.

در فروشگاه اینترنتی، باید فرایند ثبت سفارش و ارتباط با درگاه نیز آزمایش شود.

اگر اختلالی مشاهده شد، لاگ‌ها و تغییرات اخیر بررسی شوند.

چگونه امنیت PHP سایت را بررسی کنیم؟

تنظیم php.ini تنها بخشی از فرایند ایمن‌سازی است.

برای اطمینان از درست‌بودن پیکربندی، باید تنظیمات واقعی اجرا و رفتار برنامه بررسی شوند.

بررسی تنظیمات فعال

در محیط مدیریت‌شده می‌توان مقدار تنظیمات PHP را با ابزارهای مدیریتی یا روش‌های برنامه‌نویسی مناسب بررسی کرد.

برای مثال، تابع ini_get() امکان دریافت مقدار بعضی گزینه‌ها را فراهم می‌کند.

بااین‌حال، بررسی باید در محیط امن انجام شود و اطلاعات پیکربندی نباید در اختیار کاربران عمومی قرار گیرند.

بررسی هدرهای HTTP

برای بررسی انتشار اطلاعات شناسایی PHP می‌توان هدرهای پاسخ سرور را مشاهده کرد.

وجود هدر X-Powered-By ممکن است نشان دهد اطلاعاتی درباره فناوری اجرا منتشر می‌شود.

اما نبود این هدر به‌تنهایی نشان‌دهنده امن‌بودن PHP نیست.

بررسی آپلود فایل

اگر سایت قابلیت آپلود دارد، باید بررسی شود محدودیت حجم و نوع فایل به‌درستی اجرا می‌شود.

این آزمایش بهتر است با فایل‌های سالم و کنترل‌شده انجام شود.

همچنین باید مطمئن شد فایل‌های آپلودشده در مسیرهای غیرمجاز به‌عنوان کد اجرایی پردازش نمی‌شوند.

بررسی نشست کاربران

در برنامه‌هایی که از Session داخلی PHP استفاده می‌کنند، ویژگی‌های کوکی نشست باید در مرورگر بررسی شوند.

وجود ویژگی‌های Secure، HttpOnly و SameSite باید متناسب با طراحی برنامه باشد.

همچنین خروج کاربر، انقضای نشست و بازتولید شناسه پس از ورود باید بررسی شوند.

تفاوت امنیت PHP با امنیت وردپرس چیست؟

امنیت PHP و امنیت وردپرس با یکدیگر ارتباط دارند، اما یکسان نیستند.

امنیت PHP بیشتر بر محیط اجرای زبان، تنظیمات مفسر، مدیریت منابع و کنترل قابلیت‌های حساس تمرکز می‌کند.

در مقابل، امنیت وردپرس شامل امنیت هسته، افزونه‌ها، قالب‌ها، حساب‌های کاربری، تنظیمات برنامه و نحوه ارتباط با زیرساخت است.

برای افزایش امنیت یک سایت وردپرسی، هر دو حوزه باید بررسی شوند.

نقش WAF و فایروال سرور در امنیت PHP

فایروال سرور، WAF و تنظیمات PHP در لایه‌های متفاوتی از زیرساخت فعالیت می‌کنند.

فایروال سرور ارتباطات شبکه را کنترل می‌کند و می‌تواند دسترسی مستقیم به سرویس‌های غیرضروری را محدود کند.

WAF درخواست‌های HTTP و HTTPS را بررسی می‌کند و ممکن است برخی الگوهای مرتبط با SQL Injection، XSS و سایر حملات وب را شناسایی کند.

در مقابل، php.ini بر رفتار محیط اجرای PHP تأثیر می‌گذارد.

برای مثال، اگر یک برنامه دارای آسیب‌پذیری امنیتی باشد، WAF ممکن است بخشی از درخواست‌های سوءاستفاده را فیلتر کند.

در همین شرایط، محدودسازی مجوزهای فرایند PHP می‌تواند دامنه دسترسی احتمالی به منابع را کاهش دهد.

اما هیچ‌یک از این کنترل‌ها به‌تنهایی تضمین‌کننده امنیت کامل نیستند.

بهترین راهکار، ترکیب تنظیمات امن PHP با کنترل دسترسی، برنامه‌نویسی امن، فایروال، WAF و مانیتورینگ است.

اشتباهات رایج در افزایش امنیت PHP

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

۱. غیرفعال‌کردن تمام توابع حساس

غیرفعال‌کردن تعداد زیادی تابع بدون بررسی وابستگی‌ها ممکن است امکانات برنامه را از کار بیندازد.

همچنین disable_functions یک مرز امنیتی کامل نیست.

بهتر است فقط محدودیت‌های ضروری و قابل دفاع اعمال شوند.

۲. فعال‌گذاشتن نمایش خطاها

نمایش خطاهای PHP در سایت عملیاتی می‌تواند اطلاعات فنی غیرضروری را افشا کند.

بهتر است خطاها در محیط مناسب ثبت شوند و به‌صورت عمومی نمایش داده نشوند.

۳. غیرفعال‌کردن allow_url_fopen بدون بررسی

بعضی برنامه‌ها یا افزونه‌ها ممکن است برای دریافت منابع به URL Wrapperهای PHP وابسته باشند.

غیرفعال‌سازی این گزینه باید پس از بررسی سازگاری انجام شود.

۴. تنظیم اشتباه open_basedir

محدودسازی بیش‌ازحد مسیرها ممکن است باعث اختلال در فایل‌های موقت، کتابخانه‌ها یا فرایندهای نگهداری شود.

همچنین این گزینه را نباید جایگزین مجوزهای صحیح سیستم‌عامل دانست.

۵. استفاده از نسخه قدیمی PHP

استفاده از نسخه‌های خارج از پشتیبانی امنیتی می‌تواند خطر مواجهه با آسیب‌پذیری‌های اصلاح‌نشده را افزایش دهد.

به‌روزرسانی باید براساس برنامه مشخص و پس از بررسی سازگاری انجام شود.

۶. افزایش بی‌رویه memory_limit

افزایش محدودیت حافظه بدون توجه به تعداد فرایندها می‌تواند فشار بیشتری بر RAM سرور ایجاد کند.

این گزینه باید متناسب با ظرفیت سخت‌افزار و رفتار برنامه انتخاب شود.

۷. اعتماد کامل به تنظیمات آپلود PHP

محدودیت اندازه فایل مانع آپلود تمام فایل‌های مخرب نمی‌شود.

اعتبارسنجی محتوا، مدیریت نام فایل و جلوگیری از اجرای اسکریپت در مسیر آپلود ضروری هستند.

۸. انتشار عمومی phpinfo

صفحه phpinfo اطلاعات زیادی درباره محیط سرور نمایش می‌دهد.

قرارگرفتن دائمی این صفحه در مسیر عمومی سایت می‌تواند اطلاعات غیرضروری را در اختیار دیگران قرار دهد.

۹. تغییر فایل php.ini اشتباه

در سرورهای دارای چند نسخه PHP، ممکن است مدیر فایل CLI را تغییر دهد، درحالی‌که وب‌سایت از PHP-FPM دیگری استفاده می‌کند.

قبل از ویرایش باید مسیر واقعی تنظیمات وب‌سایت شناسایی شود.

۱۰. اعمال تغییرات بدون آزمایش

فعال‌سازی یک گزینه امنیتی نباید بدون بررسی نتیجه انجام شود.

پس از تغییرات، لازم است عملکرد برنامه، لاگ‌ها و مسیرهای وابسته بررسی شوند.

چک‌لیست افزایش امنیت PHP در سرور

برای بررسی وضعیت امنیت PHP، موارد زیر را در برنامه نگهداری سرور قرار دهید:

1. استفاده از نسخه PHP دارای پشتیبانی امنیتی
2. به‌روزرسانی منظم PHP و افزونه‌های نصب‌شده
3. غیرفعال‌بودن نمایش خطاها در محیط عملیاتی
4. فعال‌بودن ثبت امن خطاها
5. غیرفعال‌بودن انتشار غیرضروری اطلاعات PHP
6. بررسی نیاز واقعی به توابع حساس
7. محدودسازی مجوزهای فایل و فرایندها
8. بررسی نیاز به open_basedir و اثر عملکردی آن
9. کنترل قابلیت‌های دسترسی به منابع خارجی
10. محدودسازی مناسب اندازه و تعداد آپلودها
11. جلوگیری از اجرای کد در مسیرهای آپلود
12. استفاده از HTTPS برای ارتباطات حساس
13. تنظیم امن Session در برنامه‌های وابسته به نشست PHP
14. کنترل حافظه و زمان اجرای درخواست‌ها
15. جداسازی کاربران و Poolهای PHP-FPM در صورت نیاز
16. بررسی مجوزهای Socket و مسیرهای موقت
17. تنظیم صحیح OPcache و فرایند انتشار تغییرات
18. جلوگیری از دسترسی عمومی به فایل‌های پیکربندی و لاگ‌ها
19. هماهنگی تنظیمات PHP با وب‌سرور و WAF
20. آزمایش عملکرد سایت پس از تغییر تنظیمات

این چک‌لیست یک چارچوب اولیه برای ایمن‌سازی PHP است و باید متناسب با معماری واقعی سرور تکمیل شود.

سؤالات متداول درباره امنیت PHP و php.ini

امنیت PHP چیست؟

امنیت PHP مجموعه‌ای از اقدامات مرتبط با کدنویسی امن، تنظیمات محیط اجرا، محدودسازی دسترسی‌ها و مدیریت منابع است که برای کاهش خطر آسیب‌پذیری و محافظت از برنامه‌های تحت وب انجام می‌شود.

فایل php.ini چیست؟

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

بهترین تنظیمات امنیتی php.ini کدام‌اند؟

تنظیماتی مانند display_errors = Off، log_errors = On و expose_php = Off از گزینه‌های مهم برای محیط عملیاتی هستند. سایر تنظیمات مانند open_basedir و disable_functions باید براساس نیاز برنامه بررسی شوند.

آیا تغییر php.ini باعث افزایش امنیت وردپرس می‌شود؟

بله، پیکربندی مناسب PHP می‌تواند بعضی خطرات را کاهش دهد. اما امنیت وردپرس به به‌روزرسانی هسته و افزونه‌ها، مجوزهای فایل، احراز هویت و تنظیمات وب‌سرور نیز وابسته است.

آیا disable_functions امنیت سایت را تضمین می‌کند؟

خیر. این گزینه فقط برخی توابع داخلی PHP را غیرفعال می‌کند و یک Sandbox کامل ایجاد نمی‌کند. امنیت مؤثر به محدودسازی مجوزهای سیستم‌عامل و سایر کنترل‌های دفاعی نیاز دارد.

آیا open_basedir باید فعال باشد؟

فعال‌سازی این گزینه به معماری سرور بستگی دارد. در بعضی شرایط می‌تواند محدودیت تکمیلی مفیدی ایجاد کند، اما ممکن است با مسیرهای موردنیاز برنامه تداخل داشته باشد و بر عملکرد تأثیر بگذارد.

آیا display_errors باید روشن باشد؟

در محیط توسعه ممکن است برای عیب‌یابی مفید باشد؛ اما در سایت عملیاتی بهتر است غیرفعال باشد و خطاها در مسیر مناسب ثبت شوند.

آیا allow_url_fopen خطرناک است؟

این قابلیت به‌خودی‌خود آسیب‌پذیری محسوب نمی‌شود، اما می‌تواند در بعضی سناریوهای ناامن مورد سوءاستفاده قرار گیرد. غیرفعال‌سازی آن باید متناسب با نیاز برنامه و پس از بررسی سازگاری انجام شود.

آیا تنظیمات Session برای وردپرس ضروری هستند؟

تنظیمات Session داخلی PHP برای برنامه‌هایی اهمیت دارند که از همین سازوکار استفاده می‌کنند. وردپرس برای ورود کاربران از سیستم احراز هویت و کوکی‌های مخصوص خود بهره می‌برد؛ بنابراین همه تنظیمات Session PHP مستقیماً روی ورود وردپرس اثر ندارند.

بهترین مقدار memory_limit برای وردپرس چیست؟

مقدار مناسب به نوع سایت، افزونه‌ها، حجم پردازش و منابع سرور بستگی دارد. عددی مانند ۲۵۶ مگابایت می‌تواند نقطه شروعی برای بعضی سایت‌ها باشد، اما مقدار نهایی باید براساس مصرف واقعی انتخاب شود.

آیا PHP-FPM از mod_php امن‌تر است؟

امنیت نهایی به پیکربندی بستگی دارد. PHP-FPM امکاناتی مانند Poolهای مستقل و مدیریت جداگانه کاربران فراهم می‌کند که می‌توانند به جداسازی بهتر برنامه‌ها کمک کنند؛ اما پیاده‌سازی نادرست هر معماری همچنان خطرآفرین است.

آیا تغییرات php.ini نیاز به راه‌اندازی مجدد دارد؟

بسته به روش اجرای PHP و نوع تنظیمات، ممکن است بازخوانی یا راه‌اندازی مجدد سرویس لازم باشد. در PHP-FPM معمولاً تغییر فایل اصلی پیکربندی به بارگذاری مجدد سرویس مربوط نیاز دارد.

آیا php.ini مانع SQL Injection می‌شود؟

خیر. پیشگیری اصلی از SQL Injection به استفاده از پرس‌وجوهای پارامتری، کنترل ورودی و طراحی امن برنامه وابسته است. تنظیمات PHP و WAF می‌توانند لایه‌های دفاعی تکمیلی باشند.

آیا می‌توان تمام تنظیمات امنیتی PHP را در هاست اشتراکی تغییر داد؟

خیر. سطح دسترسی کاربر و نوع تنظیمات تعیین می‌کنند کدام گزینه‌ها قابل تغییر هستند. برخی تنظیمات فقط توسط مدیر سرور قابل مدیریت‌اند.

چگونه بفهمیم تنظیمات امنیتی PHP اعمال شده‌اند؟

باید پیکربندی واقعی PHP مورد استفاده سایت بررسی شود. ابزارهای مدیریتی هاست، بررسی کنترل‌شده مقدار تنظیمات و لاگ‌های سرویس می‌توانند در این کار کمک کنند.

جمع‌بندی: چگونه امنیت PHP سایت را افزایش دهیم؟

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

فایل php.ini امکاناتی برای کنترل نمایش خطاها، مدیریت نشست‌ها، محدودسازی آپلود، تنظیم حافظه و مدیریت برخی قابلیت‌های حساس فراهم می‌کند.

برای افزایش امنیت PHP، بهتر است ابتدا نسخه نرم‌افزار و محیط اجرای واقعی شناسایی شود. سپس تنظیمات مهم مانند display_errors، log_errors و expose_php بررسی شوند و سایر محدودیت‌ها براساس نیاز برنامه انتخاب شوند.

در سایت‌های وردپرسی، توجه به امنیت PHP-FPM، مجوزهای فایل، مسیرهای آپلود و سازگاری افزونه‌ها نیز اهمیت زیادی دارد.

همچنین نباید فراموش کرد که غیرفعال‌کردن گسترده توابع یا محدودسازی بدون برنامه، لزوماً امنیت بیشتری ایجاد نمی‌کند و حتی ممکن است عملکرد سایت را مختل کند.

بهترین رویکرد، استفاده از نسخه پشتیبانی‌شده PHP، پیکربندی دقیق php.ini، اجرای برنامه با حداقل دسترسی، ثبت و پایش خطاها، به‌روزرسانی منظم و استفاده از کنترل‌های مکمل مانند فایروال و WAF است.

در نهایت، هدف از افزایش امنیت PHP فقط محدودکردن قابلیت‌ها نیست؛ بلکه ایجاد تعادل میان امنیت، سازگاری، عملکرد و امکان مدیریت مطمئن وب‌سایت است.