شناسایی SQL Injection فقط با دیدن یک خطا یا عبارت مشکوک در لاگ انجام نمی‌شود. باید مشخص شود ورودی کنترل‌نشده واقعاً توانسته ساختار پرس‌وجوی پایگاه داده را تغییر دهد یا فقط یک درخواست ناموفق بوده است. این تفاوت، مسیر رسیدگی و شدت رخداد را تعیین می‌کند.
شواهد لازم برای شناسایی SQL Injection
زمان رخداد، مسیر درخواست، نسخهٔ افزونهٔ مرتبط و پیام خطا را ثبت کنید. فایل error_log الزاماً در public_html نیست؛ محل و جزئیات ثبت لاگ به تنظیمات سرویس وابسته است. نبود خطا هم به معنی نبود آسیب‌پذیری نیست.
لاگ وب، خطای برنامه، هشدار WAF و تغییر غیرمجاز داده را کنار هم بررسی کنید. یک هشدار WAF می‌تواند تلاش مسدودشده باشد؛ از طرف دیگر، نبود هشدار تضمین ایمنی نیست. اطلاعات حساس و رمزها را در گزارش عمومی یا دیدگاه مقاله درج نکنید.
کدام بخش وردپرس باید بررسی شود؟
مسیر پردازش فرم، جستجو، پارامتر URL، درخواست API یا دادهٔ واردشده از سرویس دیگر را تا محل ساخت SQL دنبال کنید. مشکل فقط به ظاهر فرم وابسته نیست. داده‌ای که قبلاً ذخیره شده نیز هنگام استفادهٔ دوباره در پرس‌وجو باید درست مدیریت شود.
برای آزمون فنی، محیط آزمایشی و محدودهٔ مجاز مشخص داشته باشید. راهنمای آزمون OWASP مدل بررسی این آسیب‌پذیری را توضیح می‌دهد؛ اجرای اسکن یا ورودی آزمایشی روی سایت دیگران مجاز فرض نمی‌شود. در سایت عملیاتی، آزمون بی‌برنامه ممکن است داده یا سرویس را مختل کند.
نمونهٔ دفاعی در کد وردپرس
تا جای ممکن از APIهای مناسب وردپرس استفاده کنید. اگر پرس‌وجوی مستقیم لازم است، مقدار داده را با جای‌نگهدار مناسب به wpdb::prepare() بدهید. نمونهٔ زیر با فرض وجود مقدار متنی معتبر در متغیر email نوشته شده و فقط الگوی آماده‌سازی را نشان می‌دهد.
global $wpdb;
$user_id = $wpdb->get_var(
$wpdb->prepare(
"SELECT ID FROM {$wpdb->users} WHERE user_email = %s",
$email
)
);نام جدول در این نمونه از شیء وردپرس می‌آید، نه ورودی کاربر. مقدار ایمیل را قبل از prepare به رشتهٔ SQL نچسبانید. این مثال کنترل مجوز، اعتبارسنجی کاربردی و نحوهٔ نمایش نتیجه را پوشش نمی‌دهد؛ آماده‌سازی SQL جای آن‌ها را نمی‌گیرد.
کدام اقدامات کافی نیستند؟
- تغییر پیشوند wp_ آسیب‌پذیری کد را برطرف نمی‌کند.
- رمز قوی دیتابیس مانع SQL ناامنِ اجراشده توسط خود برنامه نمی‌شود.
- پنهان‌کردن خطا از بازدیدکننده، ساخت پرس‌وجو را اصلاح نمی‌کند.
- WAF می‌تواند لایهٔ کمکی باشد، اما جای وصلهٔ برنامه نیست.
- پاک‌سازی عمومی متن با تابعی نامرتبط، تضمین امنیت SQL نیست.
رفع علت و پیگیری نتیجه
نسخهٔ اصلاح‌شدهٔ افزونه یا کد را از منبع معتبر تهیه کنید و مسیر آسیب‌پذیر را در محیط کنترل‌شده دوباره بیازمایید. مجوز کاربر دیتابیس متناسب با نیاز برنامه باشد. کنترل ورود و نقش کاربر را هم جداگانه بررسی کنید، چون یک پرس‌وجوی امن هنوز می‌تواند داده را به فرد غیرمجاز بدهد.
اگر تغییر یا افشای داده تأیید شده، رسیدگی را به حذف خطای صفحه محدود نکنید. محدودهٔ داده و حساب‌های درگیر، سلامت نسخهٔ بازیابی و علت دسترسی باید مشخص شود. نتیجهٔ رفع را با شواهد ثبت کنید تا همان مسیر در نسخهٔ بعدی دوباره ناامن نشود.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
