واجهة برمجة التطبيقات (API) هي طريقة تسمح للتطبيقات بالتواصل مع بعضها البعض. يوفر طريقة للمطورين لإنشاء تطبيقات برمجية مع تمكين استخراج البيانات ومشاركتها بطريقة يسهل الوصول إليها.
يمكن استخدام واجهات برمجة التطبيقات لتسهيل الهجمات الإلكترونية حيث يتم استخدام واجهات برمجة التطبيقات على نطاق واسع لتحويل المعلومات التي قد تكون حساسة. نقاط الضعف مثل المصادقة الضعيفة ، ونقص التشفير ، والعيوب المنطقية ، ونقاط النهاية غير الآمنة تجعل واجهات برمجة التطبيقات عرضة للهجمات.
بعض الهجمات الرئيسية التي تحدث عادةً بسبب نقص التدابير الأمنية أثناء تنفيذ واجهات برمجة التطبيقات هي:
رجل في الوسط (MITM)
من أجل الحصول على معلومات حساسة ، يقوم دخيل باعتراض حركة المرور بين الأطراف المتصلة عن طريق ترحيل واعتراض الاتصال الذي يتضمن تبادلات API.
حقن API (XSS و SQLi)
في هجوم حقن التعليمات البرمجية ، يتم إدخال رمز ضار في برنامج برمجي ضعيف لشن هجوم مثل البرمجة النصية عبر المواقع (XSS) وحقن SQL (SQLi).
يمكن للجاني إدخال نص برمجي ضار في واجهة برمجة تطبيقات ضعيفة ، أي الذي يفشل في تنفيذ إدخال مرشح مناسب وإخراج الهروب (FIEO) لإطلاق هجوم XSS يستهدف متصفحات المستخدمين النهائيين. بالإضافة إلى ذلك ، يتم إدراج التعليمات البرمجية الضارة في رسالة API ، على سبيل المثال ، الأوامر التي تحذف الكائنات ، والسجلات من قاعدة البيانات.
رفض الخدمة الموزع (DDoS)
في هجوم رفض الخدمة الموزع (DDoS) ، تغمر أنظمة متعددة النطاق الترددي للنظام المستهدف ، وعادةً ما تكون خوادم الويب. يحاول هجوم DDoS على واجهة برمجة التطبيقات إرهاق ذاكرتها وسعتها من خلال إغراقها بالاتصالات المتزامنة ، أو بإرسال / طلب كميات كبيرة من المعلومات في كل طلب. استخدم هجوم DDoS على موقع FCC الإلكتروني في أوائل عام 2017 خدمات السحابة التجارية لإصدار كمية هائلة من طلبات واجهة برمجة التطبيقات لنظام التعليق. استهلك هذا موارد الماكينة المتاحة وزاحم المعلقين البشريين ، مما أدى في النهاية إلى تعطل موقع الويب.
اختطاف DNS
يعد اختطاف خادم اسم المجال (DNS) المعروف أيضًا باسم إعادة توجيه DNS نوعًا من الهجمات يتم فيه إعادة توجيه استعلامات DNS بشكل غير متوقع إلى مواقع ضارة.
أحد الأمثلة على اختطاف DNS هو عندما تكون على الإنترنت وموقع ويب تريد الوصول إليه يعيد توجيهك إلى موقع ضار مليء بالنوافذ المنبثقة والإعلانات غير المرغوب فيها. الدافع الأساسي وراء ذلك هو توليد الدخل.
يمكن أيضًا استخدام اختطاف DNS للتصيد الاحتيالي. في التصيد الاحتيالي ، يتم استهداف الضحايا ويحاول المهاجمون خداعهم للكشف عن معلومات حساسة مثل بيانات اعتماد الدفع الخاصة بهم. السيناريو الأكثر شيوعًا الذي نراه في التصيد الاحتيالي هو إرسال بريد إلكتروني كطعم يوجه المستخدمين إلى موقع ويب يبدو أنه موقع معالجة دفع شرعي ومن هناك يسرق معلوماتهم.
كيف نقوم في Quick Heal بتأمين واجهات برمجة التطبيقات الخاصة بنا
HTTPS عبر HTTP
أمان طبقة النقل (TLS) هو معيار يحافظ على خصوصية اتصال الإنترنت ويتحقق من أن البيانات المرسلة بين نظامين مشفرة وغير معدلة. يُقال إن موقع الويب محمي بواسطة TLS إذا كان عنوان URL يبدأ بـ “HTTPS” (بروتوكول نقل النص التشعبي الآمن).
TLS في التفاعل القائم على API أمر ضروري. يعد تشفير طبقة النقل أحد “الأشياء الضرورية” لتأمين واجهات برمجة التطبيقات. إذا لم يكن هناك TLS ، فإن خطر هجمات “Man-In-The-Middle” يظل مرتفعًا للغاية. نحن نستخدم كلاً من TLS في واجهات برمجة التطبيقات الخاصة بنا ، خاصةً عند طرحها للعامة باستخدام واجهات برمجة التطبيقات. نحن نستخدم HTTPS بشكل صارم عبر HTTP.
المصادقة
لتحديد هوية المستخدم النهائي (المتصل) في API ، يمكن تنفيذ المصادقة الأساسية باستخدام بروتوكول TLS. ومع ذلك ، فإن OAuth 2 و OpenID Connect بدائل أكثر أمانًا.
لا تكشف معلومات عن عناوين المواقع
لا تكشف أبدًا عن أي معلومات حساسة أو ضعيفة في عناوين URL
التحقق من صحة معلمة الإدخال
تحقق من صحة معلمات الطلب في الخطوة الأولى ، قبل أن تصل إلى منطق عمل معالجة الخدمة الفعلي. نجري عمليات تحقق قوية من الصحة ونرفض الطلب فورًا في حالة فشل التحقق.
التشفير
يوصى بشدة باستخدام تشفير قوي للمعلومات الحساسة والخاصة أثناء التحويل عبر واجهات برمجة التطبيقات. نستخدم خوارزمية تشفير قوية وخفيفة الوزن – AES256
AES 256
معيار التشفير المتقدم (AES) هو التشفير الأول والوحيد الذي يمكن الوصول إليه للجمهور والمعتمد من قبل وكالة الأمن القومي الأمريكية (NSA) لحماية المعلومات السرية للغاية.
حتى الآن ، تم الإبلاغ عن عدد قليل جدًا من الهجمات ضد تطبيق 256 AES. كانت معظمها هجمات على القنوات الجانبية (تم تنفيذ الهجوم على تطبيق التشفير على النظام وليس على التشفير الأساسي نفسه). يُعتقد أن تصميم وقوة طول المفتاح يحميان خوارزمية AES وطول مفتاح 256 بت مثالي للمعلومات السرية للغاية. عندما يتعلق الأمر بأمن البيانات ، لا أحد يريد التنازل ، و AES-256 هي واحدة من أكثر الطرق أمانًا لتشفير البيانات المتوفرة في السوق اليوم.
خوارزميات تبادل المفاتيح
استخدم خوارزميات تبادل المفاتيح القوية لتبادل مفاتيح المصادقة أو التشفير. يجب اعتماد هذا على الأسرار الثابتة أو الثابتة.
للتبادل السري للمفاتيح ، نستخدم أقوى طريقة لتبادل المفاتيح العامة والتي تسمى تبادل المفاتيح الآمن Diffie Hellman.
تبادل المفاتيح الآمن Diffie Hellman:
تبادل مفاتيح Diffie-Hellman معقد. تستخدم أعدادًا كبيرة جدًا والكثير من الرياضيات. يعتمد تبادل مفاتيح Diffie-Hellman على وظائف أحادية الاتجاه كأساس لأمنه. هذه الحسابات بسيطة وذات اتجاه واحد ، ولكن من الصعب جدًا حسابها بطريقة عكسية.
بعض مزايا Diffie-Hellman:
- لا يحتاج المرسل والمتلقي إلى أي معرفة مسبقة ببعضهما البعض
- بمجرد تبادل المفاتيح ، يمكن توصيل البيانات عبر قناة غير آمنة بشكل آمن
- مشاركة المفتاح السري آمنة
المصادقة القائمة على الرمز المميز
تتمثل ميزة المصادقة القائمة على الرمز المميز في أنها تزيل فرص ضعف بيانات اعتماد تسجيل الدخول. الرمز المميز عبارة عن جزء مؤمن للغاية من البيانات يستخدم لنقل المعلومات الحساسة بين طرفين بطريقة مضغوطة ومستقلة. غالبًا ما يتم استخدام الرموز لتعزيز عمليات المصادقة ، سواء كان ذلك داخل موقع ويب أو تطبيق.
نحن نستخدم الاتصالات القائمة على JWT Token والتي تتكون من:
- رأس يحدد نوع الرمز المميز والخوارزمية المستخدمة
- حمولة تحتوي على معلومات حول المستخدم والبيانات الوصفية الأخرى
- توقيع يتحقق من هوية المرسل وصحة الرسالة
عناوين URL
لا تكشف عناوين URL أي معلومات حساسة لأننا نتجنب استخدام معامِلات طلب البحث ولا يتم الكشف عن أي معلومات عبر عناوين URL.
التحقق من صحة معلمة الإدخال
لدينا تحقق قوي من معلمات الإدخال في المرحلة الأولية للغاية قبل تنفيذ منطق الأعمال ونرفض جميع الطلبات غير الصالحة المحتملة.
الأمان مقابل الأداء
الأداء ميزة والأمان عنصر أساسي في الوقت الحاضر ، لذلك من المهم جدًا تحقيق كليهما دون المساس بالآخر. لتلبية متطلبات الأمان هذه دون المساس بالأداء ، يمكن للمرء اختيار إستراتيجية تنفيذ خفيفة الوزن مع إجراءات أمان عالية.
كاتب مُشارك: Prafulla Prakash Ranadive
