ثغرة Excessive Data Exposure وتعريض البيانات للخطر - تقنيات الاختراق وسبل الوقاية

مقدمة

تعتبر ثغرة Excessive data exposure التى تحتل الترتيب الثالث في قائمة أعلى عشرة تهديدات لأمان واجهات برمجة التطبيقات (API)، وفقًا لمؤسسة OWASP، يجب أن يسلط الضوء على انتشارها وكيفية حدوثها وأهمية التعامل معه داخل واجهات الـ API , وما هي أفضل الطرق لحماية واجهات برمجة التطبيقات الخاصة بك من الوقوع ضحية لهجوم إلكتروني يستهدف هذه الثغرة الأمنية؟ وكيف يحدث هذا التسريب من الأساس ؟ سنتطرق فى الحديث عن كل ما يخص هذة الثغرة والسبيل الى الحماية.

ما هى ثغرة Excessive Data Exposure ؟

حسب الأحصائيات الأخيرة لعام 2020 تعرض 91 ٪ من هجمات الـ API، وهذا الرقم فى تزايد مستمر بما في ذلك الشركات الكبرى مثل Paypal و Facebook و Equifax والتي شهدت خسائر فادحة لسمعتها وقيمة الشركة بسبب انتهاكات البيانات هذه.

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

كيفة تحدث هذة الثغرة ؟

سأتحدث الأن من المنظور التقنى للمطورين والمبرمجين وما يحدث فى تطبيقات الـ API ثم سأنتقل من المنظور الأمنى .

السيناريو الأول: 

• المنظور البرمجى : قد يفترض المبرمج أن عملاء الشركة فقط هم الذين سيتحدثون إلى الـ API ويعتقدون أن العميل سيتجاهل اى بيانات اضافية.
• المنظور الأمنى : للأسف ، لن يقتصر المهاجمون على بيانات العميل الرسمي فقط وسيختارون استخدام البيانات الإضافية.

السيناريو الثانى : 

• المنظور البرمجى : يمكن للمطورين استخدام وظائف البرمجة لتحويل بيانات API الداخلية إلى طلبات ارسال واستلام للـ API تلقائيًا. يمكن أن هذا يوفر هذا السيناريو زيادة في الإنتاجية لفرق التطوير.
• المنظور الأمنى : للأسف ، لن يقتصر المهاجمون على بيانات العميل الرسمي فقط وسيختارون استخدام البيانات الإضافية.

جيد الى الأن ولكن كيف يحدث هذا فى التطبيقات ؟ على سبيل المثال اذا أراد مالك متجر إلكتروني سحب أسماء العملاء ومواقعهم لاستخدامها في حملة تسويقية. إليك ما قد يبدو عليه طلب الـ API :

https://yourestore.com/api/v1/customers/show؟customer_id=123

سيقوم الـ API بسحب البيانات بالكامل لـ id=123 من قاعدة البيانات ، بما في ذلك المعلومات التي تبحث عنها مثل :

{
  "id": 123, 
  "username": "user123", 
  "real_name": "John Doe", 
  "location": "San Antonio, TX", 
  "phone_number": "321-123-4565", 
  "address": "514 W Commerce St, San Antonio, TX, USA",
  "creditCard": "2342 3424 5323 1234",
  "CVV": "123",
  “validUntil": "2030”
 }

عند ذلك الحالة تحدث هذة الثغرة عندما تُرجع الـ API الكثير من المعلومات ، بدلاً من تصفية الحقول المطلوبة فقط ، والتي يجب أن تبدو كما يلي:

{
  "id": 123,
  "real_name": "John Doe", 
  "location": "San Antonio, TX"
  "
}

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

السبيل الى الحماية 

من المؤسف بالنسبة لسبل الحماية تكون اكتشاف هذة الثغرة صعباً في الكشف عنها، خاصةً في حالة وجود واجهة برمجة تطبيقات مُنْشَأَة مُسَبَّقَاً، حيث تُعَدُّ البيانات الإضافية جزءًا من طلب الوصول الطبيعي. قد تساعد عمليات Source code review  في التخفيف من هذه المشكلة، ولكن ذلك يعتمد على لغة البرمجة والإطار العمل المستخدم. بالإضافة إلى ذلك، بالإضافة إلى ذلك ، لن تتمكن جميع أدوات SAST من التنبيه عند تضمين بيانات حساسة في استجابة طلبات الـ API.

يمكن ايضا استخدام برامج SDLC قوي وآمن يتضمن تدريبًا خاصًا بأمان API في طريقة مهمة لتقليل حالات عرض البيانات في الـ API. من خلال إعلام المطورين بأهمية إرسال البيانات المطلوبة فقط في الردود والافتراض الخاطئ لتصفية العميل.

هناك بعض الحلول ايضا من الممكن ان تساعد فى الوقاية من هذة الثغرة :

1- منع العميل من إجراء تصفية البيانات

القاعدة الذهبية بسيطة: لا تترك تصفية البيانات للعميل عند التعامل مع معلومات المستخدم الحساسة بل تعامل معها من البداية الى النهاية لحمايتها فعليًا.

2. تقليل ومراقبة ردود API الخاصة بك

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

3. تشفير البيانات أثناء ارسال واستلام الطلبات 

يؤدي تشفير البيانات أثناء النقل باستخدام طرق مثل SSL أو TLS أو FTPS إلى تقليل احتمالية وصول الأطراف الثالثة إلى البيانات الحساسة بشكل كبير حتى لو تمكن المهاجمين من اعتراض طلب لـ API تعتبر مجموعة من الرموز العشوائية التى تتطلب مفتاح للفك التشفير.

الخاتمة 

ثغرات الـ API هى ثغرات تعتبر ثرية جدا بالنسبة للمهاجمين ومجرموا الانترنت حيث تكلف ما يقارب اكثر من 75 مليار دولار فى السنة , واحدثكم هنا ايضا من المنظورين التقنى والأمنى لأن اغلب المبرمجين لا يهتموا بالجانب الأمنى لذلك وجب وجود مؤتمرات توعية بأستمرار بالمخاطر الأمنية وعمل ورش امنية لأختبار اختراق تطبيقات الـ API لذلك وجب التنبية والتوعية بالأستمرار والله الموفق والمستعان .