إزاي السيرفر “بيفتكرك” وسط آلاف المستخدمين

ليه المشكلة دي أصلاً موجودة؟

الـ HTTP بروتوكول Stateless — يعني كل طلب بيوصل السيرفر مقطوع الصلة تمامًا عن الطلب اللي قبله. لو سجّلت دخول في طلب، وبعتّ طلب تاني فورًا، السيرفر مش هيفتكر إنك سجلت دخول أصلاً، لأنه ببساطة مش بيحتفظ بأي “ذاكرة” بين الطلبات. المشكلة دي هي اللي فتحت الباب لظهور فكرة الـ Cookies والـ Sessions — طريقة تخلي السيرفر “يفتكرك” وسط آلاف الطلبات التانية اللي جاية من مستخدمين تانيين.

الـ Cookies

الـ Cookie هي ملف صغير بيخزّنه المتصفح بناءً على طلب السيرفر، بتُستخدم لحفظ الـ Session ID، إعدادات المستخدم، أو تتبّع سلوكه.

أنواع الكوكيز

  • Session Cookies: بتتمسح لما تقفل المتصفح.
  • Persistent Cookies: بتفضل موجودة لحد تاريخ انتهاء محدد.
  • Secure Cookies: بتتبعت بس على HTTPS.
  • Third-Party Cookies: بتتبعت لمواقع تانية غير اللي إنت فاتحه (زي شبكات الإعلانات).

الـ Cookie Attributes — كل واحدة منهم بتقفل باب هجوم معين

هنا بالظبط بيكون الفرق بين cookie آمنة وcookie قابلة للاستغلال. خلينا نمشي على كل Attribute ونفهم إيه الهجوم اللي بيمنعه بالظبط:

1. HttpOnly

لو مفعّلة، الـ JavaScript مش هيقدر يقرا الكوكيز دي عبر document.cookie. ده بيقفل باب مهم جدًا: حتى لو الموقع فيه ثغرة XSS، المهاجم مش هيقدر يسرق الـ session cookie مباشرة لأن الكود الخبيث نفسه مش هيقدر يشوفها. لاحظ إن ده مش بيمنع الـ XSS نفسه، بس بيقلل من الـ impact بتاعه على الكوكيز تحديدًا.

2. Secure

الكوكيز دي بتتبعت بس على اتصال HTTPS. لو مش موجودة، والموقع بيدعم HTTP جنب HTTPS، الكوكيز ممكن تنبعت مكشوفة على HTTP ويسرقها أي حد على الشبكة (Man-in-the-Middle).

3. SameSite

بيتحكم إذا كانت الكوكيز بتتبعت مع طلبات جاية من مواقع تانية (Cross-Site Requests):

  • Strict: الكوكيز مبتتبعتش خالص لو الطلب جاي من موقع تاني — حماية قوية من CSRF لكن ممكن تكسر تجربة استخدام معينة (زي لينك في إيميل بيوديك للموقع وإنت مش logged in).
  • Lax: بتتبعت مع GET requests بس لو جاية من مواقع تانية — دي القيمة الافتراضية الحديثة في معظم المتصفحات.
  • None: بتتبعت مع كل الطلبات بغض النظر عن المصدر، لكن لازم تكون Secure كمان. القيمة دي مطلوبة في سيناريوهات معينة زي تطبيقات بتستخدم iframe عبر دومينات مختلفة.

4. Domain

بيحدد نطاق الكوكيز. لو Domain=example.com، الكوكيز بتتبعت لكل الـ subdomains زي sub.example.com. المشكلة تظهر لو الـ Domain واسع جدًا، وواحد من الـ subdomains فيه ثغرة زي XSS — ممكن يسرق كوكيز الدومين الرئيسي كله.

5. Path

بيحدد أي جزء من الموقع الكوكيز بتتبعتله. لو مش محدد كويس، الكوكيز ممكن تتبعت لأماكن مش لازمها، زادت من سطح الهجوم بلا داعي.

6. Expires / Max-Age

بيحدد وقت انتهاء الكوكيز. لو الكوكيز ملهاش انتهاء أو مدتها طويلة جدًا وحد سرقها، هيقدر يستخدمها لفترة طويلة جدًا.

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=1800

الـ Session — إزاي السيرفر فعليًا بيربطك بهويتك

بعد ما تسجل دخول بنجاح، السيرفر بيعمل Session ليك بس، بتتخزن على السيرفر وليها Session ID فريد. الـ Session ID ده بيتبعت مع كل طلب جديد في الكوكيز، وبيبقى المرجع اللي السيرفر بيتأكد بيه إن الطلب ده جاي منك أنت تحديدًا.

PHPSESSID=3f84b87f5a2b9b9dbe99b6bff2e40cf8

إعدادات السيرفر بتحدد قوة نظام الـ Session بالكامل

1. توليد الـ Session ID

لازم يكون عشوائي وطويل بما فيه الكفاية (128-bit أو أكتر)، ومولّد بـ Cryptographically Secure Random Generator. لو الـ Session ID متوقع أو قصير (زي أرقام متسلسلة)، تقدر تجرب تخمينه بأداة زي Burp Sequencer اللي بتقيّم مدى عشوائية القيم دي إحصائيًا.

2. تخزين الـ Session (Session Storage)

  • Memory: سريع، بس بيتمسح لو السيرفر عمل restart.
  • Database: أبطأ، لكن بيحفظ الجلسات حتى لو السيرفر وقف.
  • Redis: حل وسط — سريع زي الـ Memory، ومستقر زي الـ Database لأنه بيقدر يحفظ نسخة على القرص.

لو لقيت Redis مفتوح على Port 6379 من غير Password، ده finding خطير جدًا — تقدر تدخل عليه بأدوات زي redis-cli أو حتى Nmap NSE scripts، وتقرا/تعدّل session data لأي مستخدم على النظام كله، وأحيانًا حتى تحصل على RCE لو الـ Redis instance غير محصّن (عن طريق كتابة SSH keys أو cron jobs).

3. Session Timeout

لازم الـ session تنتهي بعد فترة عدم نشاط (Idle Timeout) أو وقت كلي (Absolute Timeout). لو الـ Timeout طويل جدًا، وسرقت session ID، هتفضل تقدر تستخدمها لفترة أطول.

4. Session Regeneration

السيرفر لازم يغيّر الـ Session ID بعد أي حدث حساس زي Login أو تغيير Password. السبب: لو الـ Session ID القديم اتسرق قبل الحدث ده، الـ ID القديم يبقى ملهوش قيمة بعد التغيير. لو السيرفر ما بيعملش regeneration، الثغرة دي اسمها Session Fixation — المهاجم يقدر يفرض session ID معروف على الضحية (مثلًا عن طريق لينك فيه ?PHPSESSID=attacker_known_value)، وبعد ما الضحية تسجل دخول، المهاجم يستخدم نفس الـ ID المعروف عنده ويدخل بنفس صلاحيات الضحية من غير ما يحتاج يسرق أي حاجة أصلاً.

5. Secure Session Handling

السيرفر لازم يفحص كل طلب إن الـ Session ID صحيح ومرتبط بيوزر معين، ويربطها أحيانًا بـ Context إضافي زي IP Address أو User-Agent (Browser Fingerprinting) عشان يتأكد إن الكوكيز جاية من نفس الجهاز.