أفضل الممارسات لبناء واجهات برمجة التطبيقات الآمنة

بقلم راكيش تالانكي وفيدهير غاديكوتا

يفهم مصممو واجهة برمجة التطبيقات (واجهة برمجة التطبيقات) ومطوروها عمومًا أهمية الالتزام بمبادئ التصميم أثناء تنفيذ الواجهة. لا أحد يريد تصميم أو تنفيذ واجهة برمجة تطبيقات سيئة!

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

يجب أن يتذكر المطورون ارتداء قبعة الهاكر API قبل النشر. إذا أهمل أحد المطورين تحديد نقاط الضعف في واجهة برمجة التطبيقات ، فقد تصبح واجهة برمجة التطبيقات عبارة عن بوابة مفتوحة للنشاط الضار.

تحديد وحل نقاط الضعف API

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

الحقن

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

في أكتوبر 2014 ، على سبيل المثال ، أعلنت دروبال عن ثغرة أمنية في حقن SQL تمنح المهاجمين إمكانية الوصول إلى قواعد البيانات ، والكود ، ودلائل الملفات. كان الهجوم شديدًا لدرجة أن المهاجمين ربما قاموا بنسخ جميع البيانات من مواقع العملاء. هناك العديد من أنواع تهديدات الحقن ، ولكن الأكثر شيوعًا هي SQL Injection و RegEx Injection و XML Injection. لقد رأينا أكثر من مرة واجهات برمجة التطبيقات تعمل بدون حماية من التهديدات - إنها ليست غير شائعة.

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

تمثل واجهة برمجة التطبيقات التي تم إنشاؤها دون حماية من التهديدات الضارة من خلال المصادقة فشلًا في تصميم واجهة برمجة التطبيقات التي يمكن أن تهدد قواعد بيانات المؤسسة. تجاهل المصادقة الصحيحة - حتى لو تم استخدام تشفير طبقة النقل (TLS) - يمكن أن يسبب مشاكل. مع وجود رقم جوال صالح في طلب API ، على سبيل المثال ، يمكن لأي شخص الحصول على عناوين البريد الإلكتروني الشخصية وبيانات تعريف الجهاز. آليات المصادقة والتخويل القوية القياسية الصناعية مثل OAuth / OpenID Connect ، بالاقتران مع TLS ، تعتبر ضرورية.

البيانات الحساسة في العراء

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

مع تزايد المخاوف بشأن أمن API ، يجب أن يكون تشفير البيانات الحساسة والسرية أولوية قصوى. على سبيل المثال ، في يونيو 2016 ، تم الكشف عن مشكلة عدم حصانة الوكيل http والتي وفرت طرقًا متعددة للمهاجمين لإرسال الطلب الصادر إلى خادم اختيار والتقاط معلومات حساسة من الطلب واكتساب معلومات حول البيانات الداخلية. بالإضافة إلى استخدام TLS ، من المهم أن تتم حماية حركة مرور واجهة برمجة التطبيقات من خلال تشفير البيانات الحساسة وتنفيذ قناع البيانات للتتبع / التسجيل واستخدام الرمز المميز لمعلومات البطاقة.

هجمات الإعادة

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

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

تشمل الإجراءات المضادة سياسات الحد من الأسعار لتخفيض الطلبات ، واستخدام أدوات معقدة مثل Apigee Sense لتحليل حركة مرور طلبات واجهة برمجة التطبيقات ، وتحديد الأنماط التي تمثل طلبات الروبوت غير المرغوب فيها. تشمل التدابير الأمنية الإضافية لمنع هجمات الإعادة ما يلي:

  • HMAC ، الذي يدمج الطوابع الزمنية للحد من صلاحية الصفقة لفترة زمنية محددة
  • توثيق ذو عاملين
  • تمكين رمز وصول قصير الأجل باستخدام OAuth

طفرات غير متوقعة في استخدام واجهة برمجة التطبيقات

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

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

المفاتيح في URI

بالنسبة لبعض حالات الاستخدام ، يعد تنفيذ مفاتيح واجهة برمجة التطبيقات للمصادقة والترخيص جيدًا بدرجة كافية. ومع ذلك ، يمكن أن يؤدي إرسال المفتاح كجزء من معرف الموارد الموحد (URI) إلى اختراق المفتاح. كما هو موضح في IETF RFC 6819 ، نظرًا لأن تفاصيل URI يمكن أن تظهر في سجلات المتصفح أو النظام ، فقد يتمكن مستخدم آخر من عرض URIs من محفوظات المستعرض ، مما يجعل مفاتيح API وكلمات المرور والتاريخ الحساس في API URIs يمكن الوصول إليها بسهولة.

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

تتبع المكدس

أصبح العديد من مطوري واجهة برمجة التطبيقات يشعرون بالراحة عند استخدام 200 لكل طلبات النجاح ، و 404 لكل حالات الفشل ، و 500 بالنسبة لبعض أخطاء الخادم الداخلية ، وفي بعض الحالات القصوى ، 200 مع وجود رسالة فشل في النص ، بالإضافة إلى تتبع مكدس مفصل. يمكن أن يصبح تتبع المكدس تسربًا للمعلومات إلى مستخدم ضار عندما يكشف عن التصميم الأساسي أو تطبيقات الهندسة المعمارية في شكل أسماء الحزم وأسماء الفصول وأسماء إطار العمل والإصدارات وأسماء الخوادم واستعلامات SQL.

يمكن للمهاجمين استغلال هذه المعلومات عن طريق إرسال طلبات عناوين URL ، كما هو موضح في مثال سيسكو هذا. من الممارسات الجيدة إرجاع كائن خطأ "متوازن" ، مع رمز حالة HTTP الصحيح ، مع الحد الأدنى المطلوب من رسائل (رسائل) الخطأ و "عدم تتبع المكدس" أثناء ظروف الخطأ. سيؤدي ذلك إلى تحسين معالجة الأخطاء وحماية تفاصيل تنفيذ واجهة برمجة التطبيقات من المهاجمين. يمكن استخدام بوابة واجهة برمجة التطبيقات لتحويل رسائل الخطأ الخلفية إلى رسائل موحدة بحيث تبدو جميع رسائل الخطأ مماثلة ؛ هذا أيضا يلغي تعريض بنية رمز الواجهة الخلفية.

الحفاظ على واجهات برمجة التطبيقات آمنة

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

[هل ترغب في معرفة المزيد حول أمان واجهة برمجة التطبيقات؟ احصل على نسختك من كتابنا الإلكتروني الأخير ، داخل عقلية Product API: إنشاء وإدارة واجهات برمجة التطبيقات الآمنة.]