أهم 10 تهديدات لتطبيق الويب في OWASP

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

يوضّح هذا المستند مختلف الأساليب التي يمكنك استخدامها في Apigee لمعالجة نقاط ضعف الأمان التي حدّدتها OWASP. للاطّلاع على طرق إضافية موثّقة في Apigee، يُرجى الاطّلاع على خيارات التخفيف من المخاطر في قائمة OWASP لأهم 10 ثغرات أمنية لعام 2021 على Google Cloud.

نظرة عامة

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

‫OWASP هو منتدى مفتوح مخصّص لمساعدة المؤسسات في تطوير وشراء وصيانة التطبيقات وواجهات برمجة التطبيقات الموثوق بها. من خلال مشروع أمان واجهات برمجة التطبيقات التابع لمؤسسة OWASP، تنشر مؤسسة OWASP أهم المخاطر الأمنية التي تواجه تطبيقات الويب وواجهات REST API، وتقدّم اقتراحات بشأن كيفية التعامل مع هذه المخاطر.

باستخدام Apigee، يمكن لطبقة خادم وكيل واجهة برمجة التطبيقات رصد طلبات واجهة برمجة التطبيقات غير الصالحة وحظرها والإبلاغ عنها من العميل قبل معالجة الطلبات على أنظمة الخلفية، ما يقلّل من المخاطر ويحمي خدماتك. يمكن أن تتضمّن الطلبات غير الصالحة أي مكوّن يشكّل بروتوكول HTTP على مستوى التطبيق:

  • عنوان URL
  • العناوين
  • المسار
  • الحمولة

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

تتيح لك منصة إدارة واجهات برمجة التطبيقات الذكية من Apigee معالجة أهم الثغرات الأمنية في واجهات برمجة التطبيقات وفقًا لمعايير OWASP بسلاسة، وذلك من خلال اتّباع نهج يركّز على الاستهلاك في تصميم واجهات برمجة التطبيقات وربطها بأنظمة الخلفية. في ما يلي قائمة بالسياسات/الإعدادات التي تنصح بها Apigee للتعامل مع أبرز تهديدات OWASP المتعلقة بخدمات REST.

حلول Apigee لأهم 10 مخاطر أمنية في تطبيقات الويب وفقًا لبرنامج OWASP لعام 2017

هناك العديد من المخاوف الأمنية عندما يتعلق الأمر بإنشاء تطبيقات الويب وتأمينها. أصدرت مؤسسة OWASP قائمتها لأهم 10 تهديدات أمنية في 2017 لتطبيقات الويب.  على الرغم من أنّ تطبيقات الويب تتضمّن العديد من الأجزاء، تعتمد معظم تطبيقات الويب الحديثة بشكل كبير على واجهات REST API.  لا يُقصد من Apigee تلبية جميع احتياجات الأمان لتطبيق ويب، ولكن يمكن أن تؤدي دورًا محوريًا في تأمين واجهات REST API. في ما يلي أهم التهديدات الأمنية التي حدّدتها OWASP مع أوصاف لكيفية استخدام Apigee للمساعدة في التصدّي لهذه التهديدات.

‫A1:2017 - الحقن

للحماية من إدخال بيانات غير موثوق بها، مثل SQL وNoSQL وLDAP وJavaScript، ما قد يؤدي إلى تنفيذ أوامر غير مقصودة أو الوصول إلى بيانات غير مصرّح بها، توفّر Apigee العديد من السياسات للتحقّق من صحة الإدخال للتأكّد من أنّ القيم التي يقدّمها العميل تتطابق مع التوقّعات قبل السماح بإجراء المزيد من المعالجة. تتحقّق Apigee Edge، التي تعمل كخادم لطلبات البيانات الواردة من واجهة برمجة التطبيقات، من أنّ بنية الحمولة تندرج ضمن نطاق مقبول، ويُعرف ذلك أيضًا باسم التحقّق من الحدّ. يمكنك إعداد خادم وكيل لواجهة برمجة التطبيقات كي يحوّل روتين التحقّق من صحة الإدخال الإدخال لإزالة تسلسلات الأحرف الخطيرة واستبدالها بقيم آمنة.

تتوفّر عدة طرق للتحقّق من صحة الإدخال باستخدام منصة Apigee:

  • تتحقّق JSONThreatProtection من حِمل JSON بحثًا عن تهديدات.
  • XMLThreatProtection تتحقّق من حمولة XML بحثًا عن التهديدات.
  • يمكن إجراء عملية التحقّق من صحة المَعلمات باستخدام JavaScript.
  • يمكن إجراء عملية التحقّق من صحة العنوان باستخدام JavaScript.
  • يمكن التعامل مع SQLCodeInjection باستخدام سياسة RegularExpressionProtection.

التحقّق من صحة أنواع المحتوى:

A2:2017 - المصادقة وإدارة الجلسات المعطّلة

يمكن للمهاجمين الوصول إلى كلمات المرور ورموز الجلسات والمفاتيح لانتحال هوية مستخدمين آخرين من خلال استغلال عيوب التنفيذ في التطبيقات. هذه المشكلة تتعلّق بالتنفيذ أكثر من المنتج نفسه.  توفر Apigee سياسات VerifyApiKey وOAuth وJSON Web Token (JWT)، التي تساعد في الحماية من هذه الثغرة الأمنية.

التحقّق من صحة مفتاح واجهة برمجة التطبيقات

التحقّق من صحة مفتاح واجهة برمجة التطبيقات هو أبسط شكل من أشكال الأمان المستند إلى التطبيق الذي يمكن إعداده لواجهة برمجة التطبيقات. يعرض تطبيق العميل ببساطة مفتاح واجهة برمجة التطبيقات مع طلبه، ثم يتحقّق Apigee Edge، من خلال سياسة مرفقة بخادم وكيل لواجهة برمجة التطبيقات، من أنّ مفتاح واجهة برمجة التطبيقات في حالة معتمَدة للمورد المطلوب.

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

قد يشير مصطلح "مفاتيح واجهة برمجة التطبيقات" أحيانًا إلى معانٍ مختلفة. في Apigee، عند إنشاء علاقة بين التطبيق والمنتج، تنشئ Apigee معرّف عميل وسرّ عميل.  يشير البعض إلى كل من المعرّف والسر باسم مفتاح واجهة برمجة التطبيقات. يشير البعض إلى معرّف العميل فقط على أنّه مفتاح واجهة برمجة التطبيقات. في واجهة مستخدم Edge، سيظهر لك "مفتاح المستهلك" و "سر المستهلك".

في سياسة VerifyAPIKey، يتم التحقّق من معرّف العميل فقط، أو "مفتاح المستهلك". يحصل المطوّرون على مفتاح العميل عند تسجيل تطبيقاتهم في Apigee وربط التطبيق بمنتج واجهة برمجة تطبيقات. يضمّن المطوّرون مفتاح المستهلك في الطلبات التي يرسلها التطبيق إلى خوادم وكيل واجهة برمجة التطبيقات المجمّعة في منتج واجهة برمجة التطبيقات.

تتيح Apigee أيضًا إمكانية استيراد مفاتيح واجهة برمجة التطبيقات الحالية من مصادر خارجية.

بالنسبة إلى أنواع منح الإذن باستخدام OAuth، يتم استخدام كل من معرّف العميل وسر العميل.

OAuth 2.0

يتيح إطار عمل تفويض OAuth 2.0 لتطبيق تابع لجهة خارجية الحصول على إذن محدود بالوصول إلى خدمة HTTP، إما نيابةً عن مالك المورد من خلال تنسيق تفاعل الموافقة بين مالك المورد وخدمة HTTP، أو من خلال السماح للتطبيق التابع لجهة خارجية بالحصول على إذن الوصول نيابةً عن نفسه.

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

JWT

تُستخدَم رموز JSON المميّزة للويب، أو JWT، عادةً لمشاركة المطالبات أو التأكيدات بين التطبيقات المرتبطة. توفّر Apigee إمكانية استخدام رموز JWT من خلال ثلاث سياسات.

  • إنشاء رموز GenerateJWT المميّزة (متوافقة مع توقيع HS256 وRS256)
  • ValidateJWT tokens
  • فك ترميز رموز JWT المميّزة بدون التحقّق منها

‫A3:2017 - تعرُّض البيانات الحسّاسة لخطر التسريب

يستهدف المهاجمون البيانات الحسّاسة، مثل معلومات بطاقة الدفع وأرقام التأمين الاجتماعي وبيانات اعتماد تسجيل الدخول ومعلومات تكشف الهوية الشخصية (PII) والمعرّفات الضريبية، وذلك لارتكاب جرائم سرقة الهوية وسرقة الأموال والاحتيال وغيرها. يجب أن تنفّذ تطبيقات الويب عملية التشفير، سواء كانت البيانات محفوظة أو قيد النقل، وأن تستخدم استراتيجيات أخرى لضمان حماية البيانات الحسّاسة.

بروتوكول أمان طبقة النقل (TLS) (الذي كان يُعرف سابقًا باسم SSL) هو تكنولوجيا الأمان العادية لإنشاء رابط مشفّر بين خادم ويب وعميل ويب، مثل متصفّح أو تطبيق. تتيح Apigee بروتوكول أمان طبقة النقل (TLS) أحادي الاتجاه وثنائي الاتجاه.

يتم توفير بروتوكول أمان طبقة النقل (TLS) في اتجاه الشمال (العميل يتصل بواجهة برمجة التطبيقات التي تعمل كخادم) من خلال استخدام إعداد المضيف الافتراضي. يمكن ضبط مضيف افتراضي لاستخدام بروتوكول أمان طبقة النقل (TLS) في اتجاه واحد أو اتجاهين.

يمكن استخدام بروتوكول أمان طبقة النقل (TLS) في اتجاه الخادم الخلفي (Apigee كعميل يتصل بخدمة الخلفية) من خلال استخدام إعدادات خادم مستهدف.  يمكن ضبط خادم مستهدف لاستخدام بروتوكول أمان طبقة النقل (TLS) أحادي الاتجاه أو ثنائي الاتجاه.

تتيح Apigee العديد من خيارات إعداد طبقة النقل الآمنة.

يضمن فرض استخدام بروتوكول أمان طبقة النقل الثنائي الاتجاه أنّ العميل يستخدم شهادة تم إعدادها مسبقًا على Apigee. تقدّم OWASP أيضًا أفضل الممارسات المتعلّقة ببروتوكول أمان طبقة النقل (TLS).

في Apigee hybrid، تتوفّر طبقة النقل الآمنة (TLS) عند نقطة الدخول من خلال اسم مستعار للمضيف، وهو مفهوم مشابه للمضيف الافتراضي.

في ما يلي إرشادات لتأمين البيانات الحسّاسة:

  • استخدِم منصة تتوافق مع بروتوكول أمان طبقة النقل (TLS) أحادي الاتجاه وثنائي الاتجاه، ما سيوفّر الحماية على مستوى البروتوكول.
  • استخدِم سياسات مثل AssignMessage policy وJavaScript policy لإزالة البيانات الحساسة قبل إرسالها إلى العميل.
  • استخدِم تقنيات OAuth العادية، وفكِّر في إضافة HMAC أو التجزئة أو الحالة أو الرقم الخاص أو مفتاح حماية تبادل الرموز (PKCE) أو غيرها من التقنيات لتحسين مستوى المصادقة لكل طلب.
  • استخدِم إعدادات إخفاء البيانات لإخفاء البيانات الحسّاسة في أداة Edge Trace.
  • يجب توخّي الحذر عند تخزين أي بيانات حسّاسة في ذاكرة التخزين المؤقت (أو تشفير البيانات الحسّاسة المخزّنة في ذاكرة التخزين المؤقت). في Edge، يمكنك تشفير البيانات الحساسة غير النشطة في خرائط قيم المفاتيح.

‫A4:2017 - كيانات XML الخارجية

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

تتيح لك سياسة ExtractVariables في Apigee استخراج المحتوى من طلب أو ردّ وتعيين هذا المحتوى لمتغيّر. يمكنك استخراج أي جزء من الرسالة، بما في ذلك العناوين ومسارات URI وحمولات JSON/XML ومَعلمات النماذج ومَعلمات طلبات البحث. تعمل السياسة من خلال تطبيق نمط نصي على محتوى الرسالة، وعند العثور على تطابق، يتم ضبط متغيّر باستخدام محتوى الرسالة المحدّد.

تتضمّن Apigee محلّلاً مضمّنًا لملفات XML كجزء من النظام الأساسي الذي يستخدم XPath لاستخراج البيانات. يتضمّن أيضًا سياسة XMLThreatProtection للحماية من حمولات XML الضارة.

A5:2017 - Broken Access Control

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

تتيح Apigee اتّباع نهج متعدد الطبقات لتنفيذ عناصر التحكّم في الوصول من أجل منع الجهات الضارة من إجراء تغييرات غير مصرَّح بها أو الوصول إلى النظام.

عناصر التحكّم في الوصول إلى واجهة مستخدم Edge

عناصر التحكّم في الوصول إلى "بوابة المطوّرين" في Apigee

  • إعداد الدخول الموحّد باستخدام موفِّر الهوية الخاص بشركتك
  • ضبط التحكّم في الوصول المستند إلى الدور (RBAC) للسماح للمستخدمين فقط بالوصول إلى الوظائف والإعدادات التي يحتاجون إليها على بوابات المطوّرين المستندة إلى Drupal
  • ضبط بوابات المطوّرين لعرض منتجات واجهة برمجة تطبيقات معيّنة حسب دور المستخدم
  • اضبط البوابة لإظهار المحتوى أو إخفائه استنادًا إلى دور المستخدم.

عناصر التحكّم في الوصول إلى واجهة برمجة التطبيقات في وقت تشغيل Apigee

  • يمكن فرض الوصول إلى واجهات برمجة التطبيقات من خلال مفاتيح واجهة برمجة التطبيقات ورموز OAuth المميزة ونطاقات OAuth والشهادات وغيرها من الأساليب.
  • يضبط مقدّم خدمة واجهة برمجة التطبيقات الموارد المتاحة من خلال تحديد منتج واجهة برمجة التطبيقات. يتم منح إذن الوصول إما يدويًا في واجهة المستخدِم أو من خلال واجهة برمجة التطبيقات الإدارية أو من خلال بوابة مخصّصة للمطوّرين. عندما يتم منح مطوّر إذن الوصول إلى منتج API، يتلقّى معرّف عميل وسرًا يتم استخدامهما في عملية المصادقة.
  • يمكن أن تتكامل Apigee مع أي موفّر هوية لتنفيذ بروتوكول OAuth.
  • يمكن أن تنشئ Apigee رموز JWT المميزة أو تستخدم تقنيات أخرى لإرسال هوية المستخدم إلى الخدمات المستهدَفة. يمكن للخدمات المستهدَفة استخدام هذه الهوية لحظر الوصول إلى الخدمات والبيانات حسب الحاجة.

‫A6:2017-Security Misconfiguration

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

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

تضمن إصدارات منتجات Apigee الحماية من المكتبات التي تتضمّن ثغرات أمنية. قد تطرح Apigee تصحيحات أو تحديثات إضافية في حال العثور على ثغرات أمنية جديدة. يتم تصحيح السحابة الإلكترونية العامة على الأجهزة الطرفية تلقائيًا. على عملاء Edge for Private Cloud (في الموقع الجغرافي) تطبيق تصحيحات المنتج بأنفسهم.

A7:2017-Cross-Site Scripting (XSS)

تتيح البرمجة النصية عبر المواقع (XSS) للمهاجمين تنفيذ برامج نصية في متصفحات الويب الخاصة بالمستخدمين للتحكّم في جلسات المستخدمين أو التلاعب بالمواقع الإلكترونية أو التأثير بشكل ضار في المستخدمين بطرق أخرى. لا ترتبط مشاكل البرمجة النصية على مستوى الموقع الإلكتروني (XSS) بالضرورة بواجهات برمجة التطبيقات، ولكن توفّر Apigee سياسات حماية من التهديدات يمكن الاستفادة منها للحماية من البرمجة النصية على مستوى الموقع الإلكتروني (XSS) في واجهة برمجة التطبيقات.  باستخدام التعبيرات العادية، إما مع سياسة RegularExpressionProtection أو سياسة JavaScript، تحقَّق من حمولة البيانات وقيم المَعلمات بحثًا عن JavaScript وغيره من الهجمات التي تستخدم أسلوب الحقن.

‫CORS هو أحد الحلول الشائعة التنفيذ لسياسة المصدر نفسه التي تفرضها جميع المتصفحات، ويمكن تنفيذها باستخدام سياسة AssignMessage.

A8:2017 - Insecure Deserialization

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

لا تنصح Apigee بإجراء إلغاء التسلسل. ومع ذلك، يمكن أن تساعد سياسة JSONThreatProtection وسياسة RegularExpressionProtection في الحماية من حمولات JSON الضارة. يمكن أيضًا استخدام سياسة JavaScript لفحص الحِملات بحثًا عن محتوى ضار. يمكن استخدام ذاكرة التخزين المؤقت والسياسات الأخرى للحماية من هجمات إعادة الإرسال. على مستوى البنية التحتية، تتضمّن منصة Apigee أيضًا ضوابط مدمجة لحماية العمليات الجارية.

A9:2017 - استخدام المكوّنات التي تتضمّن ثغرات أمنية معروفة

بما أنّ الأُطر والمكتبات والوحدات تعمل مع إمكانية التنفيذ الكاملة والوصول إلى عمليات الإنشاء والقراءة والتعديل والحذف (CRUD)، يمكن للمهاجمين الاستفادة من الثغرات الأمنية في المكوّنات لمهاجمة الأنظمة.

تضمن إصدارات منتج Apigee المنتظمة الحماية من الثغرات الأمنية في المكوّنات، خاصةً عند اكتشاف ثغرات أمنية معيّنة. يتم تصحيح سحابة Apigee العامة تلقائيًا، وتُرسل Apigee إشعارات إلى عملاء Edge for Private Cloud عند توفّر حِزم تصحيح محلية للتثبيت.

A10:2017 - التسجيل والرصد غير الكافيين

عندما لا تنفّذ عمليات التسجيل والمراقبة وإدارة الحوادث بشكل كافٍ في أنظمتك، يمكن للمهاجمين تنفيذ هجمات أعمق وأطول على البيانات والبرامج.

تتوفّر في Apigee عدة طرق لتنفيذ التسجيل والمراقبة ومعالجة الأخطاء وتسجيل عمليات التدقيق.

التسجيل

  • يمكن إرسال رسائل السجلّ إلى Splunk أو أي نقطة نهاية أخرى لنظام syslog باستخدام سياسة MessageLogging.
  • يمكن سحب بيانات إحصاءات واجهة برمجة التطبيقات من خلال analytics API واستيرادها أو تصديرها إلى أنظمة أخرى.
  • في Edge for Private Cloud، يمكنك استخدام سياسة MessageLogging للكتابة إلى ملفات السجلّ المحلية. تتوفّر أيضًا ملفات السجلّ من كل المكوّنات التي يتم تشغيلها.
  • يمكن استخدام سياسة JavaScript لإرسال رسائل السجلّ إلى نقطة نهاية تسجيل REST بشكل متزامن أو غير متزامن.

المراقبة

  • استخدِم واجهة مستخدم مراقبة واجهات برمجة التطبيقات أو واجهة برمجة التطبيقات لمراقبة واجهات برمجة التطبيقات والخوادم الخلفية بانتظام وتفعيل التنبيهات.
  • استخدِم رصد السلامة لمراقبة الخلفيات المستهدَفة للخادم بانتظام.
  • تقدّم Apigee اقتراحات بشأن مراقبة Edge for Private Cloud.
  • توفّر Apigee أيضًا أفضل الممارسات التي يمكن لفريقك الاستفادة منها لرصد برنامج واجهة برمجة التطبيقات.

خطأ أثناء المعالجة

توفّر Apigee آلية قوية ومتعدّدة الاستخدامات للتعامل مع الأخطاء في خوادم وكيل واجهات برمجة التطبيقات. على غرار الطريقة التي يرصد بها برنامج Java الاستثناءات، يمكن لوكلاء واجهة برمجة التطبيقات رصد الأخطاء وتحديد كيفية عرض الردود المناسبة للعملاء. تتيح لك ميزة معالجة الأخطاء المخصّصة في Apigee إضافة وظائف، مثل تسجيل الرسائل، كلما حدث خطأ.

سجلات التدقيق

تحتفظ منصة Apigee بسجلّ تدقيق يتتبّع التغييرات التي يتم إجراؤها على خوادم وكيل API والمنتجات وسجلّ المؤسسة.  يتوفّر هذا السجلّ من خلال واجهة المستخدم أو من خلال Audits API.

حلول Apigee للثغرات الأمنية التي رصدتها OWASP في 2013

عندما عدّلت مؤسسة OWASP قائمتها لعام 2017، تم حذف بعض الثغرات الأمنية من قائمة 2013، إلا أنّها لا تزال تشكّل تهديدات صالحة. توضّح الأقسام التالية كيفية التعامل مع هذه التهديدات باستخدام Apigee.

‫A8:2013 - تزوير الطلبات من موقع إلكتروني مختلف (CSRF)

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

إرشادات:

  • هذه المشكلة مرتبطة بالمتصفّح أكثر من كونها مشكلة في منتج واجهة برمجة التطبيقات. يمكنك معالجة هذه الثغرة الأمنية باستخدام OpenID Connect وOAuth وتقنيات أخرى.
  • ننصحك باستخدام تقنيات HMAC أو الحالة أو التجزئة أو الرقم الخاص أو PKCE لمنع عمليات التزوير وهجمات إعادة الإرسال.

A10:2013 - عمليات إعادة التوجيه غير الصالحة

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

إرشادات:

  • استخدِم OAuth وافرض عملية التحقّق في كل طلب.
  • منع عمليات إعادة التوجيه غير المتوقّعة برمز الحالة 302 من خلال التحقّق من رموز الاستجابة في منطق وكيل واجهة برمجة التطبيقات والتعامل مع عمليات إعادة التوجيه بشكلٍ مناسب