ما هي ثغرة SSRF وكيف تحد من مخاطرها؟
الكاتب: فريق تحرير Domeny.ForSale تاريخ النشر
باختصار: SSRF (Server-Side Request Forgery)، أي تزوير الطلبات من جانب الخادم، ثغرة تتيح للمهاجم دفع خادم التطبيق إلى إرسال طلب إلى عنوان غير مقصود. وقد يصل الخادم بهذه الطريقة إلى موارد لا يمكن الوصول إليها مباشرة من الإنترنت، مثل خدمات الشبكة الداخلية. وعلى خلاف CSRF التي تستغل متصفح المستخدم، ينفّذ الخادم نفسه الطلب في حالة SSRF.
كيف تعمل SSRF؟ مثال بسيط
تخيّل تطبيقا يتيح إضافة صورة منتج بلصق عنوان الصورة. يُدخل المستخدم URL، أي عنوان المورد، فيجلب الخادم الملف ويحفظه في دليل المتجر. هذه ميزة مريحة، لكن على التطبيق التحقق من الوجهة التي يتصل بها فعليا.
إذا كان التطبيق يقبل أي عنوان، فقد يحدد المهاجم، بدلا من الصورة، عنوان خدمة لا يمكن الوصول إليها إلا من شبكة الخادم. عندها يصبح التطبيق وسيطا يرسل الطلب إلى وجهة لا يستطيع المهاجم الوصول إليها بنفسه. وإذا أعاد التطبيق أيضا المحتوى الذي تلقّاه إلى المستخدم، فقد يكشف بيانات داخلية.
يمكن تشبيه ذلك بموظف استقبال يجلب مستندات من غرف مغلقة بناء على طلب أي شخص. ليست المشكلة في جلب المستندات بحد ذاته، بل في عدم التحقق من الأماكن التي يُسمح بأخذها منها والأشخاص الذين يجوز تسليمها إليهم.
جلب البيانات من عنوان يقدمه المستخدم لا يعني، بحد ذاته، وجود ثغرة. تظهر SSRF حين يستطيع المستخدم توجيه الطلب إلى خارج النطاق المسموح به، ولا يفرض التطبيق القيود المناسبة.
أين تظهر SSRF وما آثارها المحتملة؟
قد تصيب SSRF أي وظيفة تتصل بمورد آخر استنادا إلى بيانات يتحكم فيها المستخدم. ومن أمثلتها الشائعة إنشاء معاينات الروابط، واستيراد المستندات، وجلب الصور، وإنشاء ملفات PDF من صفحات الويب. وينشأ خطر مماثل عند استخدام إشعارات webhook، وهي إشعارات آلية تُرسل إلى عنوان محدد.
تعتمد الآثار على الموارد التي يستطيع الخادم الوصول إليها وطريقة تعامل التطبيق مع الاستجابة. ومن النتائج المحتملة:
- قراءة معلومات من خدمات داخلية؛
- استكشاف الخدمات المتاحة في شبكة الخادم؛
- الوصول إلى البيانات الوصفية للبيئة السحابية، التي قد تتضمن أحيانا بيانات اعتماد؛
- تنفيذ عمليات في خدمة تثق، على نحو غير سليم، بحركة البيانات الواردة من الشبكة الداخلية.
لا تعني SSRF تلقائيا الاستيلاء على الخادم بأكمله. لكن الخطر يزداد عندما يتمتع التطبيق بإمكانية وصول واسعة إلى الشبكة، ولا تشترط الخدمات الداخلية المصادقة.
وهناك أيضا SSRF العمياء (blind SSRF)، وهي حالة لا يرى فيها المهاجم مباشرة الاستجابة الواردة من المورد المطلوب. عدم عرض المحتوى لا يزيل الثغرة؛ فمجرد إرسال الطلب قد ينفّذ عملية غير مرغوبة أو يكشف معلومات من خلال سلوك التطبيق.
SSRF وCSRF: اسمان متشابهان وآليتان مختلفتان
تقوم CSRF (Cross-Site Request Forgery)، أي تزوير الطلبات عبر المواقع، على دفع متصفح المستخدم إلى إرسال طلب غير مرغوب فيه إلى التطبيق. وقد يرفق المتصفح تلقائيا بيانات الجلسة، مثل ملف تعريف ارتباط خاص بمستخدم سجّل دخوله. ويكون الهدف عادة تنفيذ عملية بصلاحيات ذلك المستخدم.
أما في SSRF، فالخادم هو الذي ينفّذ الطلب، ويستغل الهجوم قدرته على الوصول عبر الشبكة وأي صلاحيات قد يتمتع بها. ولا تتطلب هذه الآلية في حد ذاتها وجود ضحية سجّلت دخولها، وإن كانت الوظيفة المصابة بالثغرة قد لا تتاح إلا بعد تسجيل الدخول.
| الجانب | SSRF | CSRF |
|---|---|---|
| من يرسل الطلب؟ | خادم التطبيق | متصفح المستخدم |
| ما الذي يُستغل؟ | قدرة الخادم على الوصول وصلاحياته | جلسة المستخدم |
| محور الحماية الأساسي | ضبط وجهات الاتصال والوصول إلى الشبكة | التحقق من الطلبات التي تغيّر الحالة، باستخدام رموز CSRF وغيرها |
لا تغني وسائل الحماية هذه بعضها عن بعض. فرمز CSRF لا يعالج مشكلة خادم يجلب بيانات من عناوين غير مسموح بها. وبالمثل، لا تغني تصفية الاتصالات الصادرة عن حماية جلسة المستخدم.
كيف تحد من مخاطر SSRF؟
حدّد أولا ما إذا كان التطبيق يحتاج فعلا إلى جلب بيانات من أي عنوان يقدمه المستخدم. إذا كان التكامل يخص خدمة واحدة، فمن الأكثر أمانا حفظ عنوانها في الإعدادات، والاكتفاء بتلقّي معرّف المورد من المستخدم.
عندما يكون إدخال العناوين ضروريا، طبّق عدة طبقات من الحماية:
- احصر الوجهات المسموح بها. إذا كانت طبيعة الوظيفة تسمح بذلك، فاستخدم قائمة محددة حصرا بالمضيفين والمنافذ والبروتوكولات الموثوقة. ولا تكتف بالتحقق من العناوين عبر البحث عن جزء من النص.
- تحقّق من عناوين IP المستهدفة. شمل التحقق كلا من IPv4 وIPv6، واحظر النطاقات غير المسموح بها، بما فيها الشبكات الخاصة والعناوين المحلية ونقاط الوصول الخاصة بالبيانات الوصفية السحابية.
- اضبط عمليات إعادة التوجيه وDNS. قد يعيد عنوان يبدو آمنا توجيه الطلب إلى مورد محظور. يجب أن يشمل التحقق الوجهة الفعلية للاتصال، لا URL الأولي وحده.
- قيّد حركة البيانات الصادرة. ينبغي أن تمنع قواعد الشبكة التطبيق من الوصول إلى الخدمات التي لا يحتاج إليها. واضبط أيضا حدودا لمهلة الانتظار وحجم الاستجابة.
لا تمرّر تلقائيا ملفات تعريف الارتباط أو الرموز أو غيرها من بيانات الاعتماد إلى العناوين التي يحددها المستخدم. وفي البيئة السحابية، راجع أيضا وثائق المزوّد الرسمية المتعلقة بحماية خدمة البيانات الوصفية.
من أين تبدأ فحص التطبيق؟
أعدّ قائمة بالوظائف التي يجلب فيها الخادم بيانات اعتمادا على عنوان أو قيمة أخرى يقدمها المستخدم. وحدّد لكل وظيفة وجهات الاتصال المسموح بها، وكيفية التعامل مع إعادة التوجيه، والبيانات التي تُعاد إلى المستخدم.
لا تُجرِ الاختبارات إلا في بيئتك الخاصة أو بإذن المالك. ابدأ بوظيفة واحدة، مثل استيراد صورة، وتحقق من أن قيودها تظل سارية بعد إعادة التوجيه أيضا، لا على العنوان المُدخل في النموذج وحده.
اقرأ أيضًا
