تثبيت الجلسة

سيناريو مباشر:

1. توصل مالوري إلى أن هذه الأداة http://unsafe.example.com/تقبل أي مُعرّف جلسة، وتقبل مُعرّفات الجلسات من سلاسل الاستعلام، ولا يوجد بها أي تحقق أمني. http://unsafe.example.com/وبالتالي فهي غير آمنة.
2. أرسلت مالوري رسالة بريد إلكتروني إلى أليس تقول فيها: "مرحباً، انظري إلى هذا، هناك ميزة جديدة رائعة لملخص الحساب في بنكنا http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID". تحاول مالوري تثبيت معرف النظام (SID) على I_WILL_KNOW_THE_SID...
3. أبدت أليس اهتمامها وقامت بزيارة الموقع http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID. ظهرت شاشة تسجيل الدخول المعتادة، وقامت أليس بتسجيل الدخول.
4. تزور مالوري http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SIDحساب أليس، ولديها الآن وصول غير محدود إليه.

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

سيناريو:

1. يقوم برنامج مالوري بزيارة الخادم http://vulnerable.example.com/والتحقق من مُعرّف الأمان (SID) الذي يتم إرجاعه. على سبيل المثال، قد يستجيب الخادم بما يلي Set-Cookie: SID=0D6441FEA4496C2:
2. أصبح بإمكان مالوري الآن إرسال بريد إلكتروني إلى أليس: "ألقِ نظرة على هذه الميزة الرائعة الجديدة في بنكنا، http://vulnerable.example.com/?SID=0D6441FEA4496C2".
3. تقوم أليس بتسجيل الدخول، باستخدام معرف الجلسة الثابت SID=0D6441FEA4496C2.
4. تزور مالوري http://vulnerable.example.com/?SID=0D6441FEA4496C2حساب أليس، ولديها الآن وصول غير محدود إليه.

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

سيناريو:

1. يقوم موقع ويب www.example.comبتوزيع نطاقات فرعية على جهات خارجية غير موثوقة
2. أحد هؤلاء الأطراف، مالوري، الذي يسيطر الآن evil.example.com، يستدرج أليس إلى موقعه
3. تؤدي زيارة الموقع إلى evil.example.comتعيين ملف تعريف ارتباط للجلسة مع النطاق .example.comعلى متصفح أليس
4. عندما تزور أليس الموقع، www.example.comسيتم إرسال ملف تعريف الارتباط هذا مع الطلب، وستحصل أليس على الجلسة المحددة بواسطة ملف تعريف الارتباط الخاص بمالوري.
5. إذا قامت أليس بتسجيل الدخول الآن، فبإمكان مالوري استخدام حسابها.

عندما يكتمل هذا الهجوم، يمكن لمالوري الوصول إلى www.example.comأليس.

ليس من الضروري تسجيل دخول المستخدم لاستغلال هجمات تثبيت الجلسة ^{[ 1 ]} ، ورغم أن هذه الهجمات غير المصادق عليها لا تقتصر على هجمات ملفات تعريف الارتباط عبر النطاقات الفرعية، إلا أن آثار هجمات النطاقات الفرعية ذات صلة بهذه السيناريوهات غير المصادق عليها. على سبيل المثال، قد يُقدّم مالوري رابطًا من موقعه الخبيث، مُثبّتًا جلسة في حالة غير مصادق عليها، ويستخدم هذه التقنيات لاستغلال هدفه. يشمل ذلك سيناريوهات تستغل كلًا من الحالات غير المصادق عليها (مثل النماذج أو التسجيل) والقدرة على تزويد المستخدم بجلسة قائمة لتجاوز تسجيل الدخول تمامًا.

لنفترض، على سبيل المثال، أن مالوري قد تُنشئ مستخدمًا باسم A1ice على الموقع www.example.com وتُسجّل دخولها للحصول على مُعرّف جلسة صالح. ثم تُوقع مالوري أليس في فخّ رابط من evil.example.com يُثبّت ملف تعريف ارتباط الجلسة في متصفح أليس (كما ذُكر سابقًا) ويُعيد توجيهها إلى www.example.com لإتمام معاملة مُحدّدة (أو في الواقع، لاستخدام أوسع). وهكذا، تستطيع مالوري الاستيلاء على جلسة تسجيل الدخول الأصلية، وجمع البيانات، وتنفيذ العمليات باسم "A1ice" على "www.example.com". إذا نجحت عملية الخداع في خداع أليس وحفظت بطاقتها الائتمانية في الحساب، فقد تُجري مالوري عمليات شراء باستخدام تلك البطاقة.

لا يُنصح باستخدام معرفات الجلسة في عنوان URL (سلسلة الاستعلام، متغيرات GET) أو متغيرات POST لأنها تبسط هذا الهجوم - فمن السهل إنشاء روابط أو نماذج تقوم بتعيين متغيرات GET / POST.

• يتم تسريب معرف الأمان (SID) إلى أشخاص آخرين عندما يقوم المستخدمون بنسخ ولصق "روابط مثيرة للاهتمام" من شريط العناوين في المحادثات والمنتديات والمجتمعات وما إلى ذلك.
• يتم تخزين معرف الأمان (SID) في العديد من الأماكن (سجل تاريخ المتصفح، سجل خادم الويب ، سجلات الوكيل، ...).

ملاحظة: يتم تبادل ملفات تعريف الارتباط بين علامات التبويب ونوافذ المتصفح المنبثقة. إذا كان نظامك يتطلب الوصول إلى نفس النطاق (www.example.com/?code=site1 و www.example.com/?code=site2)، فقد تتعارض ملفات تعريف الارتباط بين علامات التبويب.

قد يتطلب الأمر إرسال مُعرّف الجلسة مع عنوان URL لتجاوز هذا القيد. يُفضّل استخدام site1.example.com أو site2.example.com لتجنّب تعارض النطاقات في ملفات تعريف الارتباط. قد يُكلّف ذلك تكاليف إضافية لشهادات SSL.

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

تم إيقاف استخدام معرفات الجلسة في GET و POST في PHP 8.4 وسيتم إزالتها في PHP 9.0. ^{[ 2 ]}

تتمثل إحدى طرق مكافحة تثبيت الجلسة في إنشاء مُعرّف جلسة جديد (SID) مع كل طلب. عند تطبيق ذلك، حتى لو تمكن المهاجم من خداع المستخدم لقبول مُعرّف جلسة معروف، فسيكون هذا المُعرّف غير صالح عند محاولة المهاجم إعادة استخدامه. يُعدّ تطبيق هذا النظام بسيطًا، كما يتضح مما يلي:

• استرجاع مُعرّف الجلسة السابقة OLD_SIDمن طلب HTTP.
• إذا OLD_SIDكانت القيمة فارغة أو معدومة أو لم تكن هناك جلسة بمعرف SID= OLD_SIDموجودة، فقم بإنشاء جلسة جديدة.
• قم بإنشاء مُعرّف جلسة جديد NEW_SIDباستخدام مُولّد أرقام عشوائية آمن.
• لنفترض أن الجلسة تُعرَّف بواسطة SID= NEW_SID(وليس بواسطة SID= بعد الآن OLD_SID)
• إرسال معرف النظام الجديد إلى العميل.

مثال:

إذا نجحت مالوري في خداع أليس لزيارتها http://victim.example.com/?SID=I_KNOW_THE_SID، فسيتم إرسال طلب HTTP هذا إلى victim.example.com:

طلب GET /?SID=I_KNOW_THE_SID HTTP / 1.1 Host : victim.example.com

victim.example.comيقبل هذا الأمر SID=I_KNOW_THE_SID، وهو أمرٌ يُعتبر سيئاً في العادة. مع ذلك، victim.example.comفهو آمن لأنه يُجري عملية إعادة إنشاء الجلسة. victim.example.comويتلقى الاستجابة التالية:

HTTP / 1.1 200 OK Set-Cookie : SID=3134998145AB331F

ستستخدم أليس الآن SID=3134998145AB331Fبيانات غير معروفة لمالوري، وهي SID=I_KNOW_THE_SIDبيانات غير صالحة. وبالتالي، تفشل مالوري في محاولة تثبيت الجلسة.

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

إذا كان تنفيذ الجلسات يتضمن إرسال معرف الجلسة (SID) من خلال متغيرات GET أو POST، فقد يؤدي ذلك أيضًا إلى جعل زر "الرجوع" غير قابل للاستخدام في معظم المتصفحات، حيث سيستخدم المستخدم حينها معرف جلسة قديمًا وغير صالح من طلب سابق.

إحدى طرق تحسين الأمان هي عدم قبول مُعرّفات الجلسات التي لم يُنشئها الخادم. مع ذلك، وكما ذُكر أعلاه، فإن هذا لا يمنع جميع هجمات تثبيت الجلسة.

إذا لم يتم تعيين مُعرّف الجلسة المُولّد بواسطة الخادم ( SERVER_GENERATED_SID )، فسيتم حذف جميع البيانات الموجودة في الجلسة . بعد ذلك ، يتم إنشاء مُعرّف جلسة جديد ( SERVER_GENERATED_SID ) وتعيينه إلى القيمة true .

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

إذا ( تم تسجيل الخروج ) { session_destroy (); // حذف جميع البيانات في الجلسة }

هذا الدفاع سهل التنفيذ وله ميزة توفير قدر من الحماية ضد المستخدمين غير المصرح لهم الذين يصلون إلى حساب مستخدم مصرح له باستخدام جهاز ربما يكون قد تُرك دون رقابة.

يُخزَّن في متغير الجلسة طابع زمني لآخر وصول تم بواسطة مُعرِّف الأمان (SID). عند استخدام مُعرِّف الأمان هذا مرة أخرى، يُقارن الطابع الزمني الحالي مع الطابع الزمني المُخزَّن في الجلسة. إذا كان الفرق أكبر من قيمة مُحدَّدة مُسبقًا، ولتكن 5 دقائق، تُنهى الجلسة. وإلا، يُحدَّث متغير الجلسة بالطابع الزمني الحالي.

عند زيارة صفحة ما، تقوم معظم متصفحات الويب بتعيين رأس Referrer - الصفحة التي تحتوي على الرابط الذي اتبعته للوصول إلى هذه الصفحة.

عندما يكون المستخدم مسجلاً دخوله إلى موقع من غير المرجح أن يتم الوصول إليه من خارجه (مثل مواقع البنوك أو البريد الإلكتروني )، ولا يكون هذا الموقع من النوع الذي يبقى فيه المستخدمون مسجلين دخولهم لفترة طويلة، يجب أن يكون المُحيل من ذلك الموقع. أي مُحيل آخر يُعتبر مشبوهاً. مع ذلك، إذا كان الطلب الأصلي من صفحة HTTPS، فسيتم حذف المُحيل، لذا لا يمكنك الاعتماد على هذا النظام الأمني.

على سبيل المثال، http://vulnerable.example.com/يمكن استخدام فحص الأمان التالي:

إذا كان ( strpos ( $_SERVER [ 'HTTP_REFERER' ], 'http://vulnerable.example.com/' ) !== 0 ) { session_destroy (); // حذف جميع البيانات في الجلسة } session_regenerate_id (); // إنشاء مُعرّف جلسة جديد

إحدى طرق تعزيز الأمان هي ضمان ظهور المستخدم على أنه نفس المستخدم النهائي (العميل). هذا يجعل من الصعب تنفيذ هجمات تثبيت الجلسة وغيرها من الهجمات.

مع ازدياد التزام الشبكات بمعيار RFC 3704 وغيره من ممارسات مكافحة التزييف ، يصبح عنوان IP أكثر موثوقية كمعرّف "مصدر ثابت". لذا، يمكن تحسين أمان موقع الويب من خلال التحقق من ثبات عنوان IP المصدر طوال الجلسة.

يمكن القيام بذلك بهذه الطريقة:

إذا كان عنوان الخادم البعيد ( $_SERVER [ 'REMOTE_ADDR' ] ) لا يساوي عنوان الجلسة البعيد السابق ($ _SESSION [ 'PREV_REMOTEADDR' ]) ، فسيتم حذف جميع البيانات من الجلسة . وإلا، فسيتم إنشاء مُعرّف جلسة جديد ( session_regenerate_id ()). ثم يتم تعيين عنوان الجلسة البعيد السابق ($_SESSION [ 'PREV_REMOTEADDR' ]) إلى عنوان الخادم البعيد السابق ( $_SERVER [ 'REMOTE_ADDR' ]).

ومع ذلك، هناك بعض النقاط التي يجب مراعاتها قبل استخدام هذا النهج.

• قد يتشارك عدة مستخدمين عنوان IP واحد. ومن الشائع أن يتشارك مبنى بأكمله عنوان IP واحد باستخدام تقنية NAT .
• قد يمتلك المستخدم عنوان IP غير ثابت. ينطبق هذا على المستخدمين الذين يستخدمون خوادم بروكسي (مثل عملاء AOL ). وينطبق أيضًا على بعض مستخدمي الهواتف المحمولة/التجوال، بالإضافة إلى المستخدمين الذين يستخدمون اتصالات إنترنت متوازنة الأحمال. كما يمكن للمستخدمين الذين فعّلوا ملحقات خصوصية IPv6 تغيير عناوين خصوصية IPv6 الخاصة بهم في أي وقت.
• لن يعمل بشكل موثوق مع عملاء البروتوكول المزدوج حيث ستنتقل الطلبات بين IPv4 و IPv6.
• لن يعمل بشكل موثوق مع مستخدمي الهواتف المحمولة، حيث يتنقل مستخدمو الهواتف المحمولة بين العناوين أيضًا.

بالنسبة لبعض المواقع، تفوق مزايا الأمان الإضافية قلة الراحة، وبالنسبة لمواقع أخرى لا يكون الأمر كذلك.

إذا كان ( $_SERVER [ 'HTTP_USER_AGENT' ] != $_SESSION [ 'PREV_USERAGENT' ]) { session_destroy (); // حذف جميع البيانات في الجلسة } session_regenerate_id (); // إنشاء مُعرّف جلسة جديد $_SESSION [ 'PREV_USERAGENT' ] = $_SERVER [ 'HTTP_USER_AGENT' ];