Taint Analysis for Graph APIs Focusing on Broken Access Control
تقدم هذه الورقة نهجاً هجيناً جديداً يجمع بين تحليل تتبع التدفق القائم على تحويل الرسم البياني الساكن والتحقق الديناميكي للكشف المنهجي عن ثغرات التحكم في الوصول المكسور، المباشرة وغير المباشرة، في واجهات برمجة تطبيقات الرسوم البيانية (Graph APIs)، كما هو موضح من خلال تطبيقه على واجهة برمجة تطبيقات GitHub GraphQL.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أن لديك مكتبة رقمية ضخمة حيث يمكن للناس استعارة الكتب، وكتابة ملاحظات فيها، وحتى تمزيق صفحاتها. هذه المكتبة تُدار بواسطة واجهة برمجة تطبيقات رسومية (Graph API). فكر في واجهة برمجة التطبيقات هذه ليس كبرنامج كمبيوتر ممل، بل كـ أمين مكتبة فائق الكفاءة يدرك أن كل شيء في المكتبة مترابط. "الكتاب" هو عقدة (Node)، وحقيقة أن "الكتاب أ" مرتبط بـ "المؤلف ب" هي حافة (Edge) تربط بينهما.
الآن، تخيل أن لهذه المكتبة قواعد صارمة:
- المالك يمكنه فعل أي شيء (استعارة، كتابة، تدمير).
- المتعاون يمكنه الاستعارة والكتابة، ولكن ليس التدمير.
- الضيف يمكنه فقط النظر إلى الغلاف.
المشكلة؟ أحياناً، يرتكب أمين المكتبة خطأً. ربما يُسمح لضيف بالتمكن من تمزيق صفحة عن طريق الخطأ، أو يُمنع المالك من كتابة ملاحظة. هذا ما يسمى بخلل التحكم في الوصول (Broken Access Control). إنه يشبه إعطاء مفاتيح خزنة المدير التنفيذي لعامل نظافة، أو قفل المكتب في وجه المدير التنفيذي نفسه.
تقدم هذه الورقة طريقة جديدة لاكتشاف هذه الأخطاء قبل أن يكتشفها المتربصون. هم يسمونها تحليل التلوث (Taint Analysis). وإليك كيف تعمل، مقسمة إلى خطوات بسيطة:
1. استراتيجية "الملاحظة اللاصقة" (التلويث/Tainting)
تخيل أنك تأخذ ملاحظة لاصقة حمراء زاهية وتضعها على كل قطعة من المعلومات الحساسة في المكتبة (مثل "مستودع" أو "مشروع"). أنت تقول لأمين المكتبة: "مهلاً، أي شيء عليه ملاحظة لاصقة حمراء هو شيء خاص. فقط الأشخاص الذين يحملون الشارة المناسبة يمكنهم لمسه."
في الورقة، يسمون هذا التلويث (Tainting). هم يضعون علامات على "العقد" الرقمية (كائنات البيانات) التي تحتاج إلى حماية.
2. "المصدر" و"المصب" (The Source and the Sink)
الآن، ينظر المؤلفون إلى الوصف الوظيفي لأمين المكتبة (استدعاءات API) ويصنفونها إلى نوعين:
- المصدر (الخالق): هذه هي الأفعال التي تنشئ عناصر جديدة مغطاة بالملاحظات اللاصقة. (مثال: "إنشاء مستودع جديد").
- المصب (المتلاعب): هذه هي الأفعال التي تلمس، أو تغير، أو تحذف تلك العناصر المغطاة بالملاحظات اللاصقة. (مثال: "تحديث مستودع").
الخطر يحدث عندما يقوم مصدر بإنشاء عنصر سري، ثم يحاول مصب لمسه لاحقاً، ولكن الشخص الذي يقوم باللمس لا يملك الشارة الصحيحة.
3. الفحص الساكن (لعبة "ماذا لو؟")
قبل اختبار المكتبة فعلياً، يلعب المؤلفون لعبة "ماذا لو؟" باستخدام تقنية تسمى تحليل الأزواج الحرجة (Critical Pair Analysis).
تخيل أن لديك بطاقتين:
- البطاقة أ: "إنشاء ملف سري."
- البطاقة ب: "حذف ملف سري."
يسأل الكمبيوتر: "إذا قمت بالبطاقة أ، ثم قمت بالبطقة ب مباشرة، هل سيسمح النظام بذلك؟"
- التدفق المباشر: إذا حدثت البطاقة ب مباشرة بعد البطاقة أ، يمكن للكمبيوتر رؤية ما إذا كانت القواعد قد كُسرت بسهولة.
- التدفق غير المباشر (الجزء الصعب): ماذا لو كانت هناك بطاقات أخرى في المنتصف؟
- البطاقة أ: إنشاء ملف.
- البطاقة الوسطى: إضافة مجلد إلى الملف.
- البطاقة ب: حذف الملف.
يحاول الكمبيوتر معرفة ما إذا كانت "البطاقة الوسطى" تغير القواعد. أحياناً، قد تفتح البطاقة الوسطى الباب بالخطأ للمتربص. توضح الورقة أن طريقتهم جيدة جداً في رصد الأخطاء المباشرة وبعض الأخطاء غير المباشرة، بشرط ألا تصبح القواعد فوضوية للغاية.
4. الفحص الديناميكي (اختبار "العالم الحقيقي")
لعبة "ماذا لو؟" رائعة، لكنها قد تفوت بعض الأشياء أو تعطي تنبيهات ليست خطيرة حقاً (إنذارات كاذبة). لذا، ينتقل المؤلفون إلى التحليل الديناميكي.
هنا يتم تشغيل الاختبارات فعلياً. هم يكتبون نصاً برمجياً (Script) يعمل كأنه مستخدم مشاكس.
- الاختبار الجيد: يحاولون تحديث ملف بصفتهم "المالك". (النتيجة المتوقعة: نجاح).
- الاختبار السيئ: يحاولون تحديث ملف بصفتهم "ضيفاً". (النتيجة المتوقعة: فشل/خطأ).
إذا نجح "الاختبار السيئ" في الوقت الذي كان يجب أن يفشل فيه، فقد وجدوا ثغرة أمنية! لقد سمح أمين المكتبة للضيف بتمزيق صفحة!
5. الإثبات من العالم الحقيقي (GitHub)
لإثبات نجاح ذلك، طبقوه على GitHub (النسخة الواقعية من مكتبتنا).
- نظروا إلى مشكلة محددة حيث كان بإمكان المستخدم مقارنة فروع الكود (code branches) بطريقة لم يكن ينبغي له القيام بها، اعتماداً على كيفية تسجيل دخوله.
- نظام "الملاحظة اللاصقة" الخاص بهم حدد المسار الخطير.
- نص "اختبار العالم الحقيقي" البرمجي قام بالفعل بإعادة إنتاج الخطأ، مما أكد أن الثغرة الأمنية كانت حقيقية.
ملخص: لماذا هذا الأمر رائع؟
معظم الأدوات الأمنية تنظر إلى الكود سطراً بسطر، مثل قراءة رواية كلمة بكلمة. أما هذه الورقة، فهي تنظر إلى الروابط بين الأفعال، مثل النظر إلى حبكة القصة.
- الاستعارة: الأمر يشبه وجود حارس أمن لا يكتفي بفحص ما إذا كنت تملك مفتاحاً فحسب، بل يراقب تسلسل يومك بالكامل. "لقد أنشأت غرفة سرية، ثم مشيت عبر ممر، والآن تحاول فتح الغرفة السرية. مهلاً لحظة، أنت لم تكن تملك مفتاحاً للممر!"
من خلال الجمع بين خريطة رياضية رسمية للمكتبة (تحويل الرسم البياني - Graph Transformation) ونظام تتبع "الملاحظات اللاصقة" (تحليل التلوث - Taint Analysis)، تقدم هذه الورقة لخبراء الأمن طريقة منهجية وقوية للعثور على "الأقفال المكسورة" في تطبيقات الويب الحديثة قبل أن يجدها المخترقون.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.