أهم نقاط الضعف في OATH API
أهم نقاط الضعف في OATH API: مقدمة
عندما يتعلق الأمر بالاستغلال ، فإن واجهات برمجة التطبيقات هي أفضل مكان للبدء. API يتكون الوصول عادة من ثلاثة أجزاء. يتم إصدار الرموز المميزة للعملاء بواسطة خادم التفويض ، والذي يعمل جنبًا إلى جنب مع واجهات برمجة التطبيقات. تتلقى واجهة برمجة التطبيقات رموز الوصول من العميل وتطبق قواعد التفويض الخاصة بالمجال بناءً عليها.
تطبيقات البرامج الحديثة عرضة لمجموعة متنوعة من المخاطر. مواكبة أحدث المآثر والعيوب الأمنية ؛ يعد وجود معايير لهذه الثغرات الأمنية أمرًا ضروريًا لضمان أمان التطبيق قبل حدوث أي هجوم. تعتمد تطبيقات الجهات الخارجية بشكل متزايد على بروتوكول OAuth. سيتمتع المستخدمون بتجربة مستخدم أفضل بشكل عام ، بالإضافة إلى تسجيل الدخول والترخيص بشكل أسرع بفضل هذه التقنية. قد يكون أكثر أمانًا من التفويض التقليدي حيث لا يتعين على المستخدمين الكشف عن بيانات اعتمادهم مع تطبيق الجهة الخارجية من أجل الوصول إلى مورد معين. بينما يكون البروتوكول نفسه آمنًا وآمنًا ، فإن الطريقة التي يتم تنفيذه بها قد تجعلك عرضة للهجوم.
عند تصميم واجهات برمجة التطبيقات واستضافتها ، تركز هذه المقالة على ثغرات OAuth النموذجية ، بالإضافة إلى العديد من عوامل تخفيف الأمان.
تفويض مستوى الكائن المكسور
هناك مساحة واسعة للهجوم في حالة انتهاك التفويض نظرًا لأن واجهات برمجة التطبيقات توفر الوصول إلى الكائنات. نظرًا لأنه يجب مصادقة العناصر التي يمكن الوصول إليها بواسطة واجهة برمجة التطبيقات ، فهذا ضروري. تنفيذ عمليات التحقق من التفويض على مستوى الكائن باستخدام بوابة API. يجب أن يُسمح فقط لمن لديهم بيانات اعتماد الإذن المناسبة بالوصول.
مصادقة المستخدم المعطلة
تعتبر الرموز المميزة غير المصرح بها طريقة أخرى متكررة للمهاجمين للوصول إلى واجهات برمجة التطبيقات. قد يتم اختراق أنظمة المصادقة ، أو قد يتم كشف مفتاح واجهة برمجة التطبيقات عن طريق الخطأ. قد تكون رموز المصادقة يستخدمه المتسللون للوصول. قم بمصادقة الأشخاص فقط إذا كان من الممكن الوثوق بهم ، واستخدم كلمات مرور قوية. باستخدام OAuth ، يمكنك تجاوز مجرد مفاتيح واجهة برمجة التطبيقات والوصول إلى بياناتك. يجب أن تفكر دائمًا في كيفية دخولك وخروجك من المكان. يمكن استخدام رموز OAuth MTLS المقيدة للمرسل جنبًا إلى جنب مع بروتوكول TLS المتبادل لضمان عدم إساءة تصرف العملاء وتمرير الرموز المميزة إلى الطرف غير الصحيح أثناء الوصول إلى الأجهزة الأخرى.
ترقية API:
التعرض المفرط للبيانات
لا توجد قيود على عدد نقاط النهاية التي يمكن نشرها. في معظم الأوقات ، لا تتوفر جميع الميزات لجميع المستخدمين. من خلال الكشف عن بيانات أكثر مما هو ضروري للغاية ، فإنك تعرض نفسك والآخرين للخطر. تجنب الإفصاح عن الحساسية معلومات حتى يكون ذلك ضروريًا للغاية. قد يحدد المطورون من لديه حق الوصول إلى ماذا من خلال استخدام نطاقات ومطالبات OAuth. قد تحدد المطالبات أقسام البيانات التي يمكن للمستخدم الوصول إليها. يمكن جعل التحكم في الوصول أبسط وأسهل في الإدارة باستخدام بنية قياسية عبر جميع واجهات برمجة التطبيقات.
نقص الموارد وتحديد السعر
غالبًا ما تستخدم القبعات السوداء هجمات الحرمان من الخدمة (DoS) كوسيلة للقوة الغاشمة لإغراق الخادم وبالتالي تقليل وقت تشغيله إلى الصفر. مع عدم وجود قيود على الموارد التي قد يتم استدعاؤها ، تكون واجهة برمجة التطبيقات عرضة لهجوم منهك. باستخدام بوابة API أو أداة إدارة ، يمكنك تعيين قيود معدل لواجهات برمجة التطبيقات. يجب تضمين التصفية وتقسيم الصفحات ، بالإضافة إلى تقييد الإجابات.
التكوين الخاطئ لنظام الأمان
تعد إرشادات تكوين الأمان المختلفة شاملة إلى حد ما ، نظرًا لاحتمال كبير لسوء تهيئة الأمان. هناك عدد من الأشياء الصغيرة التي قد تعرض أمن النظام الأساسي للخطر. من الممكن أن تكتشف القبعات السوداء ذات الأغراض الخفية معلومات حساسة مرسلة ردًا على استفسارات مشوهة ، كمثال.
الاحالة الجماعية
لا يعني عدم تحديد نقطة النهاية علنًا أنه لا يمكن للمطورين الوصول إليها. قد يتم اعتراض واجهة برمجة التطبيقات السرية بسهولة وإجراء هندسة عكسية بواسطة المتسللين. ألق نظرة على هذا المثال الأساسي ، الذي يستخدم رمز Bearer Token مفتوحًا في واجهة برمجة تطبيقات "خاصة". من ناحية أخرى ، قد توجد وثائق عامة لشيء مخصص حصريًا للاستخدام الشخصي. يمكن استخدام المعلومات المكشوفة من قبل القبعات السوداء ليس فقط لقراءة خصائص الكائن ولكن أيضًا للتلاعب بها. اعتبر نفسك مخترقًا وأنت تبحث عن نقاط ضعف محتملة في دفاعاتك. السماح فقط لمن لديهم الحقوق المناسبة بالوصول إلى ما تم إرجاعه. لتقليل الثغرات الأمنية ، قم بتقييد حزمة استجابة API. يجب ألا يضيف المستجيبون أي روابط غير مطلوبة تمامًا.
ترقية API:
إدارة الأصول غير السليمة
بصرف النظر عن تعزيز إنتاجية المطور ، تعد الإصدارات الحالية والوثائق ضرورية لسلامتك. استعد لإدخال الإصدارات الجديدة وإيقاف استخدام واجهات برمجة التطبيقات القديمة مسبقًا. استخدم واجهات برمجة تطبيقات أحدث بدلاً من السماح للواجهات القديمة بالبقاء قيد الاستخدام. يمكن استخدام مواصفات API كمصدر أساسي للحقيقة للتوثيق.
عن طريق الحقن
واجهات برمجة التطبيقات عرضة للحقن ، وكذلك تطبيقات مطوري الطرف الثالث. يمكن استخدام التعليمات البرمجية الضارة لحذف البيانات أو سرقة المعلومات السرية ، مثل كلمات المرور وأرقام بطاقات الائتمان. الدرس الأكثر أهمية الذي يجب استخلاصه من هذا هو عدم الاعتماد على الإعدادات الافتراضية. يجب أن يكون مورد الإدارة أو البوابة لديك قادرًا على تلبية احتياجات التطبيق الفريدة الخاصة بك. يجب ألا تتضمن رسائل الخطأ معلومات حساسة. لمنع تسرب بيانات الهوية خارج النظام ، يجب استخدام الأسماء المستعارة الزوجية في الرموز المميزة. وهذا يضمن عدم تمكن أي عميل من العمل معًا لتحديد هوية المستخدم.
التسجيل والمراقبة غير كافيين
عندما يحدث هجوم ، تتطلب الفرق استراتيجية رد فعل مدروسة جيدًا. سيستمر المطورون في استغلال الثغرات الأمنية دون أن يتم اكتشافهم في حالة عدم وجود نظام تسجيل ومراقبة موثوق به ، مما سيزيد من الخسائر ويلحق الضرر بنظرة الجمهور إلى الشركة. اعتماد استراتيجية صارمة لمراقبة API واختبار نقطة النهاية للإنتاج. يجب أن يكافأ مختبرو القبعة البيضاء الذين يكتشفون نقاط الضعف في وقت مبكر بنظام المكافآت. يمكن تحسين مسار السجل من خلال تضمين هوية المستخدم في معاملات API. تأكد من تدقيق جميع طبقات بنية API الخاصة بك باستخدام بيانات Access Token.
وفي الختام
قد يقوم مصممو المنصات بتجهيز أنظمتهم لتسبق المهاجمين بخطوة باتباع معايير الضعف المعمول بها. نظرًا لأن واجهات برمجة التطبيقات قد توفر إمكانية الوصول إلى معلومات التعريف الشخصية (PII) ، فإن الحفاظ على أمان هذه الخدمات أمر بالغ الأهمية لاستقرار الشركة والامتثال للتشريعات مثل القانون العام لحماية البيانات (GDPR). لا ترسل أبدًا رموز OAuth المميزة مباشرة عبر واجهة برمجة التطبيقات بدون استخدام بوابة API ونهج Phantom Token.
ترقية API:
