🚀 أصبحت CloudSek أول شركة للأمن السيبراني من أصل هندي تتلقى استثمارات منها ولاية أمريكية صندوق
اقرأ المزيد

اقرأ الجزء الأول على GraphQL هنا.
في مدونة الأسبوع الماضي، تعرفنا على أساسيات GraphQL وكيفية تكوين خادم GraphQL. ناقشنا أيضًا بعض الاختلافات الرئيسية بين GraphQL و REST API.
فيما يلي ملخص موجز:
GraphQL هي لغة استعلام مفتوحة المصدر لواجهات برمجة التطبيقات التي تساعد على تحميل البيانات من خادم إلى العميل بطريقة أبسط بكثير. بمقارنة الجوانب المتعددة لكل من GraphQL و REST API، رأينا أن عمليات GraphQL تتفوق على عمليات REST API. على الرغم من أن فوائد هذه اللغة مفتوحة المصدر كثيرة، إلا أنها تأتي مع ثغرات أمنية يميل المطورون إلى مواجهتها من وقت لآخر.
ومن هناك، سنناقش في الجزء الثاني ما يلي:
GraphQL هي واحدة من البدائل الأكثر كفاءة ومرونة لواجهة برمجة تطبيقات REST. ومع ذلك، فهي عرضة لنفس الهجمات التي تتعرض لها REST API.
تعتمد GraphQL على مطوري API لتنفيذ مخططها للتحقق من صحة البيانات. خلال هذه العملية يمكنهم إدخال أخطاء عن غير قصد. بالإضافة إلى ذلك، تتم إضافة الميزات والوظائف الجديدة، التي تلبي متطلبات العميل، إلى تطبيقات الويب كل ساعة. هذا يزيد أيضًا من فرصة ارتكاب المطورين للأخطاء.
نسلط الضوء هنا على بعض التكوينات الخاطئة الشائعة والمشكلات في GraphQL، والتي تسمح للقراصنة باستغلالها.
يمكن أن تمنح قيود عملية مصادقة المستخدم وصولاً غير مصرح به لأي شخص. في حالة وجود خلل في عملية المصادقة، يفشل تطبيق الويب في تقييد الوصول إلى كائن أو مورد مما يؤدي إلى تسليم بيانات مستخدم آخر دون إجراء فحوصات التخويل. تسمح الطريقة المعيبة للمهاجمين بتجاوز قيود الوصول المقصودة، وتعريض بيانات المستخدم لإساءة الاستخدام أو الحذف أو التغيير.
لنفكر في السيناريو الذي يريد فيه المستخدم، بمعرف الكائن الرقمي: 5002، استرداد معلومات التعريف الشخصية الخاصة به مثل معرف البريد الإلكتروني وكلمة المرور والاسم ورقم الهاتف المحمول وما إلى ذلك إذا كان هذا المستخدم يستخدم عن قصد أو عن غير قصد معرف مستخدم مختلفًا (على سبيل المثال، 5005)، وكان هذا المعرف ينتمي إلى مستخدم نشط آخر، ولكن البحث يسرب بياناته، فإنه يظهر أن محلل GraphQL يسمح بالوصول غير المصرح به.
يتكون الاستعلام التالي من معرف مستخدم يمثل مستخدمًا قام بتسجيل الدخول ويجلب معلومات تحديد الهوية الشخصية للمستخدم:
الاستعلام عن بيانات المستخدم {
المستخدمون (المعرف: 5002) {
اسم
البريد الإلكتروني
معرف
كلمة المرور
رقم الهاتف المحمول
مفتاح التخويل
رقم الحساب المصرفي
رقم السيرة الذاتية
}
}
ومع ذلك، إذا كان نفس المستخدم المصادق قادرًا على جلب بيانات المعرف 5005، فهذا يعني وجود تحكم غير صحيح في الوصول إلى كائن أو مورد. إنه يمكّن المخترقين/المهاجمين من الوصول إلى بيانات العديد من المستخدمين. كما يسمح للمهاجم بتنفيذ أنشطة ضارة مثل تحرير بيانات المستخدم وحذف المستخدم من قاعدة البيانات وما إلى ذلك.
في استعلام واحد، يكون قادرًا على اتخاذ إجراءات متعددة استجابة لطلبات HTTP المتعددة. تزيد هذه الميزة من تعقيد واجهات برمجة تطبيقات GraphQL، مما يجعل من الصعب على مطوري API الحد من عدد طلبات HTTP. إذا لم يتم التعامل مع الطلب بشكل صحيح من قبل المحلل في طبقة GraphQL API، فإنه يفتح بابًا للجهات الفاعلة لمهاجمة واجهة برمجة التطبيقات وتنفيذ هجمات رفض الخدمة (DoS).
لتجنب ذلك، يجب السماح فقط بعدد محدد من الطلبات في الدقيقة لواجهة برمجة التطبيقات، وفي حالة تجاوز عدد الطلبات الحد، يجب أن يؤدي ذلك إلى حدوث خطأ أو رفض الاستجابة.
لنلقِ نظرة على المثال التالي لمثل هذه الاستعلامات المتداخلة:
الاستعلام: استعلام متداخل {
جميع المستخدمين {
المشاركات {
متابع {
مؤلف {
المشاركات {
متابع {
مؤلف {
المشاركات {
متابع {
مؤلف {
المشاركات {
معرف
}
}
}
}
}
}
}
}
}
}
}
}
تعمل بعض نقاط نهاية API على تمكين الاتصالات من خادم إلى خادم وليست مخصصة لعامة الناس. ومع ذلك، فإن ميزة GraphQL للتأمل الذاتي تجعل هذا ممكنًا دون صعوبة كبيرة.
افترض الحالة التي يرسل فيها شخص ما استعلامًا مقابل نقطة نهاية داخلية فقط للوصول إلى بيانات اعتماد المسؤول وبالتالي الحصول على امتياز المسؤول.
في ما يلي مثال لنقطة نهاية واحدة لديها القدرة على السماح للمهاجمين بالوصول إلى مكالمات API المخفية من الواجهة الخلفية.

هناك العديد من مواقع الويب مثل https://apis.guru/graphql-voyager/ التي تعرض القائمة الكاملة لمكالمات API المتاحة في الواجهة الخلفية. يوفر هذا فهمًا أفضل لواجهته ويوضح أيضًا طرقًا لجمع المعلومات الحساسة من الخادم.

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


لكن العيب الرئيسي لاختباره في Burp Suite هو التصور غير الكافي لوثائق المخطط بالكامل. قد يؤدي هذا إلى تجاهل العديد من عمليات التهيئة الخاطئة الشائعة، ما لم نحدد الوثائق المناسبة لنقاط نهاية API أو المكالمات المنفذة في الواجهة الخلفية. هناك مشكلة أخرى تتعلق باستخدام Burp وهي أنه يتعين علينا تعديل الاستعلام أو تصحيحه يدويًا مما يجعل العملية أكثر تعقيدًا. يمكن حل جميع هذه المشكلات بمساعدة الطريقة التالية.
يساعد Altair في تصحيح استعلامات GraphQL وتطبيقات الخادم. إنه يصحح مشكلة تعديل الاستعلامات يدويًا ويساعد بدلاً من ذلك على التركيز على الجوانب الأخرى.
يتوفر Altair GraphQL كبرنامج لأنظمة التشغيل Mac و Linux و Windows OS وأيضًا كملحق لجميع المتصفحات تقريبًا. يوفر التوثيق المناسب للمخطط بأكمله المتاح في الواجهة الخلفية. كل ما نحتاج إليه هو تكوين تطبيق الويب الذي نختبره.

يمكن رؤية جميع عمليات GraphQL الثلاث في قسم التوثيق كما هو موضح أعلاه. يمكنك أيضًا استكشاف هذه الخيارات للحصول على حقول أخرى ونقاط نهاية API وما إلى ذلك.

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


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