كوكيز المصادقة في ووردبريس: البنية التشفيرية، علامات الأمان، وسرقة الجلسات

الكوكيز الأربعة الأساسية في ووردبريس: خريطة الهوية

ووردبريس مش بيستخدم كوكي واحدة وخلاص؛ النواة بتولد 4 كوكيز متخصصة، كل كوكي ليها دور وسياق أمني محدد:

التشريح التشفيري لسلسلة الكوكي (Under the Hood)

لو فتحت أدوات المطورين في المتصفح (DevTools -> Application -> Cookies)، وبصيت على قيمة كوكي wordpress_sec_...، هتلاقي نص طويل مفصول بعلامة | بالشكل ده:

mohamed|1735689600|a8f9c1d2e3b4...|9f8e7d6c5b4a...

تعال نفكك مكونات هذا النص التشفيري الأربعة كما تولدها دالة wp_generate_auth_cookie() في ملف wp-includes/pluggable.php:

1. اسم المستخدم (Username)

اسم المستخدم الصريح المسجل في قاعدة البيانات (مثل mohamed). ووردبريس بيقرأه أولاً عشان يعرف هو بيبحث عن مين في جدول wp_users.

2. تاريخ انتهاء الصلاحية (Expiration Timestamp)

الوقت بالثواني (Unix Timestamp) الذي تنتهي عنده صلاحية الكوكي.
افتراضياً، الكوكي مدتها **يومان (48 ساعة)**، ولكن لو المستخدم علم على مربع **”تذكرني” (Remember Me)** أثناء الدخول، بتتمدد الصلاحية تلقائياً لـ **14 يوماً** كاملة.

3. توكن الجلسة المشفر (Session Token)

رمز عشوائي بطول 64 محرفاً تم توليده وتخزينه كهاش في جدول wp_usermeta تحت مفتاح session_tokens. هذا الرمز يمثل الجهاز والمتصفح الحالي تحديداً.

4. توقيع الـ HMAC الرقمي (Message Authentication Code)

وده صمام الأمان الرياضي الأهم في الكوكي بالكامل!
ووردبريس بيعمل توقيع مشفر يدمج: اسم المستخدم + تاريخ الانتهاء + توكن الجلسة + الأملاح التشفيرية المشفرة في wp-config.php (مثل SECURE_AUTH_KEY و SECURE_AUTH_SALT).

لماذا يستحيل تزوير الكوكي؟
لو المخترق فتح المتصفح وعدل تاريخ الانتهاء من 2026 إلى 2030، أو غير اسم المستخدم من ahmed إلى admin، دالة wp_validate_auth_cookie() في السيرفر هتعيد حساب توقيع الـ HMAC؛ ولأن الهاش الجديد مش هيتطابق مع التوقيع، السيرفر هيكتشف التلاعب فوراً ويلغي الكوكي ويطرد الهاكر في جزء من الميكروثانية!

علامات الأمان الثلاث في الكوكيز: الحصون الرقمية

عشان الكوكي تكون منيعة ضد السرقة، في 3 علامات أمان أساسية (Cookie Flags) لازم يتم ضبطها في ترويسة Set-Cookie القادمة من السيرفر:

1. علامة HttpOnly (الدرع ضد ثغرات XSS)

العلامة دي بتقول للمتصفح:
*”الكوكي دي مخصصة لطلبات السيرفر فقط، وممنوع منعاً باتاً لأي كود جافاسكريبت في الصفحة إنه يقرأها عبر document.cookie!”*.
لو موقعك أصيب بثغرة XSS خبيثة، كود الهاكر مش هيعرف يسرق كوكي المصادقة طالما علامة HttpOnly مفعلة، وده بيحمي الجلسة من الاختطاف.

2. علامة Secure (الدرع ضد شبكات الواي فاي المفتوحة)

العلامة دي بتجبر المتصفح على عدم إرسال الكوكي إطلاقاً إلا إذا كان الاتصال مشفراً ببروتوكول **HTTPS (SSL/TLS)**.
لو المستخدم فاتح متصفحه من شبكة واي فاي عامة في كافيه، وفي هاكر بيتجسس على حزم البيانات (Packet Sniffing)، المتصفح هيرفض إرسال الكوكي عبر أي رابط غير مشفر، مما يمنع اعتراض الجلسة من الهواء.

3. علامة SameSite (الدرع المزدوج ضد CSRF)

العلامة دي بتحدد للمتصفح: هل يُسمح بإرسال الكوكي مع الطلبات التي تبدأ من مواقع خارجية؟

• SameSite=Strict: الكوكي لا تُرسل نهائياً إلا إذا كان المستخدم داخل نفس الموقع؛ لو ضغط على رابط خارجي موجه لموقعك، سيفتح كزائر غير مسجل!
• SameSite=Lax (الخيار الذهبي المتوازن): الكوكي تُرسل مع الروابط العادية المباشرة (Top-level Navigation)، ولكنها تُحظر تماماً في طلبات الـ POST والـ AJAX الموجهة عبر المواقع، مما يقضي على هجمات الـ CSRF بنسبة 99%.

كيف يحدث اختطاف الجلسات (Session Hijacking)؟

اختطاف الجلسة معناه إن الهاكر قدر يحصل على نسخة مطابقة لكوكي المصادقة النشطة الخاصة بالمدير بطريقة ما:

1. التنصت على الشبكات غير المشفرة (Packet Sniffing): استخدام أدوات مثل Wireshark في شبكات المقاهي المفتوحة لالتقاط الكوكيز غير المحمية بـ Secure.
2. البرمجيات الخبيثة على جهاز الضحية (Infostealers & Malware): فيروسات طروادة تستخرج ملفات الكوكيز مباشرة من مجلدات متصفحات Chrome و Edge في نظام التشغيل.
3. هجمات XSS المتطورة: استغلال كوكيز تفتقد لعلامة HttpOnly.

بمجرد ما الكوكي تقع في إيد الهاكر، ووردبريس افتراضياً هيتعامل معاه كأنه المدير الحقيقي!
عشان كده، المعمارية المتقدمة بتفرض نظام **حراسة سلوكية للجلسات (Session Anomaly Detection)**؛ بنفحص عنوان الـ IP والـ User Agent؛ فإذا دخلت الكوكي فجأة من دولة تانية أو متصفح مختلف تماماً عن اللي فتح الجلسة، النظام ينهي الجلسة فوراً ويطلب إعادة المصادقة!

الكود البرمجي الكامل: نظام حراسة كوكيز الجلسات والتصدي للاختطاف

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

 $this->getIpSubnet(),
            'user_agent' => $_SERVER['HTTP_USER_AGENT'] ?? 'UNKNOWN',
            'created_at' => time()
        ];

        update_user_meta($user->ID, $sessionMetaKey, $fingerprint);
    }

    /**
     * فحص سلامة الجلسة ومطابقتها للبصمة المسجلة لكشف الاختطاف
     */
    public function inspectSessionIntegrity(): void {
        if (!is_user_logged_in()) {
            return;
        }

        $userId = get_current_user_id();
        $token = function_exists('wp_get_session_token') ? wp_get_session_token() : '';
        if (empty($token)) {
            return;
        }

        $sessionMetaKey = 'session_fp_' . md5($token);
        $storedFingerprint = get_user_meta($userId, $sessionMetaKey, true);

        if (!is_array($storedFingerprint)) {
            return; // جلسة قديمة لم تسجل بصمتها
        }

        $currentSubnet = $this->getIpSubnet();
        $currentAgent  = $_SERVER['HTTP_USER_AGENT'] ?? 'UNKNOWN';

        // فحص هل تغير المتصفح بشكل كامل؟ (دليل قاطع على سرقة الكوكي واستخدامها في متصفح آخر)
        $isAgentHijacked = ($currentAgent !== $storedFingerprint['user_agent']);

        if ($isAgentHijacked) {
            // رصد محاولة اختطاف مؤكدة! إنهاء الجلسة فوراً وتدمير التوكن
            $this->terminateHijackedSession($userId, $token);

            wp_die(
                'تنبيه أمني عاجل: تم إنهاء جلستك تلقائياً لرصد نشاط مشبوه وتغيير مفاجئ في بيئة المتصفح. يرجى تسجيل الدخول مجدداً.',
                'اختطاف الجلسة',
                ['response' => 403]
            );
        }
    }

    /**
     * تدمير الجلسة المخترقة وطرد المخترق من السيرفر
     */
    private function terminateHijackedSession(int $userId, string $token): void {
        // 1. حذف توكن الجلسة من ووردبريس
        $manager = WP_Session_Tokens::get_instance($userId);
        $manager->destroy($token);

        // 2. مسح بصمة الجلسة
        delete_user_meta($userId, 'session_fp_' . md5($token));

        // 3. مسح الكوكيز من المتصفح
        wp_clear_auth_cookie();

        // 4. تسجيل الحادث في اللوج الأمني
        error_log(sprintf('[SECURITY ALERT] Session Hijacking blocked for User ID: %d. Token destroyed.', $userId));
    }

    /**
     * جلب شبكة الـ IP الفرعية (Class C) لتفادي مشاكل تغير الـ IP الطفيف في شبكات الموبايل
     */
    private function getIpSubnet(): string {
        $ip = $_SERVER['REMOTE_ADDR'] ?? '127.0.0.1';
        $parts = explode('.', $ip);
        if (count($parts) === 4) {
            return $parts[0] . '.' . $parts[1] . '.' . $parts[2] . '.0';
        }
        return $ip;
    }

    /**
     * فرض ترويسات الأمان القصوى لكافة الكوكيز الصادرة
     */
    public function enforceCookieSecurityHeaders(bool $send): bool {
        // ضمان أن المتصفح يمنع إرسال الكوكيز في أي اتصال غير مشفر
        if (!is_ssl() && defined('FORCE_SSL_ADMIN') && FORCE_SSL_ADMIN) {
            wp_safe_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);
            exit;
        }
        return $send;
    }
}

دراسة حالة حقيقية: كارثة شركة العقارات بالتجمع الخامس

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

الوضع القديم:
الشركة كان عندها موقع ووردبريس رئيسي متصل بنظام CRM مخصص لإدارة طلبات العملاء وبيانات كبار المستثمرين ورجال الأعمال (VIP Clients) بأرقام تليفوناتهم وحجم ثرواتهم واستثماراتهم.
المبرمج كان رافع الموقع على بيئة تجريبية فرعية (Staging) لا تستخدم شهادة SSL (http://staging.realestate-eg.com) لتجربة ميزات جديدة، وكان مسجل دخوله بحساب المدير العام للموقع.

يوم الاختراق في كافيه المول الشهير:
مدير التسويق والمبيعات كان قاعد في كافيه مشهور بمول تجاري كبير في التجمع الخامس، وفاتح اللابتوب بتاعه ومتصل بشبكة الواي فاي المفتوحة والمجانية للكافيه.
المدير فتح صفحة الـ Staging عشان يراجع تقرير عميل.
ولأن الاتصال كان بـ HTTP العادي والكوكي مكنش عليها علامة Secure:
كان في شاب هاكر قاعد على ترابيزة تانية في نفس الكافيه، ومشغل برنامج Wireshark بيلتقط كل حزم البيانات في هواء الكافيه (Man-in-the-Middle Attack)!

الكارثة:
الهاكر التقط حزمة الـ HTTP واضحة بنص صريح (Plaintext)، ونسخ كوكي wordpress_logged_in_... وكوكي wordpress_sec_... الخاصة بالمدير!
الهاكر فتح متصفحه، وحط الكوكي في إضافة EditThisCookie، وفتح لوحة تحكم الـ CRM مباشرة بدون باسورد وبدون ما يدخل أي كود!
في خلال 25 دقيقة، الهاكر قام بتصدير قاعدة بيانات 12,500 عميل VIP، مع تفاصيل ممتلكاتهم وعناوينهم وأرقامهم السرية، وبدأ يتواصل مع الشركات المنافسة ويبيع البيانات بأكثر من 40,000 دولار!
الشركة اتعرضت لفضيحة تجارية مدوية وخسرت تعاقدات حصرية مع كبار المطورين العقاريين في مصر.

العلاج المعماري الشامل:
لما مسكنا التحقيق الجنائي والأمني:

1. فرض تشفير HTTPS إجباري وشامل بـ HSTS: تم تفعيل بروتوكول HTTP Strict Transport Security (HSTS) على كافة النطاقات الرئيسية والفرعية، مما يمنع المتصفح من فتح أي صفحة بـ HTTP نهائياً.
2. تفعيل الثابت الصارم FORCE_SSL_ADMIN: تم فرضه في wp-config.php لإجبار علامة Secure على كافة كوكيز الجلسات.
3. بناء نظام مراقبة البصمة (Session Guardian): تم تشغيل نظام فحص البصمة الذي بنيناه في هذا المقال؛ بحيث لو تم تسريب الكوكي وتم فتحها من متصفح مختلف أو IP خارج شبكة الشركة، يتم تدمير الجلسة فوراً وإلغاء التوكن.

النتيجة: تم تأمين المنصة بالكامل، وإغلاق كافة ثغرات تسريب الكوكيز في الهواء، وحصلت الشركة على بيئة سحابية فائقة التحصين.

الوصايا العشر لأمان كوكيز المصادقة في ووردبريس

1. فعل SSL إجبارياً على كامل الموقع: لا تترك أي صفحة تعمل بـ HTTP العادي، وافرض define('FORCE_SSL_ADMIN', true); في wp-config.php.
2. تأكد من علامة HttpOnly: لا تضع بيانات جلسات حساسة في كوكيز تقرؤها الجافاسكريبت لحمايتها من ثغرات XSS.
3. استخدم علامة Secure دائماً: اضمن أن المتصفح لا يرسل كوكيز المصادقة إلا عبر قنوات التشفير الآمنة HTTPS.
4. فعل SameSite=Lax: احمِ كوكيز موقعك من الاستغلال في هجمات التزوير عبر المواقع (CSRF).
5. احذر من شبكات الواي فاي العامة: درب فريقك على استخدام شبكات VPN مشفرة وتجنب فتح لوحات التحكم من مقاهي الإنترنت المفتوحة.
6. دمر التوكنات القديمة عند الخروج: استخدم wp_destroy_current_session() لضمان محو أثر الجلسة من السيرفر تماماً.
7. قيد صلاحية الكوكي بدون “تذكرني”: لا تفرط في تمديد عمر الكوكي؛ 48 ساعة كافية جداً لمعظم جلسات العمل الإدارية.
8. راقب شذوذ الجلسات (Session Anomalies): افحص تغير المتصفحات المفاجئ واعتبره مؤشراً قوياً على محاولة اختطاف الجلسة.
9. احمِ ملف wp-config.php: تسريب أملاح SECURE_AUTH_KEY يتيح للهاكرز توليد وفحص تواقيع HMAC للكوكيز خارج الموقع.
10. وفر ميزة تسجيل الخروج الشامل: اسمح لمستخدميك بإنهاء جلساتهم من كافة الأجهزة بضغطة زر واحدة عند الشك في أي اختراق.

كوكيز شبكات ووردبريس المتعددة (Multisite Network Cookies)

في بيئات ووردبريس متعددة المواقع (Multisite Network)، إدارة الكوكيز بتتحول لمعضلة معمارية تتطلب فهماً عميقاً لطريقة عمل نطاقات الويب:

1. الشبكات القائمة على مجلدات فرعية (Sub-directories) مقابل نطاقات فرعية (Sub-domains):

لو شبكتك بتعتمد على مسارات فرعية (مثل: example.com/cairo/ و example.com/alex/)، ووردبريس بيعين مسار الكوكي COOKIEPATH على الجذر /، وبالتالي جلسة المستخدم بتفضل مشتركة وسلسة عبر كافة المواقع.

أما لو كانت شبكتك بتعتمد على نطاقات فرعية مستقلة (مثل: cairo.example.com و alex.example.com)، فالمتصفح افتراضياً يرفض مشاركة الكوكيز بين النطاقات المختلفة!
هنا بيجي دور الثابت المعماري في wp-config.php:

define('COOKIE_DOMAIN', '.example.com');

لاحظ النقطة البادئة .؛ النقطة دي بتخبر المتصفح بأن يسمح بمشاركة كوكي المصادقة عبر النطاق الرئيسي وكافة النطاقات الفرعية التابعة له (Wildcard Cookie Sharing)، مما يتيح للمدير التنقل بين مواقع الشبكة بسلاسة وبجلسة دخول واحدة (Single Sign-On).

المخاطرة الأمنية لمشاركة نطاق الكوكي:

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

المصادقة عبر الكوكيز في واجهات الـ REST API

عندما يقوم تطبيق الواجهة الأمامية (مثل React أو Vue أو لوحة تحكم إضافتك بـ Gutenberg) بالتواصل مع واجهات الـ REST API في ووردبريس:

المتصفح يرسل كوكيز المصادقة wordpress_logged_in_... تلقائياً مع طلب الـ Fetch أو Axios.
ولكن ووردبريس كإجراء أمني حازم لمنع هجمات CSRF، **يرفض اعتماد الجلسة بمجرد وجود الكوكي وحدها**!
يجب على كود الجافاسكريبت إرفاق ترويسة X-WP-Nonce تحتوي على رمز Nonce صالح تم إنشاؤه عبر wp_create_nonce('wp_rest'):

// استدعاء REST API آمن يعتمد على كوكيز الجلسة مع النونس
fetch('/wp-json/my-enterprise/v1/update-profile', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-WP-Nonce': wpApiSettings.nonce // إجبار التوأمة بين الكوكي والنونس
    },
    body: JSON.stringify({ displayName: 'Mohamed Abozaid' })
});

نواة ووردبريس في كلاس WP_REST_Server تفحص الكوكي أولاً، ثم تفحص تطابق الـ Nonce مع الجلسة؛ فإذا نجح الاثنان معاً، يُعامل الطلب كطلب مصرح به من المستخدم المسجل بأعلى درجات الأمان.

إعدادات السيرفرات الوسيطة وشبكات CDN لتفادي كاش الجلسات

عندما تضع موقعك خلف شبكات توصيل المحتوى مثل Cloudflare أو Fastly أو Nginx Reverse Proxy، يجب عليك ضبط قواعد التخزين المؤقت بدقة فائقة:
إذا قامت شبكة الـ CDN بتخزين صفحة تحتوي على ترويسة Set-Cookie صادرة لمدير معين، فقد تقوم الشبكة بتوزيع هذه الكوكي على زوار آخرين، مما يؤدي إلى فضيحة أمنية تسرب حسابات المديرين للعامة!

القاعدة المعمارية:
اضبط إعدادات الـ CDN دائماً على تجاوز الكاش بالكامل (Bypass Cache) بمجرد اكتشاف أي كوكي تبدأ بـ wordpress_logged_in_ أو wordpress_sec_، وتأكد من حذف ترويسة Set-Cookie من الصفحات العامة المخبأة لضمان أقصى درجات الخصوصية والأمان لمستخدميك.