تحصين استعلامات قواعد البيانات في ووردبريس: الحماية من SQL Injection وهندسة $wpdb->prepare

تشريح هجوم الـ SQL Injection: كيف يخدع المخترق محرك MySQL؟

عشان تحمي نفسك، لازم تفهم المهاجم بيفكر إزاي. محرك MySQL لما بيستلم جملة استعلام، بيقوم بتحليلها نحوياً (Parsing) لمعرفة: فين الأمر (Command) وفين القيمة (Data).

لو كتبت الاستعلام الهش ده:

users} WHERE user_email = '{$email}'";

المستخدم الطبيعي هيكتب: ahmed@example.com، فالاستعلام هيكون طبيعي.
لكن المخترق هيكتب في الحقل النص ده:

' OR '1'='1' --

تعال شوف الاستعلام هيتحول لإيه في بطن محرك MySQL:

SELECT * FROM wp_users WHERE user_email = '' OR '1'='1' -- ';

محرك قاعدة البيانات هيشوف الشرط '1'='1' وهو شرط صحيح دائماً (True)، وعلامة -- هتخلي السيرفر يتجاهل باقي الاستعلام كتعليق!
النتيجة: الاستعلام هيعيد أول مستخدم في جدول المستخدمين (اللي هو في 99% من الحالات المدير العام للموقع Administrator)، والمخترق هيدخل لوحة التحكم بدون ما يعرف كلمة السر أصلاً!

الهندسة الداخلية لدالة $wpdb->prepare() ومحددات التنسيق

دالة $wpdb->prepare() هي الدرع الحصين الأساسي في ووردبريس. وظيفتها تعقيم وتجهيز المعاملات قبل دمجها في الاستعلام.
الدالة بتستقبل جملة الاستعلام وبتحتوي على علامات نائبة (Placeholders)، وبعدين بتستقبل القيم بالترتيب:

محددات التنسيق المعتمدة:

1. المحدد %d (الأرقام الصحيحة – Integers): مخصص للمعرفات (IDs)، والكميات، وأرقام الصفحات. يحول أي مدخل إلى رقم صحيح بدقة متناهية (مثل 105).
2. المحدد %f (الأرقام العشرية – Floats): مخصص للأسعار، والضرائب، والأوزان، والنسب المئوية (مثل 49.99).
3. المحدد %s (السلاسل النصية – Strings): مخصص للأسماء، والإيميلات، والتواريخ، والكلمات المفتاحية. يقوم بهروب الرموز وإضافة علامات التنصيص تلقائياً.
4. المحدد %i (معرفات الجداول والأعمدة – Identifiers): تم تقديمه في **ووردبريس 6.2**! مخصص لأسماء الجداول وأسماء الحقول لتأمينها من الحقن عندما تكون متغيرة.

المناطق العمياء: أين تقف دالة prepare عاجزة؟

دالة $wpdb->prepare() عظيمة جداً مع القيم في جمل WHERE و VALUES، لكن في مناطق في الـ SQL **لا تدعم استخدام المحددات إطلاقاً**:

1. ترتيب النتائج (ORDER BY & ASC/DESC)

في لغة SQL، محرك الداتا بيز لا يسمح بوضع علامة نائبة مكان اسم العمود في ORDER BY أو مكان اتجاه الترتيب (ASC أو DESC)!
لو كتبت:

$wpdb->prepare("SELECT * FROM orders ORDER BY %s %s", $column, $order); // فشل كامل!
الاستعلام هيتحول لـ:

ORDER BY 'date' 'DESC'
وده استعلام خاطئ نحوياً في MySQL ولن يعمل!

الحل المعماري الحتمي: القائمة البيضاء الصارمة (Strict Whitelisting):

 'created_at',
    'price'  => 'total_amount',
    'status' => 'order_status'
];

$sortInput = $_GET['orderby'] ?? 'date';
$sortColumn = $allowedColumns[$sortInput] ?? 'created_at'; // لو غير موجود، استخدم الافتراضي

// اتجاه الترتيب
$orderInput = strtoupper($_GET['order'] ?? 'DESC');
$sortDirection = in_array($orderInput, ['ASC', 'DESC'], true) ? $orderInput : 'DESC';

// الآن دمج آمن 100% لأن القيم خرجت من قائمة بيضاء مغلقة
$sql = "SELECT * FROM {$wpdb->prefix}orders ORDER BY {$sortColumn} {$sortDirection}";

2. المصفوفات المتغيرة في جمل IN (…)

لو عندك مصفوفة فيها معرفات متعددة قادمة من صناديق الاختيار (Checkboxes)، وعايز تستعلم عن:

WHERE id IN (12, 15, 88, 99)
مش هينفع تمرر المصفوفة كـ %s!

الحل المعماري: توليد العلامات النائبة ديناميكياً:

prepare(
        "SELECT * FROM {$wpdb->prefix}orders WHERE id IN ({$placeholders})",
        $cleanIds
    );
}

3. البحث بـ LIKE وهروب الرموز الخاصة عبر esc_like()

في استعلامات البحث LIKE '%keyword%'، علامات النسبة المئوية % والشرطة السفلية _ بتعتبر رموز مطابقة (Wildcards) في لغة SQL.
لو المستخدم بحث عن كلمة فيها % أو _ (زي مثلاً كود خصم SALE_50%)، الاستعلام هيتلخبط وممكن يستهلك موارد السيرفر بالكامل!

ووردبريس بيوفر دالة مخصصة لحل المعضلة دي اسمها $wpdb->esc_like():

esc_like($searchTerm) . '%';

// ثم استخدام %s العادية داخل prepare
$sql = $wpdb->prepare(
    "SELECT * FROM {$wpdb->prefix}clients WHERE client_name LIKE %s OR client_company LIKE %s",
    $wildcardSearch,
    $wildcardSearch
);

التطبيق البرمجي العملي: محرك بحث مالي ومحاسبي فائق التحصين

تعال نشوف كود إنتاجي متكامل لبناء استعلام بحث معقد وفلاتر متعددة لقاعدة بيانات مالية مع الالتزام بأعلى معايير الحماية من SQL Injection:

db->prefix . 'financial_ledger';

        // 1. الشروط الأساسية الثابتة
        $whereConditions = ['1=1'];
        $queryParameters = [];

        // 2. فلتر البحث النصي بالاسم أو البيان باستخدام LIKE و esc_like
        if (!empty($filters['search'])) {
            $whereConditions[] = '(reference_code LIKE %s OR description LIKE %s)';
            $wildcard = '%' . $this->db->esc_like((string)$filters['search']) . '%';
            $queryParameters[] = $wildcard;
            $queryParameters[] = $wildcard;
        }

        // 3. فلتر حالة المعاملة باستخدام القائمة البيضاء (Strict Whitelisting)
        if (!empty($filters['status'])) {
            $validStatuses = ['pending', 'cleared', 'cancelled', 'refunded'];
            if (in_array($filters['status'], $validStatuses, true)) {
                $whereConditions[] = 'status = %s';
                $queryParameters[] = $filters['status'];
            }
        }

        // 4. فلتر النطاق المالي (Min & Max Amount) باستخدام %f
        if (isset($filters['min_amount']) && is_numeric($filters['min_amount'])) {
            $whereConditions[] = 'amount >= %f';
            $queryParameters[] = (float) $filters['min_amount'];
        }

        if (isset($filters['max_amount']) && is_numeric($filters['max_amount'])) {
            $whereConditions[] = 'amount  'transaction_date',
            'amount' => 'amount',
            'id'     => 'id'
        ];
        $sortKey = $filters['sort_by'] ?? 'date';
        $orderBy = $allowedSortColumns[$sortKey] ?? 'transaction_date';

        $orderDir = strtoupper($filters['order_dir'] ?? 'DESC');
        $direction = in_array($orderDir, ['ASC', 'DESC'], true) ? $orderDir : 'DESC';

        // 7. التقسيم إلى صفحات (Pagination) بأمان
        $page = max(1, absint($filters['page'] ?? 1));
        $perPage = min(100, max(1, absint($filters['per_page'] ?? 20)));
        $offset = ($page - 1) * $perPage;

        // 8. بناء الاستعلام النهائي
        $whereSql = implode(' AND ', $whereConditions);
        $fullSql = "SELECT * FROM `{$tableName}` WHERE {$whereSql} ORDER BY `{$orderBy}` {$direction} LIMIT %d OFFSET %d";

        $queryParameters[] = $perPage;
        $queryParameters[] = $offset;

        // 9. التنفيذ الآمن عبر prepare
        $preparedSql = $this->db->prepare($fullSql, $queryParameters);

        return $this->db->get_results($preparedSql, ARRAY_A) ?: [];
    }
}

دراسة حالة حقيقية: كارثة متجر المجوهرات بالصاغة

عشان تعرف حجم الكارثة الحقيقية لثغرات SQL Injection، هشاركك قصة واقعية حصلت مع متجر مجوهرات وذهب شهير جداً مقره في حي الصاغة بالقاهرة الفاطمية وعنده متجر إلكتروني لبيع السبائك والمشغولات الذهبية أونلاين:

الوضع القديم:
المتجر كان مركب إضافة مخصصة لحساب أسعار المصنعية وفلترة المشغولات حسب العيار والوزن والسعر.
المبرمج اللي عمل الإضافة، كتب كود فلتر الأسعار بالشكل ده:

$min = $_GET['min_price'];
$sql = "SELECT * FROM {$wpdb->prefix}gold_items WHERE price >= " . $min;
المبرمج برر ده وقال: “ما الحقل ده في الفرونت إند معمول type='number'، فمستحيل يدخل فيه حروف!”.

يوم الهجوم الأسود:
أحد قراصنة الإنترنت فتح أداة التيرمينال وبدأ يفحص المتجر. فحص صفحة الفلتر وعرف إن القيمة بتروح في الـ GET بدون أي تحضير أو تعقيم على السيرفر!
الهاكر استخدم أداة SQLMap ومرر الرابط المصاب:

https://example.com/?min_price=1000%20UNION%20SELECT%20user_login,user_pass,user_email%20FROM%20wp_users--

الكارثة والابتزاز:
في أقل من 15 دقيقة، الهاكر نزل قاعدة البيانات بالكامل، وشملت:

• بيانات 8,500 عميل اشتروا سبائك ذهبية، مع عناوين منازلهم التفصيلية وأرقام هواتفهم!
• سجلات الخزنة والمخزون الحقيقي من الذهب الموجود في مقر المتجر بالصاغة!
• هاش كلمة مرور المدير العام للموقع.

الهاكر تواصل مع صاحب المتجر على الواتساب، وبعت له عينة من عناوين عملاء اشتروا سبائك بوزن كيلوجرامات، وهدده بنشر العناوين على الإنترنت وإبلاغ عصابات السطو لو مدفعش فدية قدرها 3 بيتكوين (تتجاوز 3 ملايين جنيه مصري)!
صاحب المتجر عاش كابوساً حقيقياً وتواصل مع الإدارة العامة لتكنولوجيا المعلومات ومباحث الإنترنت، وتم استدعائي كخبير معماري للتعامل مع الموقف التقني.

خطة التأمين والعلاج الحاسم:

1. إغلاق الثغرة في 5 دقائق: تم تحويل استعلام السعر إلى $wpdb->prepare("... WHERE price >= %f", (float)$min);.
2. تدقيق كامل لكافة استعلامات الموقع (Full Codebase Audit): قمنا بمسح أكثر من 45 استعلام SQL مباشر في كافة ملفات الإضافات والقوالب، وتحويلها بالكامل إلى Prepared Statements.
3. تغيير كافة مفاتيح التشفير وجلسات المستخدمين: تم تصفير كافة جلسات الموقع وتغيير أملاح ووردبريس (WordPress Salts) في ملف wp-config.php لإبطال أي جلسات مسروقة.

النتيجة: تم إغلاق الثغرة تماماً، وحماية بيانات العملاء، وضبط أمان الموقع بأعلى معايير التشفير لمنع تكرار أي محاولة حقن مستقبلاً.

الوصايا العشر لمنع SQL Injection في ووردبريس

1. لا تدمج النصوص في SQL أبداً: إياك واستخدام علامة النقطة . لدمج أي متغير داخل استعلام قاعدة البيانات.
2. استخدم $wpdb->prepare لكل استعلام يحتوي على متغيرات: اجعلها قاعدة إجبارية لا استثناء فيها في كل سطر كود SQL تكتبه.
3. لا تضع علامات تنصيص حول %s: تذكر أن prepare() هي المسؤولة عن إضافة الـ Quotes للسلاسل النصية تلقائياً.
4. طهر وافحص الترتيب بالقوائم البيضاء (Whitelisting): جمل ORDER BY و ASC/DESC لا تدعم العلامات النائبة، فافحصها بقائمة بيضاء صلبة.
5. استخدم $wpdb->esc_like للبحث: هرب المحارف المشبوهة في استعلامات LIKE قبل تمريرها لـ prepare().
6. بناء علامات IN (…) بدقة: استخدم array_fill و implode لتوليد مصفوفة من محددات %d لحماية مصفوفات المعرفات.
7. استخدم توابع $wpdb المخصصة (insert/update/delete): دوال $wpdb->insert() و update() تقوم بالتحضير والتعقيم التلقائي وتغنيك عن كتابة SQL يدوي.
8. احذر من الثقة في type=’number’: تذكر أن قيود الفرونت إند في المتصفح يمكن للمخترق تعديلها وتجاوزها في ثانية واحدة، والحماية تبدأ من السيرفر.
9. استخدم أدوات التدقيق الأمني الآلي (PHPCS & WPCS): أداة WordPress Coding Standards ستنبهك برمز خطأ أحمر عريض إذا نسيت استخدام prepare() في أي استعلام.
10. درب فريقك على عقلية الهاكر: فكر دائماً كيف يمكن استغلال هذا الحقل لكسر الاستعلام، فهذا التفكير هو الضمانة الحقيقية لبناء برمجيات متينة.

الحقن من الدرجة الثانية (Second-Order SQL Injection): الفخ الماكر

واحدة من أذكى وأخطر صور هجمات قواعد البيانات هي ما يعرف بـ **Second-Order SQL Injection** (الحقن من الدرجة الثانية).
في الهجوم ده، المخترق مش بيهجم على الاستعلام الأول بشكل مباشر؛ بل بيسجل بيانات خبيثة في قاعدة البيانات من خلال شاشة تسجيل عادية ومحمية بـ prepare()!

تخيل إن المستخدم سجل اسمه في الموقع كـ:

admin' --

الاستعلام الأول حفظ الاسم في قاعدة البيانات بأمان كقيمة نصية عادية.
الكارثة بتحصل بعدين لما يجي مبرمج الإضافة يعمل شاشة تقارير إدارية، ويسترجع اسم المستخدم من الداتا بيز، ويفترض إنه “بيان آمن وموثوق لأنه جاي من قاعدة البيانات الخاصة بنا!”، فيقوم بدمجه في استعلام تالي بدون prepare():

user_login; // قيمته admin' -- 

// المبرمج دمج النص معتقداً أنه آمن لأنه قادم من قاعدة البيانات
$auditSql = "SELECT * FROM {$wpdb->prefix}audit_logs WHERE actor = '{$storedUsername}'";
$wpdb->query($auditSql);

الاستعلام التاني انهار في فخ الحقن واشتغل كود المخترق!
القاعدة المعمارية: لا تثق حتى في البيانات المخزنة داخل قاعدة بياناتك الخاصة؛ فكل قيمة يتم دمجها في أي استعلام SQL يجب أن تمر حصرياً عبر $wpdb->prepare() بغض النظر عن مصدرها الأصلي.

تنفيذ الإدراج المجمع (Bulk Inserts) بأمان وسرعة فائقة

لو عندك إضافة متجر بتستورد 1,000 منتج أو بتسجل 500 حركة دفع دفعة واحدة من ملف إكسيل، تنفيذ $wpdb->insert() في حلقة تكرار 500 مرة هيخنق قاعدة البيانات ويأخذ وقتاً طويلاً جداً.

الحل الأمثل في الأداء هو تجميع كل الصفوف في استعلام INSERT واحد مجمع (Bulk Insert)، ولكن كيف نؤمنه ضد الحقن باستخدام $wpdb->prepare()؟
تعال نشوف الطريقة الهندسية القياسية:

prefix . 'financial_records';
    $rowPlaceholders = [];
    $values = [];

    foreach ($records as $record) {
        // لكل صف نحدد نمط المحددات (%d, %s, %f, %s)
        $rowPlaceholders[] = '(%d, %s, %f, %s)';
        $values[] = absint($record['account_id']);
        $values[] = sanitize_text_field($record['description']);
        $values[] = (float) $record['amount'];
        $values[] = current_time('mysql');
    }

    // تجميع مصفوفة الصفوف
    $sql = "INSERT INTO `{$tableName}` (`account_id`, `description`, `amount`, `created_at`) VALUES " 
         . implode(', ', $rowPlaceholders);

    // تحضير الاستعلام المجمع دفعة واحدة وتمرير مصفوفة القيم المسطحة
    $preparedSql = $wpdb->prepare($sql, $values);

    return (int) $wpdb->query($preparedSql);
}

بهذه الطريقة، تقوم بإدخال آلاف الصفوف في استعلام واحد يستغرق أجزاء من الثانية، مع تحصين كامل وشامل لكل حقل ولكل سطر ضد أي محاولة للحقن البرمجي.

محاكاة الاستعلامات في ووردبريس مقابل PDO Native Prepared Statements

من الحقائق التقنية الممتعة التي يجهلها الكثير من المطورين هي أن دالة $wpdb->prepare() لا تقوم بإنشاء Prepared Statement حقيقي على مستوى بروتوكول اتصال MySQL في السيرفر (Server-side Prepared Statement)، بل تقوم بما يسمى **محاكاة التحضير (Emulated Prepared Statements)** داخل كود الـ PHP نفسه عبر دوال التهريب وتركيب النصوص بنمط vsprintf!

ووردبريس اختار هذا التصميم الهندسي منذ بداياته لتحقيق أقصى درجات التوافق مع كافة بيئات الاستضافة المشتركة والسيرفرات المتنوعة التي قد لا تدعم حزم الـ PDO المتقدمة بكفاءة.

العلاقة الحيوية بترميز المحارف (Character Encoding):
لكي تنجح محاكاة التحضير في حمايتك بنسبة 100%، يشترط أن يكون اتصال قاعدة البيانات يستخدم ترميز محارف آمن وموحد وهو utf8mb4 (الذي يعتمده ووردبريس افتراضياً). لو تم العبث بترميز الاتصال واستخدام ترميزات قديمة مثل GBK أو BIG5، قد تظهر ثغرات نادرة تسمى (Multi-byte Character Injection)؛ لذا فإن الحفاظ على إعدادات ووردبريس القياسية للترميز في ملف wp-config.php هو صمام أمان مكمل لا غنى عنه.