أمان واجهة برمجة تطبيقات الويب

الموسوعة الحرة

يتضمن أمان واجهة برمجة تطبيقات الويب التحقق من مصادقة البرامج أو المستخدمين الذين يستدعون واجهة برمجة تطبيقات الويب .

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

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

طريقة المصادقة والتفويض

تشمل أكثر طرق المصادقة والتفويض شيوعًا ما يلي:

  1. السلاسل الثابتة: هذه تشبه كلمات المرور التي توفرها واجهات برمجة التطبيقات للمستهلكين.
  2. الرموز الديناميكية: هي رموز تعتمد على الوقت يحصل عليها المتصل من خدمة المصادقة.
  3. الرموز المفوضة من قبل المستخدم: هذه رموز مثل OAuth [ 2 ] التي يتم منحها بناءً على مصادقة المستخدم.
  4. التحكم في الوصول القائم على السياسات والسمات : تستخدم السياسات السمات لتحديد كيفية استدعاء واجهات برمجة التطبيقات باستخدام معايير مثل ALFA أو XACML .

توفر الطرق المذكورة أعلاه مستويات مختلفة من الأمان وسهولة التكامل. في كثير من الأحيان، توفر أسهل طريقة للتكامل أضعف نموذج أمان.

الأوتار الثابتة

مخطط كتلة المصادقة الأساسية

في طريقة السلاسل الثابتة، يُضمّن مُستدعي واجهة برمجة التطبيقات أو العميل سلسلة نصية كرمز مميز في الطلب. تُعرف هذه الطريقة غالبًا باسم المصادقة الأساسية. [ 3 ] "من وجهة نظر أمنية، لا تُعدّ المصادقة الأساسية مُرضية تمامًا. فهي تعني إرسال كلمة مرور المستخدم عبر الشبكة كنص عادي لكل صفحة يتم الوصول إليها (إلا إذا تم استخدام بروتوكول آمن منخفض المستوى، مثل SSL ، لتشفير جميع المعاملات). وبالتالي، يكون المستخدم عُرضة بشدة لأي برامج تجسس على حزم البيانات على الشبكة." [ 4 ]

الرموز الديناميكية

عندما تكون واجهة برمجة التطبيقات محمية برمز مميز ديناميكي، يتم إدراج قيمة عشوائية ( nonce) مرتبطة بالوقت في الرمز المميز. يحتوي الرمز المميز على مدة صلاحية (TTL) يجب على العميل بعدها الحصول على رمز مميز جديد. تعتمد واجهة برمجة التطبيقات على خوارزمية للتحقق من الوقت ، وإذا انتهت صلاحية الرمز المميز، يُمنع الطلب. مثال على هذا النوع من الرموز هو رمز JSON Web Token (JWT ). تحدد خاصية "exp" (مدة الصلاحية) وقت انتهاء الصلاحية الذي لا يجوز بعده قبول رمز JWT للمعالجة. [ 5 ]

رمز مفوض من المستخدم

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

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

نظام تفويض دقيق لواجهات برمجة التطبيقات

التحكم في الوصول القائم على السمات

في هذا النهج، توجد نقطة لتطبيق السياسات إما داخل واجهة برمجة التطبيقات نفسها، أو في إطار عمل واجهة برمجة التطبيقات (كمُعترض أو مُعالج رسائل)، أو كبوابة لواجهة برمجة التطبيقات (مثل WSO2 أو Kong أو Tyk أو ما شابهها ) تعترض استدعاء واجهة برمجة التطبيقات و/أو الاستجابة الواردة منها. تُحوّل هذه النقطة الاستجابة إلى طلب تفويض (عادةً بلغة XACML) تُرسله إلى نقطة اتخاذ قرار السياسات (PDP). تُهيأ نقطة اتخاذ قرار السياسات بسياسات تُطبّق تحكمًا ديناميكيًا في الوصول، يُمكنها استخدام أي عدد من سمات المستخدم، والمورد، والإجراء، والسياق لتحديد الوصول المسموح به أو المرفوض. يُمكن أن تتناول السياسات ما يلي:

  1. المورد (مثل حساب مصرفي)
  2. المستخدم (على سبيل المثال، العميل)
  3. السياق (مثل وقت اليوم)
  4. علاقة (مثل العميل الذي ينتمي إليه الحساب).

يتم التعبير عن السياسات باستخدام لغة ALFA أو XACML.

مراجع

  1. ↑ "هجمات واجهة برمجة التطبيقات" (ملف PDF) .
  2. ↑ "OAuth 2.0 — OAuth" . oauth.net . تم الاطلاع عليه بتاريخ 10-10-2015 .
  3. ↑ "بروتوكول نقل النص التشعبي - HTTP/1.0: مخطط المصادقة الأساسي" . w3.org . تم الاطلاع عليه بتاريخ 2026-07-08 .
  4. ↑ "دليل بدائل المصادقة عبر الويب: الجزء الثاني" . unixpapa.com . تم الاطلاع عليه بتاريخ 10-10-2015 .
  5. ↑ جون، برادلي؛ نات، ساكيمورا؛ مايكل، جونز. "رمز الويب JSON (JWT)" . tools.ietf.org . تم الاطلاع عليه بتاريخ 10-10-2015 .
  6. ↑ هاردت، ديك. "إطار عمل OAuth 2.0 للتفويض" . tools.ietf.org . تم الاطلاع عليه بتاريخ 11-10-2015 .