آسیب‌پذیری‌های PHP ضعف‌هایی در زمان اجرای PHP، کد برنامه، بسته‌های شخص ثالث یا پیکربندی سرور هستند که می‌توانند یک وب‌سایت را در معرض دسترسی غیرمجاز، سرقت داده یا اختلال قرار دهند. مثال‌های رایج شامل تزریق SQL، اسکریپت‌نویسی متقاطع سایت، آپلودهای ناامن فایل و کنترل‌های دسترسی شکسته است.
این تمایز مهم است زیرا رفع آن‌ها متفاوت است. یک نقص امنیتی زمان اجرا نیاز به یک نسخه وصله شده PHP دارد. یک اشکال مجوز نیاز به تغییر کد یا خط‌مشی دارد. به‌روزرسانی PHP ضروری است، اما به طور خودکار هر ضعفی را در وب‌سایتی که با آن ساخته شده است، ترمیم نمی‌کند.
برای خدمات رمزارز، ریسک‌ها می‌توانند شامل کنترل‌های برداشت، اعتبارنامه‌های API و جزئیات تراکنش نمایش داده شده به کاربران کیف پول باشند. یک وب‌سایت سازش شده به این معنی نیست که قوانین اجماع بیت‌کوین یا رمزنگاری یک بلاک‌چین شکسته شده است.
با نرم‌افزار پشتیبانی شده و وصله شده شروع کنید
به‌روزرسانی امنیتی، ۲۲ اکتبر ۲۰۲۶: مشاوره ۲۱ اکتبر PHP دو آسیب‌پذیری حیاتی اجرای کد از راه دور، CVE-2026-109618 و CVE-2026-109619 را شناسایی کرد. نسخه‌های رفع شده برای شاخه‌های پشتیبانی شده PHP 8.5.12، 8.4.27، 8.3.36 و 8.2.35 بودند. تیم PHP از کاربران خواست تا به‌روزرسانی کنند؛ کاهش موقت جایگزین کاملی برای وصله کردن نیست. اعلامیه امنیتی رسمی و راهنمایی ارائه‌دهنده هاست خود را بررسی کنید.
از نسخه رفع شده قابل اجرا یا نسخه پایدار وصله شده بعدی استفاده کنید. فروشندگان توزیع ممکن است اصلاحات امنیتی را به صورت پشتیبان اعمال کنند، بنابراین وضعیت مشاوره بسته را تأیید کنید و فقط به رشته نسخه آن قضاوت نکنید. تأیید کنید که زمان اجرای وب‌سرور — نه فقط PHP خط فرمان — به‌روز شده و کارگران مربوطه مجدداً راه‌اندازی شده‌اند.
همچنین یک برنامه ارتقاء را حفظ کنید. پشتیبانی امنیتی بالادستی PHP 8.2 در ۳۱ دسامبر ۲۰۲۶ به پایان می‌رسد؛ دریافت این وصله خاص، چرخه عمر پشتیبانی عادی آن را تمدید نمی‌کند.
تزریق SQL: داده‌ها را از ساختار کوئری خارج نگه دارید
تزریق SQL زمانی اتفاق می‌افتد که ورودی غیرقابل اعتماد بخشی از یک دستور پایگاه داده می‌شود. رفع اصلی این است که مقادیر داده را از طریق دستورات آماده شده پیوند دهید به جای اینکه ورودی کاربر را به رشته‌های SQL متصل کنید. مستندات PDO PHP جداسازی را توضیح می‌دهد.
به عنوان مثال، یک جستجوی مقاله خصوصی می‌تواند هم شناسه مقاله تأیید شده و هم شناسه کاربر احراز هویت شده در سمت سرور را پیوند دهد:
$stmt = $pdo->prepare(
'SELECT id, title FROM articles
WHERE id = :id AND owner_id = :owner'
);
$stmt->execute([
'id' => $articleId,
'owner' => $authenticatedUserId,
]);نگهدارنده‌ها از مقادیر داده محافظت می‌کنند، نه نام‌های دلخواه جدول، نام ستون یا جهت‌های مرتب‌سازی. این انتخاب‌ها را به مقادیر ثابت و مجاز نگاشت کنید. همچنین امتیازات پایگاه داده را محدود نگه دارید: برنامه به ندرت به حسابی نیاز دارد که بتواند کل پایگاه داده را مدیریت کند.
اسکریپت‌نویسی متقاطع سایت: برای زمینه خروجی کدگذاری کنید
اسکریپت‌نویسی متقاطع سایت، یا XSS، زمانی رخ می‌دهد که محتوای غیرقابل اعتماد به عنوان محتوای قابل اجرای مرورگر تفسیر می‌شود. یک نظر، فیلد پروفایل یا سند وارد شده می‌تواند خطرناک شود زمانی که یک صفحه آن را به درستی نمایش نمی‌دهد.
از خروجی خودکار چارچوب خود استفاده کنید و داده‌های غیرقابل اعتماد را از زمینه‌های اجرایی دور نگه دارید. برای متن ساده قرار داده شده بین تگ‌های HTML معمولی، htmlspecialchars() PHP با مدیریت صریح UTF-8 ابزار مناسبی است. این یک راه‌حل جهانی برای جاوا اسکریپت، CSS یا URLها نیست.
اگر کاربران نیاز به ارسال HTML غنی دارند، از یک پاک‌کننده HTML مبتنی بر لیست مجاز و نگهداری شده استفاده کنید به جای اینکه کل ورودی را مورد اعتماد بدانید. یک سیاست امنیتی محتوا لایه دیگری اضافه می‌کند؛ جایگزین رسیدگی صحیح به محتوا نمی‌شود. این تمایزها در راهنمای پیشگیری از XSS OWASP پوشش داده شده‌اند.
آپلودها و مدیریت فایل: آنچه سرور می‌پذیرد را کنترل کنید
یک ویژگی آپلود نباید به کاربر اجازه دهد تا تصمیم بگیرد کدام فایل اجرایی روی سرور ظاهر شود. فقط انواع فایل مورد نیاز محصول را مجاز کنید، محتوا را بررسی کنید به جای اینکه نوع MIME اعلام شده توسط مرورگر را باور کنید، محدودیت‌های اندازه را اعمال کنید و نام‌های فایل سمت سرور را تولید کنید.
آپلودهای غیرقابل اعتماد را خارج از ریشه وب یا در فضای ذخیره‌سازی جداگانه، با بازیابی کنترل شده، ذخیره کنید. اطمینان حاصل کنید که پیکربندی سرویس‌دهنده نمی‌تواند محتوای آپلود شده را اجرا کند. احراز هویت، مجوز و بازرسی مناسب بدافزار یا محتوا، حفاظت‌های اضافی را فراهم می‌کنند. راهنمای آپلود فایل OWASP ترکیب این کنترل‌ها را توصیه می‌کند.
همین نظم را برای مسیرهای فایل و واردات اعمال کنید. شناسه‌های سند رو به کاربر را به فایل‌های تأیید شده سمت سرور نگاشت کنید به جای اینکه مقادیر درخواست خام را به توابع گنجاندن فایل منتقل کنید. از تغذیه ورودی غیرقابل اعتماد به دستورات شل، یا deserialization شیء PHP خودداری کنید. APIهای امن‌تر و فرمت‌های داده تأیید شده نیاز به این عملیات خطرناک را کاهش می‌دهند.
احراز هویت، جلسات و CSRF نیاز به کنترل‌های جداگانه دارند
احراز هویت مشخص می‌کند که کاربر کیست؛ مجوز تصمیم می‌گیرد که آن کاربر چه کاری می‌تواند انجام دهد. یک صفحه ورود کارآمد اثبات نمی‌کند که رکوردهای حساب، دانلودها یا اقدامات مدیریتی محافظت شده‌اند. برای هر عملیات و شیء حساس، مجوزها را در سرور بررسی کنید.
از توابع مدیریت رمز عبور تأسیس شده مانند password_hash() و password_verify() استفاده کنید، حساب‌های ممتاز را با MFA محافظت کنید و تلاش‌های ورود ناموفق را محدود کنید. برای جلسات، HTTPS را اجباری کنید، ویژگی‌های کوکی مناسب Secure، HttpOnly و SameSite را پیکربندی کنید، شناسه‌های جلسه را پس از احراز هویت یا تغییرات امتیاز مجدداً صادر کنید و جلسات را هنگام خروج نامعتبر کنید. از راهنمای مدیریت جلسه OWASP پیروی کنید به جای اختراع یک طرح جلسه سفارشی.
درخواست‌های تغییر وضعیت با احراز هویت کوکی نیز به حفاظت CSRF نیاز دارند. پیاده‌سازی نگهداری شده چارچوب را ترجیح دهید، از جمله اعتبارسنجی توکن سمت سرور در صورت لزوم. کوکی‌های SameSite دفاع مفیدی در عمق هستند، اما نباید فرض کرد که از هر استقرار یا جریان درخواست محافظت می‌کنند. از درخواست‌های GET برای انجام تغییرات وضعیت حساس استفاده نکنید.
پیکربندی و وابستگی‌ها بخشی از برنامه هستند
یک کنترلر خوش‌نوشته می‌تواند همچنان در یک استقرار ناامن قرار گیرد. اعتبارنامه‌ها، کلیدهای خصوصی، اسرار پیکربندی و پشتیبان‌ها را از دایرکتوری‌های عمومی دور نگه دارید. نمایش خطای دقیق را در تولید غیرفعال کنید در حالی که لاگ‌های کنترل شده دسترسی را حفظ می‌کنید که به بررسی شکست‌ها بدون جمع‌آوری اسرار غیرضروری کمک می‌کنند.
موجودی کامل وابستگی‌ها را مرور کنید: زمان اجرای PHP، افزونه‌ها، چارچوب، CMS، پلاگین‌ها و بسته‌های Composer. دستور audit Composer می‌تواند مسائل امنیتی گزارش شده در وابستگی‌ها را شناسایی کند، اما نمی‌تواند گواهی دهد که منطق برنامه سفارشی ایمن است.
به‌روزرسانی‌ها را در برابر برنامه آزمایش کنید و به طور قابل تکرار از نسخه‌های وابستگی بررسی شده مستقر کنید. اجزای استفاده نشده را حذف کنید به جای اینکه آن‌ها را برای همیشه در معرض دید قرار دهید. مجوزهای سیستم فایل را محدود کنید تا یک فرآیند برنامه نتواند همه چیز را روی سرور بازنویسی کند و ابزارهای توسعه را از تولید جدا کنید.
آسیب‌پذیری‌های PHP چگونه می‌توانند بر وب‌سایت‌های رمزارز تأثیر بگذارند
لایه برنامه یک وب‌سایت رمزارز می‌تواند جدا از بلاک‌چین متصل به آن مورد حمله قرار گیرد. موارد زیر سناریوهای ریسک معماری هستند، نه یافته‌هایی در مورد هیچ صرافی یا کیف پول نام‌گذاری شده.
| ریسک رمزارز | چه چیزی می‌تواند اشتباه پیش برود | کنترل عملی |
|---|---|---|
| سوء استفاده از حساب امانی یا برداشت | جلسات ربوده شده یا مجوز ضعیف سمت سرور | اقدامات حساس را مجدداً احراز هویت کنید و تأیید را به گیرنده و مبلغ دقیق پیوند دهید. |
| فریب آدرس واریز یا امضا | محتوای صفحه وب تغییر یافته یا توضیحات تراکنش گمراه‌کننده | شبکه، گیرنده، دارایی و مبلغ را در یک رابط کیف پول مورد اعتماد یا نمایشگر کیف پول سخت‌افزاری قابل خواندن تأیید کنید. |
| قرار گرفتن اعتبارنامه‌های API در معرض | کلیدهای فاش شده از طریق کد، لاگ‌ها یا فایل‌های عمومی | کلیدها را در سمت سرور نگه دارید، مجوزها را به طور محدود دامنه بندی کنید، در صورت عدم نیاز حقوق برداشت را حذف کنید و اعتبارنامه‌های فاش شده را بچرخانید. |
محافظت از یک کلید خصوصی به طور خودکار از تصمیم استفاده از آن محافظت نمی‌کند. راهنمای امضای شفاف Trezor توضیح می‌دهد که چرا یک فرانت‌اند سازش شده می‌تواند یک تراکنش را به اشتباه توصیف کند. درخواست‌هایی را که نمی‌توانید به طور معنی‌داری تأیید کنید، تأیید نکنید، یا عبارت کلیدی را در وب‌سایتی که ادعا می‌کند نیاز به به‌روزرسانی امنیتی دارد، وارد نکنید.
وصله یا تغییر کد مربوطه را اعمال کنید، سپس هم کنترل امنیتی و هم رفتار عادی کاربر را آزمایش کنید. تست‌های منفی را شامل کنید: کاربر نباید صرفاً با تغییر یک شناسه به رکورد شخص دیگری دسترسی پیدا کند. تست‌های امنیتی را فقط در برابر سیستم‌هایی که متعلق به شما هستند یا به صراحت مجاز به ارزیابی آن‌ها هستید، اجرا کنید.
اگر سازش مشکوک است، وصله کردن تنها بخشی از بازیابی است. حادثه را مهار کنید، شواهد مفید را حفظ کنید، پایداری و اعتبارنامه‌های در معرض خطر را بررسی کنید و از یک وضعیت پاک تأیید شده بازیابی کنید. یک قانون فایروال یا نتیجه اسکنر پاک نشان نمی‌دهد که دسترسی مهاجم حذف شده است.
سوالات متداول
آیا PHP ذاتاً ناامن است؟
خیر. ریسک به نسخه زمان اجرا، طراحی برنامه، وابستگی‌ها و استقرار بستگی دارد. برنامه‌های PHP همچنان به نگهداری امنیتی معمول نیاز دارند.
آیا ارتقاء PHP تزریق SQL و XSS را برطرف می‌کند؟
لزوماً نه. به‌روزرسانی‌های زمان اجرا، آسیب‌پذیری‌های زمان اجرا را برطرف می‌کنند؛ ساختار کوئری ناامن و مدیریت خروجی به طور کلی نیاز به تغییرات برنامه دارند.
آیا HTTPS از آسیب‌پذیری‌های PHP جلوگیری می‌کند؟
خیر. HTTPS از داده‌ها در حال انتقال محافظت می‌کند. این مجوزهای شکسته، آپلودهای ناامن یا کد سمت سرور آسیب‌پذیر را اصلاح نمی‌کند.
آیا فایروال برنامه وب می‌تواند جایگزین وصله کردن شود؟
خیر. ممکن است برخی از ریسک‌ها را کاهش دهد، اما نمی‌تواند نقص نرم‌افزار یا منطق برنامه زیربنایی را به طور قابل اعتماد ترمیم کند.
نتیجه‌گیری
آسیب‌پذیری‌های PHP یک رفع جهانی ندارند. زمان اجرا و وابستگی‌ها را وصله کنید، مقادیر پایگاه داده را از SQL جدا نگه دارید، خروجی مرورگر را به طور ایمن مدیریت کنید، آپلودها را محدود کنید و کنترل‌های دسترسی سمت سرور را اجرا کنید.
برای برنامه‌های رمزارز، همچنین مجوز برداشت، اعتبارنامه‌های API و جزئیات تراکنش رو به کیف پول را محافظت کنید. هر ضعف را با کنترل مناسب مطابقت دهید و پس از استقرار آن کنترل را تأیید کنید. به‌روزرسانی‌ها، کدنویسی امن و نظارت عملیاتی با هم کار می‌کنند؛ هیچ کدام جایگزین دیگری نمی‌شود.
