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

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستند Apigee X. المعلومات

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

نظرة عامة

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

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

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

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

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

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

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

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

A1:2017 - الحقن

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

هناك عدة طرق للتحقّق من صحة المدخلات باستخدام منصة Apigee:

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

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

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

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

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

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

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

في سياسة CheckAPIKey، يتم إثبات ملكية معرّف العميل أو "مفتاح المستهلك" فقط. يحصل المطوّرون على مفتاح المستهلك عندما يسجِّلون تطبيقاتهم في 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 باستخدام ثلاث سياسات.

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

A3:2017 - التعرض للبيانات الحساسة

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

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

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

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

يتوافق Apigee مع العديد من خيارات ضبط بروتوكول أمان طبقة النقل (TLS).

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

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

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

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

A4:2017 - الكيانات الخارجية بتنسيق XML

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

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

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

A5:2017 - التحكم في الوصول معطّل

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

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

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

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

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

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

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

A6:2017-الضبط الخاطئ للأمان

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

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

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

A7:2017 - هجوم البرمجة عبر المواقع (XSS)

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

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

A8:2017 - إزالة العنوان غير الآمن

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

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

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

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

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

A10:2017 - التسجيل والمراقبة غير كافٍ

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

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

التسجيل

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

المراقبة

  • استخدِم واجهة المستخدم أو واجهة برمجة التطبيقات API Monitoring لمراقبة واجهات برمجة التطبيقات والخلفيات بانتظام وتشغيل الأدوات الذكية.
  • استخدِم مراقبة السلامة لمراقبة الخلفيات الخلفية للخادم المستهدف بانتظام.
  • تقدّم Apigee اقتراحات لمراقبة Edge في السحابة الإلكترونية الخاصة.
  • تقدّم Apigee أيضًا أفضل الممارسات التي يمكن لفريقك الاستفادة منها لمراقبة برنامج واجهة برمجة التطبيقات.

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

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

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

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

حلول Apigee لثغرات OWASP لعام 2013

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

A8:2013 - تزوير الطلبات على مواقع مختلفة (CSRF)

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

إرشادات:

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

A10:2013 - عمليات إعادة التوجيه التي لم يتم التحقق منها

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

إرشادات:

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