الثغرات الشائعة في تطبيقات API
فهم الثغرات الشائعة يساعدك في معرفة نقاط الضعف والثغرات عند اختبار اختراق الـ APIs.
كشف المعلومات Information Disclosure
قد يتم الكشف عن معلومات حساسة في رد الـ API أو في المصادر العامة مثل مستودعات الأكواد, نتائج البحث, الأخبار, الشبكات الاجتماعية, في الموقع نفسه وفي مجلدات الـ API.
المعلومات الحساسة قد تشمل أي معلومة تمكن المخترق من الاستفادة منها.
هذه المعلومات يمكن استخدامها في تسجيل الدخول باستخدام هجمات brute-force, credential-stuffing, و password-spraying.
رسائل الخطأ تساعد مستخدمي الـ API لاستكشاف الأخطاء وتسمح للمطورين بفهم المشاكل التي تواجه تطبيقاتهم. على أية حال, قد تؤدي هذه الرسائل إلى الكشف عن معلومات حساسة عن المستخدمين ,مصادر المعلومات وعن البنية الأساسية لـ API (مثل رقم إصدار خادم الويب وقاعدة البيانات.
غالباً, يمكن الحصول على أكثر المعلومات من خلال التفاعل مع تطبيق API وتحليل الردود القادمة من الخادم. قد تكشف عن معلومات في الهيدرز, الباراميترز, ورسائل الخطأ المطولة. خلال مرحلة الاستطلاع.
مستوى التفويض المصاب للكائن Broken Object Level Authorization
ثغرات BOLA هي ثغرات تظهر عندما يسمح تطبيق API للمستخدم بالدخول إلى مصادر غير مسموح له بالدخول إليها.
على سبيل المثال, تصور بأننا مخولون بالدخول إلى المستخدم Cloud Strife فقط. يمكننا أن نرسل طلب GET إلى العنوان https://bestgame.com/api/v3/users?id=5501
في هذه الحالة, نستطيع البحث عن الثغرات من خلال استخدام رقم id قريب إلى المستخدم cloud وهو الرقم 5501. وبذلك قد نتمكن من الدخول إلى معلومات مستخدم آخر.
بشكل عام يمكنك فحص هذا النوع من الثغرات من خلال فهم طريقة عمل API وفهم كيف يتم تنظيم مصادر API . وبالتالي قد تتمكن من الدخول إلى مصادر غير مسموح لك الوصول إليها. من خلال الكشف عن الأنماط الموجودة في المسارات والباراميترز, وتخمين المصادر الأخرى.
ثغرات BOLA قد تكون من الثغرات السهلة الاكتشاف. من خلال التعرف على الأنماط وإرسال بعض الطلبات إلى الخادم. في أحيان أخرى تكون هذه الثغرات صعبة الاكتشاف بعض الشيء بسبب التعقيد في تعريف الكائن object ID وفي الطلبات المستخدمة في للوصول إلى مصادر المستخدمين الآخرين.
مصادقة المستخدم المصابة Broken User Authentication
وتشير إلى نقطة ضعف في عملية مصادقة المستخدم للـ API. تظهر هذه الثغرات عادة عندما لا يوفر تطبيق الـ API أي حماية لعلمية المصادقة أو توفيرها بشكل خاطئ.
عمليات المصادقة الأخرى المصابة تشمل النواحي المتعلقة بأنظمة التسجيل مثل مزايا إعادة تعيين كلمات المرور والمصادقة الثنائية, على سبيل المثال, تصور بأن ميزة إعادة تعيين كلمة المرور تحتاج منك أن تدخل بريدك الإلكتروني وكود من ست أرقام لإعادة تعيين كلمة مرورك. حسناً, لو سمحت الـ API لك بعدد غير محدود من الطلبات. كل ما يتطلبه الأمر هو إرسال مليون طلب إلى التطبيق لتخمين الكود وإعادة تعيين كلمة المرور لأي مستخدم. الكود المكون من أربع خانات يحتاج إلى 10000 طلب فقط ليتم كسره.
نتيجة طبيعة الـ API . فإن مفتاح API اذا تم كشفه بشكل علني, هو بمثابة الكشف عن اسم المستخدم وكلمة المرور. فيمكن للمهاجم استخدام هذا المفتاح في الحصول على صلاحيات المستخدم الضحية.
التعرض المفرط للبيانات Excessive Data Exposure
وهي الحالة التي يقوم بها تطبيق API بالرد بمعلومات أكثر من الحاجة المطلوبة.
هذا النوع من الثغرات مشابه لسؤال شخص عن اسمه ليرد عليك باسمه, تاريخ ميلاده, رقم الجوال, البريد الإلكتروني وهوية كل شخص يعرفه.
فرضاً أنني قمت بطلب معلومات حسابي من خلا الطلب الآتي:
كل ما تحتاجه فعله لاكتشاف هذا النوع من الثغرات هو فحص الـ API الهدف ومراجعة المعلومات الموجودة في الرد.
نقص المصادر والسرعة المحددة Lack of Resources and Rate Limiting
تحديد السرعة rate limiting تلعب دوراً مهما في سلاسة وتوفر الـ API. فمن دونها يمكن للمستخدمين إرباك البنية الأساسية للـ API من خلال إرسال طلبات كثيرة أكثر من ما يتحمله التطبيق. وبالتالي قد يؤدي ذلك إلى تعطل الأنظمة وحدوث حرمان في الخدمة DoS . على سبيل المثال موقع RapidAPI يسمح بـ 500 طلب كل شهر بشكل مجاني و 1000 طلب كل شهر للعملاء الذين يدفعون.بمجرد انتهاء حصتك من الطلبات. يحين الوقت لاختبار الـ rate limit ومدى صرامته. يمكن تخطي الـ rate limit من خلال إضافة أو حذف الباراميترز. او تبديل العميل أو التلاعب بعنوان الأيبي.
مستوى التفويض المصاب للدالة Broken Function Level Authorization
ثغرة BFLA تحدث عندما يكون المستخدم دورفي مجموعة تمكنه من دخول أحد وظائف الـ API التابعة لدور أو مجموعة أخرى.
ثغرات BFLA مشابهة لثغرات BOLA, فبدلاً من ثغرة في صلاحية الدخول إلى المصادر تكون ثغرة في صلاحية في تأدية الإجراءات.
- عند وجود ثغرة BOLA في تطبيق الـ API, قد تستطيع معلومات حساب آخر, مثل تاريخ الدفع. أسماء المستخدين, عناوين البريد الإلكتروني وأرقام الحسابات.
- عند وجود ثغرات BFLA في تطبيق API, قد تستطيع تحويل الأموال أو تحديث معلومات الحساب.
أبسط طريقة لاكتشاف ثغرات BFLA هي إيجاد دليل الـ API الإدارية administrative API documentation وإرسال طلب كمستخدم بصلاحيات منخفضة لفحص الوظائف الإدارية. لو لم يكن هناك دليل تعليمي حول كيفية فعل ذلك. يجب تنفيذ هندسة عكسية للطلبات التي تقوم بوظائف إدارية قبل البدء بعمل فحص لها.
الإحالة الجماعية Mass Assignment
تظهر هذه الثغرة عندما يقوم مطور API بتضمين مزيد من الباراميترز في الطلبات اكثر مما يقصده التطبيق ويقوم التطبيق بإضافة هذه الباراميترز متغيرات الكود او الكائنات الداخلية. اعتقد أنها أشبه بهجوم تلويث الباراميترز Parameters Polution.
على سبيل المثال, قد يحتوي التطبيق وظيفة تحديث الحساب والتي يجب على المستخدم استخدامها فقط لتحديث اسم المستخدم, كلمة المرور, والعنوان الخاص به. فلو استطاع المستخدم تضمين باراميترز أخرى في الطلب متعلقة بحسابه, كمستوى امتيازات الحساب أو معلومات حساسة مثل مبلغ الحساب, وقام التطبيق بقبول هذه الباراميترز من دون فحصها بقائمة بيضاء تحتوي على الإجراءات المسموح بها, المستخدم قد يستفاد من هذه الثغرة في تغيير تلك القيم:
تستطيع اكتشاف هذا النوع من الثغرات من خلال إيجاد الباراميترز المثيرة للاهتمام في تعليمات الـ API ثم إضافة الباراميترز إلى الطلب. ابحث عن الباراميترز التي لها علاقة بالمستخدم, الدوال الحرجة والإجراءات الادراية. قد يساعد اعتراض الطلبات والردود في الكشف عن باراميترز مهمة لفحصها. بالإضافة إلى ذلك يمكنك تخمين البارميترز أو عمل fuzz للباراميترز في طلبات الـ API.
الإعدادت الأمنية الخاطئة Security Misconfigurations
وتشمل الأخطاء التي يقع فيها المطور عند وضع الإعدادات الخاصة بـ API. على سبيل المثال, لو قامت الإعدادت بالكشف عن ثغرة غير مرقعة, فيمكن للمهاجم بسهولة من إيجاد استغلال جاهز على الأنترنيت واختراق تطبيق الـ API والنظام الموجود عليه.
تشمل الإعدادات الأمنية الخاطئة, الهيدرز الخاطئة, وتشفير النقل الخاطئ, استخدام حسابات افتراضية default accounts, قبول ميثود HTTP غير ضرورية, نقص في تطهير المدخلات ورسائل الخطأ المطولة verbose error messages.
النقص في تطهير المدخلات يُمكن المهاجم من رفع حمولات خبيثة إلى الخادم.
على سبيل المثال لو كان هناك صفحة تقوم برفع الملفات وحفظها في مجلد الويب, قد يسمح ذلك برفع سكربت والتوجه إلى المسار الذي تم الحفظ فيه. والحصول على شيل عكسي على السيرفر.
مطوري الـ API يستخدمون الهدرز لتزويد المستخدم بإرشادات للتعامل مع متطلبات الاستجابة والأمان. إعداد الهدرز بشكل خاطئ يمكن أن يؤدي إلى تسريب معلومات حساسة, هجمات downgrade, وهجمات XSS.
في هذه الحالة المستخدم UserC لديه وقت رد أكثر بعشرين مرة من الوقت المستغرق لطلب الموارد الأخرى. مع هذه المثال يصعب التأكد من أن المستخدم UserC موجود.
لنفترض على سبيل المثال أن الحساب المزيف /user/account/thisdefinitelydoesnotexist876 لديه وقت رد X-Response-Time يبلغ 25.5 ملي ثانية. وأنت تعلم أن حسابك الصحيح /user/account/1021 لديه وقت رد 510.00 ملي ثانية. بعدها تسطيع إرسال طلبات وتنفيذ هجوم القوة الغاشمة بجميع الأرقام من 1000 إلى 2000, تسطيع فحص النتائج واختبار ما هي الحسابات التي نتج عنها ارتفاع في وقت الاستجابة.
جميع تطبيقات الـ API التي تُزود بمعلومات حساسة للمستخدمين يجب أن تستخدم تقنية أمان طبقة النقل TLS لتشفير البيانات. حتى لو كان التطبيق يعمل في شبكة داخلية, يجب استخدام بروتوكول TLS الذي يشفر ترافيك الـ HTTPS, وهو من الطرق التقليدية لحماية طلبات وردود الـ API عند نقلها عبر الشبكة. عدم استخدام او الاعداد الخاطئ لهذا البروتوكول يؤدي إلى تسرب بيانات المستخدمين الحساسة عبر الشبكات. وبالتالي سيتمكن المهاجمون من استغلال هجوم رجل في المنتصف MiTM.
عندما تستخدم إحدى الخدمات حسابًا وبيانات دخول افتراضية وتكون هذه البيانات معروفة ، يمكن للمهاجم استخدام بيانات الدخول هذه لسرقة دور هذا الحساب. قد يسمح ذلك بالوصول إلى المعلومات الحساسة أو الوظائف الإدارية ، مما قد يؤدي إلى اختراق للأنظمة التي يعمل عليها التطبيق.
أخيرًا ، إذا سمح تطبيق API بميثود HTTP غير ضرورية ، فهناك خطر متزايد من أن التطبيق لن يتعامل مع هذه الطرق بشكل صحيح أو سيؤدي إلى الكشف عن معلومات حساسة.
يمكنك اكتشاف العديد من هذه التكوينات الخاطئة للأمان باستخدام برامج مسح الثغرات الأمنية في تطبيقات الويب مثل Nessus و Qualys و OWASP ZAP و Nikto. ستتحقق هذه البرامج تلقائيًا من معلومات إصدار خادم الويب والهدرز والكوكيز وإعدادات تشفير النقل والبارميترز لمعرفة ما إذا كانت إجراءات الأمان مفقودة. يمكنك أيضًا التحقق من هذه التكوينات الخاطئة للأمان يدويًا ، إذا كنت تعرف ما تبحث عنه ، من خلال فحص الهيدرز وشهادة SSL والكوكيز والباراميترز.
ثغرات الحقن Injection
توجد ثغرات الحقن عندما يتم تمرير طلب إلى البنية التحتية الداعمة لتطبيق API ولا يقوم التطبيق بتصفية المدخلات لإزالة الأحرف غير المرغوب فيها (العملية تُعرف باسم تطهير الإدخال). يمكن أن تكون رسائل الخطأ المطولة ورموز استجابة HTTP وسلوك API غير المتوقع كلها تدل على وجود ثغرة حقن.
قد يمرر تطبيق API هذه الحمولة مباشرة إلى قاعدة بيانات SQL الخلفية ، حيث ستفشل عبارة OR 1=0 (لأن 1 لا يساوي 0) ، مما قد يتسبب في بعض الأخطاء:
غالبًا ما تُستكمل ثغرات الحقن بثغرات إخرى مثل ضعف تطهير المدخلات. في المثال التالي ، يمكنك رؤية هجوم RCE يستخدم طلب GET للاستفادة من باراميتر استعلام مصاب. في هذه الحالة ، يمرر الباراميتر المصاب أي بيانات في جزء الاستعلام من الطلب مباشرة إلى النظام الأساسي ، دون تطهيرها أولاً:
يوضح نص الاستجابة التالي أنه قد تم التلاعب بالـ API لعرض ملف /etc/passwd ، مما يكشف عن مستخدمي النظام:
يتطلب العثور على عيوب الحقن اختبار API بجدية ، مع الانتباه إلى الردود ، ثم التلاعب بالطلبات والتلاعب بالنظام. مثل هجمات اجتياز الدليل directory traversal ، كانت هجمات الحقن موجودة منذ عقود ، لذلك هناك العديد من ضوابط الأمان القياسية لحماية تطبيقات API منها.
إدارة الأصول غير السليمة Improper Assets Management
تحدث إدارة الأصول غير السليمة عندما تكشف إحدى المؤسسات عن تطبيقات (API) المتوقفة أو التي لا تزال قيد التطوير. عادةً ما تكون تطبيقات (API) التي لا تزال قيد التطوير غير آمنة مثل نظيراتها التي في مرحلة الخدمة.
يمكن أن تؤدي الإدارة غير السليمة للأصول إلى نقاط ضعف أخرى ، مثل التعرض المفرط للبيانات ، وتسريب المعلومات ، والإحالة الجماعية Mass Assignment ، وضعف تحديد السرعة rate limit ، وثغرات الحقن.
يمكنك اكتشاف إدارة الأصول غير الصحيحة من خلال قراءة وثائق API القديمة ، وسجلات التغيير ، وسجل الإصدار في المستودعات repositories.
غالبًا ما تقوم المؤسسات بتضمين معلومات حول الإصدارات في الأسماء الخاصة بها للتمييز بين الإصدارات الأقدم والأحدث ، مثل /v1/ و /v2/ و /v3/ وما إلى ذلك. غالبًا ما تستخدم تطبيقات API التي لا تزال قيد التطوير مسارات مثل /alpha/ و /beta/ و / test / و /uat/ و /demo/. إذا كنت تعلم أن API تستخدم الآن apiv3.org/admin ولكن جزءًا من وثائق API يشير إلى apiv1.org/admin ، فيمكنك محاولة اختبار روابط مختلفة لمعرفة ما إذا كانت apiv1 أو apiv2 لا تزال فعالة. بالإضافة إلى ذلك ، قد يكشف سجل التغيير changelog في المؤسسة عن أسباب تحديث الإصدار 1 أو سبب ايقافه. إذا تمكنت من الوصول إلى الإصدار 1 ، فيمكنك اختبار نقاط الضعف هذه.
من دون استخدام الوثائق documentation ، يمكنك اكتشاف ثغرات إدارة الأصول غير السليمة Improper Assets Management من خلال استخدام التخمين أو الـ fuzzing أو هجمات القوة الغاشمة. راقب الأنماط في وثائق API أو طريقة تسمية المسارات ، ثم قم بارسال الطلبات بناءً على افتراضاتك.
نقاط الضعف في منطق الأعمال Business Logic Vulnerabilities
الثغرات الأمنية في منطق الأعمال (المعروفة أيضًا باسم عيوب منطق الأعمال ، أو BLFs) هي ميزات مقصودة لتطبيق معين يمكن للمهاجمين استخدامها بشكل ضار.
على سبيل المثال ، إذا كانت API تحتوي على ميزة رفع ملفات لا تتحقق من صحة الحمولات المشفرة encoded payloads ، فيمكن للمستخدم تحميل أي ملف طالما كان مشفرًا. سيسمح هذا للمستخدمين بتحميل وتنفيذ تعليمات برمجية عشوائية ، بما في ذلك الحمولات الضارة. في تلك الحالات ، تعتمد المنظمة أساسًا على الثقة كعنصر تحكم أمني من خلال توقع أن يتصرف المستهلك بأخلاقية. لسوء الحظ ، يرتكب حتى مطوري API أخطاء قد تؤدي إلى اختراق التطبيق.
يمكنك البحث في وثائق API عن علامات تدل على نقاط الضعف في منطق الأعمال. عبارات يجب ان تنتبه لها:
"استخدم الميزة X فقط لأداء الوظيفة Y." "لا تنفذ X في الرابط Y." "يجب على المدراء فقط تنفيذ الطلب X."
عندما تهاجم API ، تأكد من عصيان مثل هذه الطلبات لاختبار وجود عناصر التحكم في الأمان.
كمثال ، ضع في اعتبارك بوابة تسجيل دخول تطبيق ويب يستخدمها المستخدم عادةً للمصادقة على حسابه. لنفترض أن تطبيق الويب أصدر طلب API التالي:
هناك احتمال أن تتمكن من تجاوز المصادقة متعددة العوامل multifactor authentication ببساطة عن طريق تغيير قيمة الباراميتر MFA إلى false.
يمكن أن يكون اختبار عيوب منطق الأعمال أمرًا صعبًا لأن كل منظمة لها امان فريد من نوعه. ستواجه ادوات الفحص التلقائي وقتًا طويلاً في اكتشاف هذه المشكلات, يجب أن تفهم كيفية عمل الشركة و الـ API ثم التفكير في كيفية استخدام هذه الميزات لصالحك. ادرس منطق الأعمال للتطبيق بعقلية مخترق ، وحاول كسر أي افتراضات تم وضعها.
الخلاصة
من المهم أن تتقن نقاط الضعف هذه حتى تتمكن من ايجادها بسهولة ، والاستفادة منها أثناء عملية اختبار الاختراق ، وإبلاغ المنظمة بها لمنع المجرمين من الاضرار بالعملاء. الآن بعد أن أصبحت معتادًا على تطبيقات الويب والـ API ونقاط ضعفها ، فقد حان الوقت لإعداد جهاز الاختراق الخاص بك والبدء بالعمل على لوحة المفاتيح.