- بواسطة x32x01 ||
لو بتتعلم أمن تطبيقات الويب أو اختبار الاختراق، ففهم ثغرات
في الشرح ده هنربط بين جانبين مهمين: هجمات حجب الخدمة DoS وDDoS، وثغرات GraphQL الناتجة عن الاستعلامات المعقدة والـ
أما
النتيجة ممكن تكون:
المشكلة هنا إن حجب مصدر واحد فقط مش بيكون كافي، لأن الطلبات ممكن تيجي من مئات أو آلاف العناوين المختلفة.
عشان كده الحماية بتحتاج أكثر من طبقة، مثل:
مثلًا، بدل ما تسمح لعميل بإرسال عدد غير محدود من الطلبات إلى API، ممكن تضع حدًا مناسبًا حسب طبيعة الخدمة.
وده بيساعد في تقليل:
ميزة
لكن المرونة دي ممكن تتحول إلى مشكلة أمنية لو السيرفر بيسمح بتنفيذ استعلامات عميقة أو معقدة جدًا بدون وضع قيود مناسبة.
على سبيل المثال، لو كان بإمكان المستخدم إنشاء Query تحتوي على مستويات كثيرة من العلاقات المتداخلة، ممكن تنفيذ عملية تحتاج موارد كبيرة من:
💡 الفكرة الأساسية: المشكلة مش في GraphQL نفسها، لكن في السماح باستعلامات مكلفة بدون التحكم في تعقيدها أو عمقها أو معدل تنفيذها.
من الإجراءات المفيدة:
الـ
مش كل Input جاي من المستخدم ينفع نثق فيه.
لازم التطبيق يعمل:
ركز على أسئلة مثل:
في المحاضرة هنطبق عمليًا على ثغرات GraphQL، ونحل حوالي 6 Labs، مع شرح الثغرات من البداية للنهاية، بالإضافة إلى توضيح طريقة كتابة الـQueries والـMutations وفهم الـInput Fields والتعامل معها أثناء الاختبار.
🎥 رابط المحاضرة:
الـ
وبالتالي، تأمين GraphQL محتاج نظرة على الـAPI بالكامل، بداية من الـSchema والـInput Fields، وصولًا إلى الـDatabase والموارد التي بيستهلكها كل Request.
GraphQL مهم جدًا، خصوصًا لما تكون مرتبطة باستهلاك موارد السيرفر أو تنفيذ استعلامات معقدة بشكل ممكن يسبب DoS.في الشرح ده هنربط بين جانبين مهمين: هجمات حجب الخدمة DoS وDDoS، وثغرات GraphQL الناتجة عن الاستعلامات المعقدة والـ
Mutations.🛡️ أولًا: يعني إيه DoS وDDoS؟
ببساطة، هجومDoS أو Denial of Service بيهدف إلى استهلاك موارد السيرفر أو إغراقه بطلبات غير طبيعية، بحيث المستخدمين الحقيقيين يلاقوا الخدمة بطيئة جدًا أو غير متاحة.أما
DDoS فهو نفس الفكرة، لكن الهجوم بييجي من عدد كبير من الأجهزة والمصادر في نفس الوقت، وغالبًا يتم التحكم في الأجهزة المصابة من خلال شبكة Botnet.النتيجة ممكن تكون:
- 🖥️ استهلاك المعالج والذاكرة بشكل كبير.
- 🌐 استهلاك موارد الشبكة.
- ⏳ بطء شديد في الاستجابة.
- ❌ توقف بعض الخدمات أو السيرفر بالكامل.
- 👥 منع المستخدمين الحقيقيين من الوصول للتطبيق.
🔥 إزاي بتحصل هجمات DDoS؟
في هجوم DDoS، المهاجم ممكن يعتمد على عدد كبير من الأجهزة التي تم التحكم فيها مسبقًا، وبعد كده يتم إرسال عدد ضخم من الطلبات إلى الهدف.المشكلة هنا إن حجب مصدر واحد فقط مش بيكون كافي، لأن الطلبات ممكن تيجي من مئات أو آلاف العناوين المختلفة.
عشان كده الحماية بتحتاج أكثر من طبقة، مثل:
- 🧱 Web Application Firewall (WAF)
- 🚦 Rate Limiting
- 🔍 مراقبة حركة المرور واكتشاف الأنماط غير الطبيعية.
- 🛡️ استخدام خدمات متخصصة في تخفيف هجمات DDoS.
- ⚙️ ضبط السيرفر والتطبيق بحيث الطلبات المكلفة ما تستهلكش الموارد بشكل غير محدود.
🚦 أهمية Rate Limiting
الـRate Limiting من أهم وسائل الحماية، وفكرته ببساطة إنك تحدد عدد الطلبات المسموح بها من مستخدم أو عنوان IP خلال فترة زمنية معينة.مثلًا، بدل ما تسمح لعميل بإرسال عدد غير محدود من الطلبات إلى API، ممكن تضع حدًا مناسبًا حسب طبيعة الخدمة.
وده بيساعد في تقليل:
- الطلبات المتكررة بشكل مبالغ فيه.
- محاولات استهلاك موارد الـAPI.
- بعض أشكال إساءة استخدام الخدمات.
- تأثير بعض هجمات DoS على التطبيق.
Rate Limiting لوحده مش حل شامل لكل أنواع DDoS، لأن الهجوم الموزع ممكن يستخدم عددًا كبيرًا من المصادر.🧩 ثغرات DoS داخل GraphQL
هنا ندخل في الجزء المهم بالنسبة لاختبار اختراق تطبيقات الويب.ميزة
GraphQL إنها بتسمح للعميل بتحديد البيانات التي يحتاجها من خلال Query، وده بيدي مرونة كبيرة للمطورين.لكن المرونة دي ممكن تتحول إلى مشكلة أمنية لو السيرفر بيسمح بتنفيذ استعلامات عميقة أو معقدة جدًا بدون وضع قيود مناسبة.
على سبيل المثال، لو كان بإمكان المستخدم إنشاء Query تحتوي على مستويات كثيرة من العلاقات المتداخلة، ممكن تنفيذ عملية تحتاج موارد كبيرة من:
- CPU
- Memory
- Database
- Network
- وقت تنفيذ الـQuery
💡 الفكرة الأساسية: المشكلة مش في GraphQL نفسها، لكن في السماح باستعلامات مكلفة بدون التحكم في تعقيدها أو عمقها أو معدل تنفيذها.
🔎 إزاي نحمي GraphQL من Complex Queries؟
في التطبيقات الحقيقية، من المهم وضع قيود على الاستعلامات بدل السماح لأي Client بتنفيذ أي Query بدون حدود.من الإجراءات المفيدة:
- 🚧 تحديد أقصى
Query Depth. - ⚖️ حساب تكلفة أو تعقيد الاستعلام
Query Complexity. - 🚦 تطبيق
Rate Limitingعلى GraphQL endpoint. - 🔐 التأكد من تطبيق Authentication وAuthorization بشكل صحيح.
- 🧹 تعطيل أو تقييد
Introspectionعندما يكون ذلك مناسبًا لبيئة الإنتاج. - 🗄️ مراقبة الاستعلامات التي تصل إلى قاعدة البيانات.
- ⏱️ وضع حدود مناسبة لوقت تنفيذ العمليات المكلفة.
🧬 GraphQL Mutations وتسجيل المستخدمين
الجزء الثاني من الشرح بيركز علىGraphQL Mutations، وخصوصًا العمليات التي بتغير البيانات داخل التطبيق، مثل تسجيل مستخدم جديد.الـ
Mutation ممكن تستخدم لتنفيذ عمليات مثل:- 👤 إنشاء حساب جديد.
- 🔑 تغيير بيانات المستخدم.
- 📝 تحديث معلومات الحساب.
- 🗑️ حذف بيانات.
- 🔄 تنفيذ عمليات أخرى تؤثر على البيانات.
Input Fields التي يستقبلها الـMutation.مش كل Input جاي من المستخدم ينفع نثق فيه.
لازم التطبيق يعمل:
- التحقق من نوع البيانات.
- التحقق من القيم المسموح بها.
- تطبيق قواعد Validation.
- التأكد من صلاحيات المستخدم.
- حماية العمليات الحساسة.
- التعامل الآمن مع البيانات قبل إرسالها إلى قاعدة البيانات.
🧪 اختبار GraphQL بشكل آمن
أثناء اختبار الاختراق المصرح به، ممكن تبدأ بفهم الـSchema والـQueries والـMutations المتاحة، وبعدها تختبر طريقة تعامل التطبيق مع المدخلات والاستعلامات.ركز على أسئلة مثل:
- هل يمكن إرسال Query عميقة جدًا؟
- هل توجد حدود على تعقيد الاستعلام؟
- هل توجد Rate Limits؟
- هل الـMutation تقبل Input غير متوقع؟
- هل يتم التحقق من الصلاحيات على مستوى العملية؟
- هل يمكن تنفيذ عمليات حساسة بدون Authentication مناسب؟
- هل يؤدي إدخال معين إلى استهلاك موارد غير طبيعي؟
🎓 شرح عملي على GraphQL وثغراتها
لو GraphQL لسه مش واضحة بالنسبة لك، أو عايز تشوف الموضوع بشكل عملي بدل الشرح النظري، فيه شرح كامل ضمن كورسCWES.في المحاضرة هنطبق عمليًا على ثغرات GraphQL، ونحل حوالي 6 Labs، مع شرح الثغرات من البداية للنهاية، بالإضافة إلى توضيح طريقة كتابة الـQueries والـMutations وفهم الـInput Fields والتعامل معها أثناء الاختبار.
🎥 رابط المحاضرة:
✅ الخلاصة
ثغرات GraphQL مش مقتصرة على أخطاء Authentication أو Authorization فقط.الـ
Queries المعقدة والـMutations غير المؤمنة ممكن تفتح باب لمشاكل أمنية مختلفة، خصوصًا لو مفيش حدود واضحة على عمق الاستعلام، تعقيده، معدل الطلبات، وصلاحيات تنفيذ العمليات.وبالتالي، تأمين GraphQL محتاج نظرة على الـAPI بالكامل، بداية من الـSchema والـInput Fields، وصولًا إلى الـDatabase والموارد التي بيستهلكها كل Request.