سنشرح في هذا القسم ماهية تزوير الطلب من جانب الخادم، ونذكر بعض الأمثلة الشائعة، ونشرح كيفية العثور على أنواع مختلفة من ثغرات SSRF واستغلالها.
ما هو SSRF؟
تزوير الطلب من جانب الخادم (المعروف أيضاً بـ SSRF) هو ثغرة أمنية على الويب تتيح للمهاجمين جعل التطبيق من جانب الخادم يقوم بإنشاء طلبات HTTP إلى نطاق (domain) كيفي من اختيار المهاجم.
في حالات SSRF النموذجية، قد يتسبب المهاجم في جعل الخادم يقوم بإعادة الاتصال بنفسه أو بخدمات الويب الأخرى ضمن البنية التحتية للمؤسسة أو بنظم الأطراف الخارجية الأخرى.
ما هو تأثير هجمات SSRF؟
غالباً ما يؤدي هجوم SSRF الناجح إلى إجراءات غير مسموح بها أو الوصول إلى البيانات داخل المؤسسة، سواءً في التطبيق المصاب نفسه أو على أنظمة خلفية أخرى يستطيع التطبيق التواصل معها. وفي بعض الحالات، قد تسمح ثغرة SSRF للمهاجم بالقيام بالتنفيذ القسري للأوامر.
قد يؤدي استغلال الـ SSRF الذي يتسبب في إجراء اتصالات بأنظمة أطراف خارجية إلى هجمات ضارة لاحقة تظهر وكأنها تنطلق من المؤسسة التي تستضيف التطبيق المصاب، مما يؤدي إلى مسؤوليات قانونية محتملة وإضرارٍ بالسمعة.
هجمات SSRF الشائعة:
غالباً ما تستغل هجمات SSRF علاقات الثقة لشن هجوم من التطبيق المصاب و تنفيذ إجراءات غير مسموح بها. قد توجد علاقات الثقة هذه بالنسبة للخادم نفسه، أو بالنسبة للأنظمة الخلفية (back-end) الأخرى ضمن نفس المؤسسة.
هجمات SSRF ضد الخادم نفسه:
في هجوم SSRF على الخادم نفسه، يجعل المهاجمُ التطبيقَ يقوم بإعادة طلب HTTP إلى الخادم الذي يستضيف التطبيق، عبر واجهة الشبكة العَودِيَّة (loopback network interface) الخاصة به. وعادةً ما يتم ذلك عبر إعطاء عنوان URL باسم مضيف (hostname) مثل 127.0.0.1 (عنوان IP محجوز يشير إلى محول عَودِي [loopback]) أو مضيف محلي localhost (اسم شائع الاستخدام للمحول نفسه) [أي أن عنوان الURL يشير إلى المخدم (أو السيرفر) نفسه الذي أُرسِلَ منه الطلب].
على سبيل المثال، ضع في اعتبارك تطبيق تسوق يتيح للمستخدم إمكانية عرض ما إذا كان عنصر ما موجوداً في المخزن ضمن متجر معين أم لا. ولتوفير معلومات المخزن، يجب أن يستعلم التطبيق العديد من REST API (واجهة برمجة التطبيقات (API) من نوع REST) الموجودة في الكود الخلفي (back-end) ، بحسب المنتج والمخزن الذي يتم الاستفسار عنه. يتم تنفيذ هذا الإجراء عن طريق تمرير عنوان URL لنقطة النهاية (endpoint) ذات الصلة في واجهة برمجة التطبيقات API عبر طلب (request) HTTP من الواجهة الأمامية. وبالتالي فعندما يستعرض المستخدم حالة المخزون لأحد العناصر، يقوم المتصفح الخاص به بإنشاء طلب (request) مثل هذا:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1
يؤدي هذا إلى قيام الخادم بإرسال طلب إلى عنوان URL المحدد، واسترداد حالة المخزون، وإعادته إلى المستخدم.
في هذه الحالة، يمكن للمهاجم تعديل الطلب لتحديد عنوان URL محلي للخادم نفسه. فعلى سبيل المثال:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin
هنا، سيقوم الخادم بإحضار محتويات عنوان URL /admin و إعادته إلى المستخدم.
الآن بالطبع، يمكن للمهاجم فقط زيارة عنوان URL /admin مباشرة. لكن الوظيفة الإدارية (إجراء يحتاج إلى صلاحيات المسؤول administrative) يمكن الوصول إليها عادةً فقط للمستخدمين المصادقين (authenticated) المناسبين. لذلك فإن المهاجم الذي يزور عنوان URL مباشرة لن يرى أي شيء مهم. ولكن، عندما يأتي طلب عنوان URL /admin من الجهاز المحلي نفسه، يتم تجاوز الضوابط المعتادة للتحكم في الوصول. ويمنح التطبيق حق الوصول الكامل إلى الوظيفة الإدارية، لأن الطلب يظهر على أنه نشأ من موقع موثوق به.
لماذا تتصرف التطبيقات بهذه الطريقة، وتثق ضمنياً في الطلبات التي تأتي من الجهاز المحلي؟ هذا يمكن أن ينشأ لأسباب مختلفة:
- قد يتم تنفيذ اختبار التحكم في الوصول ضمن مكون مختلف متوضع أمام خادم التطبيق [ربما المقصود أن التحقق من صلاحيات الوصول يتم في الواجهة الأمامية قبل الإرسال إلى السيرفر]. وعند إعادة الاتصال بالخادم نفسه، يتم تجاوز التحقق.
- لأغراض الاسترداد بعد الكوارث، قد يسمح التطبيق بالوصول الإداري دون تسجيل الدخول لأي مستخدم آتٍ من الجهاز المحلي. يوفر هذا طريقة للمسؤول لاسترداد النظام في حالة فقدان بيانات الأمان (credentials : مثل بيانات تسجيل الدخول) الخاصة بهم. الافتراض هنا هو أن المستخدم الموثوق به فقط هو الذي سيأتي مباشرةً من الخادم نفسه.
- قد تستمع الواجهة الإدارية إلى رقم منفذ (port) مختلف عن التطبيق الرئيسي، وبالتالي قد لا يمكن للمستخدمين الوصول إليها مباشرة.
هذا النوع من علاقات الثقة، حيث يتم التعامل مع الطلبات الصادرة من الجهاز المحلي بشكل مختلف عن الطلبات العادية، غالباً ما يجعل SSRF ثغرةً خطيرة.
هجمات SSRF ضد النظم الخلفية (back-end) الأخرى:
هناك نوع آخر من علاقات الثقة التي تظهر غالباً مع تزوير الطلبات من جانب الخادم، حيث يكون خادم التطبيق قادراً على التعامل مع النظم الخلفية الأخرى التي لا يمكن للمستخدمين الوصول إليها مباشرة. غالباً ما تحتوي هذه النظم على عناوين IP خاصة غير قابلة للتوجيه. ونظراً لأن هذه النظم الخلفية محمية عادةً بواسطة طوبولوجية الشبكة (شكل و نوع و توزع الأجهزة و الاتصالات في الشبكة) ، فغالباً ما يكون لها وضع أمان أضعف. في كثير من الحالات، تحتوي الأنظمة الخلفية الداخلية على وظائف حساسة يمكن الوصول إليها دون مصادقة أي شخص قادر على التفاعل مع الأنظمة.
في المثال السابق، افترض أن هناك واجهة إدارية على عنوان URL للواجهة الخلفية https://192.168.0.68/admin. هنا، يمكن للمهاجمين استغلال ثغرة SSRF للوصول إلى واجهة الإدارة عن طريق إرسال الطلب التالي:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/admin
لالتفاف على دفاعات SSRF الشائعة:
من الشائع رؤية التطبيقات التي تحتوي على سلوك SSRF مع الدفاعات التي تهدف إلى منع الاستغلال الضار. وفي كثير من الأحيان، يمكن التحايل على هذه الدفاعات.
SSRF مع مرشحات الإدخال (أو الدخل input) المعتمدة على القائمة السوداء (blacklist-based):
تمنع بعض التطبيقات المدخلات التي تحتوي على أسماء المضيفين مثل 127.0.0.1 و localhost ، أو عناوين URL الحساسة مثل /admin. في هذه الحالة، يمكنك غالباً الالتفاف على المرشح باستخدام أساليب مختلفة:
- باستخدام تمثيل IP بديل لـ 127.0.0.1 ، مثل 2130706433 أو 017700000001 أو 127.1 .
- تسجيل اسم النطاق الخاص بك الذي يحال إلى 127.0.0.1. يمكنك استخدام spoofed.burpcollaborator.net لهذا الغرض.
- تشويش السلاسل (السلاسل النصية strings) المحظورة باستخدام تشفير عنوان URL أو تبديل حالة الأحرف.
SSRF مع مرشحات الإدخال المعتمدة على القائمة البيضاء (whitelist-based):
تتيح بعض التطبيقات فقط الإدخال الذي يطابق، أو يبدأ، أو يحتوي على القيم الموجودة في قائمة بيضاء مسموح بها. في هذه الحالة، يمكنك في بعض الأحيان التحايل على الفلتر (المرشح) من خلال استغلال التناقضات في تحليل عناوين URL.
تحتوي مواصفات عنوان URL على عدد من الميزات التي يمكن التغاضي عنها عند تنفيذ تحليل عناوين URL والتحقق من صحتها:
- يمكنك تضمين بيانات الأمان (credentials) في عنوان URL قبل اسم المضيف، باستخدام المحرف @. على سبيل المثال: https: // expected-host @ evil-host.
- يمكنك استخدام المحرف # للإشارة إلى مقطع (fragment : جزء) URL. على سبيل المثال: https: // evil-host # expected-host.
- يمكنك الاستفادة من التسلسل الهرمي لتسمية DNS لوضع الإدخال المطلوب في اسم DNS مؤهل بالكامل و الذي تتحكم فيه. على سبيل المثال: https: //expected-host.evil-host.
- يمكنك استخدام ترميز URL للمحارف (characters) لإرباك كود تحليل عناوين URL. يعد هذا مفيداً بشكل خاص إذا كان الكود (أو الشيفرة code) الذي ينفذ المرشح يعالج الأحرف المشفرة بعنوان URL بشكل مختلف عن الكود الذي ينفذ طلب HTTP في الواجهة الخلفية (back-end).
- يمكنك دمج واستخدام هذه التقنيات معاً.
تجاوز مرشحات SSRF عبر إعادة التوجيه المفتوح:
من الممكن في بعض الأحيان التحايل على أي نوع من الدفاعات القائمة على الفلترة من خلال استغلال ثغرة إعادة التوجيه المفتوح.
في مثال SSRF السابق، افترض أن عنوان URL المقدم من المستخدم تم التحقق منه بشكل صارم لمنع الاستغلال الضار لسلوك SSRF. ومع ذلك، فإن التطبيق الذي تكون عناوين URL الخاصة به مسموحة يحتوي على ثغرة إعادة التوجيه المفتوح، شريطة أن تدعم واجهة برمجة التطبيقات (API) المستخدمة في إنشاء طلب HTTP للواجهة الخلفية عمليات إعادة التوجيه، حيث يمكنك إنشاء عنوان URL يرضي المرشح (الفلتر) وينتج عنه طلبٌ معاد توجيهه إلى الهدف الخلفي (back-end) المطلوب.
على سبيل المثال، لنفترض أن التطبيق يحتوي على ثغرة إعادة التوجيه المفتوح والتي يكون فيها عنوان URL التالي:
/product/nextProduct?currentProductId=6&path=http://evil-user.net
يقوم بإعادة توجيه إلى:
http://evil-user.net
يمكنك الاستفادة من ثغرة إعادة التوجيه المفتوح لتجاوز مرشح (فلتر) الـ URL ، واستغلال ثغرة SSRF على النحو التالي:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin
يعمل استغلال SSRF هذا لأن التطبيق يتحقق أولاً من أن عنوان URL المقدم والخاص بـ stockAPI موجود على نطاق (domain) مسموح به، و هو كذلك. يطلب التطبيق بعد ذلك عنوان URL المرفق، والذي يؤدي إلى إعادة التوجيه المفتوح. ثم يتبع إعادة التوجيه، وينشئ طلباً لعنوان URL الداخلي الذي اختاره المهاجم.
ثغرات SSRF العمياء:
تنشأ ثغرات SSRF العمياء عندما يمكن جعل تطبيق يقوم بإصدار طلب HTTP خلفي (من الواجهة الخلفية back-end) إلى عنوان الـ URL الذي تم تقديمه، لكن الاستجابة (response) لطلب الواجهة الخلفية (back-end) لا تُرجع في استجابة الواجهة الأمامية للتطبيق.
يصعب بوجه عام استغلال SSRF العمياء، ولكن يمكن أن تؤدي في بعض الأحيان إلى تنفيذ الكود عن بُعد (أو التنفيذ البعيد للكود remote code execution) بشكل كامل على الخادم أو المكونات الخلفية الأخرى.
العثور على المنصة الخفية لهجوم ثغرات SSRF:
من السهل نسبياً اكتشاف العديد من نقاط الضعف في تزوير الطلبات من جانب الخادم، لأن حركة المرور الطبيعية للتطبيق تتضمن وسطاء (parameters) طلب تحتوي على عناوين الـ URL كاملة. ولكن هناك بعض الحالات الأخرى من SSRF يكون تحديدها أصعب.
عناوين URL الجزئية في الطلبات:
في بعض الأحيان، يضع التطبيق فقط اسم المضيف أو جزءاً من مسار الـ URL ضمن وسطاء الطلب. ثم يتم دمج القيمة المقدمة من جانب الخادم إلى عنوان الـ URL الكامل المطلوب. إذا تم التعرف على القيمة بسهولة على أنها اسم مضيف أو مسار URL ، فقد تكون منصة الهجوم المحتمل واضحةً. ومع ذلك، فقد تكون قابلية الاستغلال مثل SSRF الكامل محدودة نظراً لأنك لا تتحكم بكامل عنوان URL الذي يتم طلبه.
عناوين الـ URL ضمن صيغ (format) البيانات:
تقوم بعض التطبيقات بنقل البيانات بصيغ تسمح مواصفاتها بإدراج عناوين URL التي قد يطلبها محلل [ parser محلل أو محول يحول البيانات من شكل لآخر] البيانات لتلك الصيغة. مثال واضح على ذلك هو تنسيق بيانات XML، والذي تم استخدامه على نطاق واسع في تطبيقات الويب لنقل البيانات المهيكلة (structured) من الزبون client إلى الخادم server. وعندما يقبل أحد التطبيقات البيانات بتنسيق XML ويقوم بتحويلها، فقد يكون عرضة لحقن XXE ، وبالتالي يكون عرضة ل SSRF عبر XXE.
SSRF عبر ترويسة Referer:
تستخدم بعض التطبيقات برنامج التحليلات من جانب الخادم والتي تتبع الزوار. غالباً ما تسجل هذه البرامج ترويسة Referer في الطلبات، نظراً لأن هذا الأمر له أهمية خاصة في تتبع الروابط الواردة. غالباً ما يقوم برنامج التحليلات بزيارة أي عنوان URL لجهة خارجية يظهر في ترويسة Referer. يتم ذلك عادةً لتحليل محتويات المواقع المحالة، بما في ذلك نص الربط (anchor text) الذي يتم استخدامه في الروابط الواردة. نتيجة لذلك، تمثل ترويسة Referer في الغالب منصة هجوم مثمر لثغرات SSRF. انظر ثغرات SSRF العمياء للحصول على أمثلة للثغرات التي تتضمن ترويسة Referer.