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

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

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

نظرة عامة

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

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

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

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

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

تتيح لك منصة إدارة واجهات برمجة التطبيقات الذكية من Apigee معالجة أهم نقاط ضعف أمان واجهات برمجة التطبيقات في OWASP بسلاسة أثناء اتّباع نهج يركز على الاستخدام لتصميم واجهات برمجة التطبيقات وربطها بأنظمة الخلفية. في ما يلي قائمة بالسياسات/الإعدادات التي تنصح بها 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 سياسات 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
  • فك رموز DecodeJWT بدون التحقّق منها

A3:2017 - Sensitive Data Exposure

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

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

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

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

تتيح Apigee العديد من خيارات ضبط بروتوكول TLS.

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

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

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

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

A4:2017 - عناصر XML الخارجية

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

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

تتضمّن Apigee أداة تحليل XML مدمجة كجزء من المنصة التي تستخدم XPath لاستخراج البيانات. تشمل هذه الخدمة أيضًا سياسة XMLThreatProtection للحماية من حِزم XML الضارة.

A5:2017 - وظائف التحكم في الوصول لا تعمل على النحو المطلوب

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

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

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

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

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

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

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

A6:2017-Security Misconfiguration

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

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

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

A7:2017-Cross-Site Scripting (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 أخرى باستخدام سياسة تسجيل الرسائل.
  • يمكن سحب بيانات الإحصاءات من خلال analytics API واستيرادها أو تصديرها إلى أنظمة أخرى.
  • في Edge for Private Cloud، يمكنك استخدام سياسة تسجيل الرسائل لكتابة البيانات في ملفات السجلّات المحلية. تتوفّر أيضًا ملفات السجلّ من كل مكوّن قيد التشغيل.
  • يمكن استخدام سياسة JavaScript لإرسال رسائل السجلّ إلى نقطة نهاية تسجيل REST بشكل متزامن أو غير متزامن.

المراقبة

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

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

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

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

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

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

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

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

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

إرشادات:

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

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

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

إرشادات:

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