كيف تفحص أمان ملفات تعريف الارتباط: Secure و HttpOnly و SameSite وبادئات الأسماء

حين يسجّل أحدهم الدخول إلى موقعك، يسلّم الخادم متصفحه في العادة ملف تعريف ارتباط للجلسة. ومنذ تلك اللحظة، كل من يحمل هذا الملف هو ذلك المستخدم. وخصائص ملف تعريف الارتباط هي التي تحدد متى يرسله المتصفح، وعبر أي اتصالات، وهل تستطيع السكربتات في الصفحة قراءته. ضبطها ضبطًا صحيحًا لا يكلّف أكثر من سطر إعدادات؛ أما الخطأ فيها فقد يحوّل خللًا صغيرًا إلى استيلاء على حساب.

الخصائص المهمة

Secure

Secure تأمر المتصفح بألّا يرسل ملف تعريف الارتباط إلا عبر HTTPS. ومن دونها قد ينتقل الملف في طلب HTTP عادي، كأن يكتب أحدهم نطاقك بلا https:// قبل أن تحدث إعادة التوجيه، وعندئذ يستطيع أي شخص على الشبكة نفسها قراءته. في موقع يعمل بـ HTTPS، ينبغي أن يحمل كل ملف تعريف ارتباط الخاصية Secure.

HttpOnly

HttpOnly تخفي ملف تعريف الارتباط عن JavaScript (document.cookie). فإذا تمكّن مهاجم من حقن سكربت في صفحتك، لم يستطع ببساطة قراءة ملف الجلسة وإرساله إلى مكان آخر. استخدمها مع ملفات الجلسة والمصادقة. أما الملفات التي لا بد أن تقرأها شيفرة الواجهة الأمامية عندك، مثل رمز CSRF الذي تعرضه بعض الأطر على JavaScript عمدًا، فلا يمكن أن تكون HttpOnly، وهذا متوقَّع.

SameSite

SameSite تتحكم في إرسال ملف تعريف الارتباط حين يأتي الطلب من موقع آخر:

• SameSite=Strict: لا يُرسَل إلا مع الطلبات التي تبدأ من موقعك نفسه. وهذا الأكثر أمانًا، لكن الزائر الذي يتبع رابطًا من بريد إلكتروني إلى موقعك يصل وكأنه غير مسجَّل الدخول.
• SameSite=Lax: يُرسَل مع التنقلات على المستوى الأعلى، مثل النقر على رابط، لا مع إرسال النماذج بين المواقع ولا مع الصور أو الإطارات. وهو خيار افتراضي جيد لملفات الجلسة.
• SameSite=None: يُرسَل في كل سياق بين المواقع، وهو لازم للأدوات المضمَّنة ولبعض مسارات تسجيل الدخول الموحّد. ويجب أن يقترن بـ Secure، وإلا رفضت المتصفحات الملف.

المتصفحات المبنية على Chromium تعامل الملف الخالي من خاصية SameSite على أنه Lax، لكن المتصفحات لا تتصرف كلها على النحو نفسه، فحدّدها صراحةً.

Domain و Path

إذا حذفت Domain صار ملف تعريف الارتباط خاصًّا بالمضيف وحده: لا يُرسَل إلا إلى المضيف الذي ضبطه بعينه. أما ضبط Domain=example.com فيشاركه مع كل نطاق فرعي، ومنها النطاقات المنسيّة على استضافات أخرى قد تكون أقل أمانًا. لا توسّع النطاق إلا حين تحتاج حقًّا إلى مشاركة تسجيل الدخول بين النطاقات الفرعية.

Expires و Max-Age

من دون Expires أو Max-Age يُفترض أن يبقى الملف ما بقيت جلسة المتصفح، وإن كانت المتصفحات التي تستعيد الجلسات قد تحتفظ به مدة أطول. ولتسجيل الدخول الدائم اختر مدة صلاحية تناسب مستوى الخطر، وتأكد من أن الخادم ينهي الجلسات من جهته كذلك.

بادئات أسماء ملفات تعريف الارتباط: __Host- و __Secure-

بادئات الأسماء تجعل المتصفح يفرض القواعد نيابةً عنك. فالملف الذي يبدأ اسمه بـ __Secure- لا يُقبل إلا إذا حمل الخاصية Secure وضُبط عبر HTTPS. والملف الذي يبدأ بـ __Host- أشد صرامة: يجب أن يكون Secure، ومضبوطًا عبر HTTPS، وفيه Path=/، وبلا خاصية Domain. وهذا يقصره على مضيف واحد، فلا يستطيع نطاق فرعي مخترَق أو مهمَل أن يكتب فوقه.

لملف جلسة لا يحتاج إلى مشاركة بين النطاقات الفرعية، البادئة __Host- أقوى خيار متاح: Set-Cookie: __Host-session=…; Secure; HttpOnly; SameSite=Lax; Path=/.

كيف تفحص ملفات تعريف الارتباط لديك

1. في المتصفح. افتح أدوات المطوّرين، وانتقل إلى Application (في Chrome و Edge) أو Storage (في Firefox)، ثم Cookies، واختر موقعك. يعرض الجدول لكل ملف أعمدة Domain و Path و Expires و HttpOnly و Secure و SameSite.
2. في الاستجابة الخام. في تبويب Network انقر على طلب المستند واقرأ ترويسات الاستجابة Set-Cookie. وهذا يبيّن بدقة ما أرسله الخادم، ومنه الخصائص التي ربما رفضها المتصفح.
3. بعد تسجيل الدخول. كثير من المواقع لا يضبط ملفاته المهمة إلا بعد تسجيل الدخول أو عند إنشاء سلة شراء، فأعد الفحص على تلك الصفحات.
4. بأداة فحص. يقرأ فاحص الأمان المجاني من Rudra ترويسات Set-Cookie في استجابة الصفحة نفسها، ويبلّغ عن الملفات الخالية من Secure على HTTPS، والملفات الشبيهة بملفات الجلسة الخالية من HttpOnly، وعن SameSite=None بلا Secure، والملفات التي بلا SameSite، والملفات المضبوطة على نطاق أب.

يحسن بك أن تعرف حدَّين للفحص الآلي. فهو يحكم بأن الملف «شبيه بملف جلسة» من اسمه (الأسماء التي تتضمن مقاطع مثل sess أو sid أو token أو auth)، ولذلك يعرض تلك النتائج بدرجة ثقة متوسطة: تأكد مما يحمله الملف فعلًا. ثم إنه لا يرى إلا الملفات التي تضبطها تلك الاستجابة الواحدة، لا الملفات التي تُضبط لاحقًا عبر JavaScript، أو في صفحات أخرى، أو بعد تسجيل الدخول، أو من أطراف خارجية. وقيم ملفات تعريف الارتباط لا تُقرأ ولا تُخزَّن أبدًا.

كيف تضبط خصائص ملفات تعريف الارتباط على المنصات الشائعة

• جلسات PHP: في php.ini، اضبط session.cookie_secure = 1 و session.cookie_httponly = 1 و session.cookie_samesite = "Lax" (في PHP 7.3 وما بعده)، أو مرِّر الخيارات نفسها إلى session_set_cookie_params().
• Django: SESSION_COOKIE_SECURE = True و CSRF_COOKIE_SECURE = True. أما SESSION_COOKIE_HTTPONLY و SESSION_COOKIE_SAMESITE = "Lax" فهما القيمتان الافتراضيتان أصلًا.
• Express (على Node.js): res.cookie("sid", value, { secure: true, httpOnly: true, sameSite: "lax" })، أو خيارات cookie في express-session. وخلف خادم وكيل، فعّل trust proxy ليعرف Express أن الاتصال يجري عبر HTTPS.
• WordPress: ملفات تسجيل الدخول الأساسية تحمل HttpOnly، وتُعلَّم بـ Secure حين يعمل الموقع على HTTPS. أما ملفات الإضافات فتتفاوت؛ افحصها في أدوات المطوّرين واسأل مطوّري الإضافة إن كانت تنقصها الخصائص.
• الخادم الوكيل العكسي كحل أخير: التوجيه proxy_cookie_flags في nginx (الإصدار 1.19.3 وما بعده) يستطيع إضافة secure و httponly و samesite إلى ملفات تطبيق لا تستطيع تعديله.

أخطاء شائعة

• تعليم الملفات بـ Secure في بيئة الإنتاج مع الاختبار محليًا عبر HTTP فقط، ثم تعطيل الخاصية «مؤقتًا».
• ضبط SameSite=None بلا Secure، فتُسقط المتصفحات الملف ويتوقف تسجيل دخول أو محتوى مضمَّن عن العمل.
• ضبط ملفات الجلسة على النطاق الأب «احتياطًا».
• تخزين رموز الجلسة في localStorage، حيث يستطيع أي سكربت محقون قراءتها؛ وملفات HttpOnly أكثر أمانًا.
• وضع بيانات شخصية في قيم ملفات تعريف الارتباط. ينبغي أن تحمل هذه الملفات معرِّفات لا معلومات.

ملفات تعريف الارتباط جزء واحد من الصورة. ولمعرفة المزيد عن الترويسات و HTTPS وحدود الاختبار غير التدخّلي، اقرأ كيف تفحص أمان موقعك.