تطبيقات الويب هي أهم موجهات يستخدمها المهاجمون لسحب الاختراقات. وفق "تقرير التحقيقات في خرق البيانات" من Verizon (PDF) ، كانت تطبيقات الويب هي السبيل لما يقرب من 70 ٪ من جميع الانتهاكات التي تمت دراستها.

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

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

خمسة دروس لتطبيقات أكثر أمانًا

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

1. لا يزال المهاجمون يستفيدون من البرمجة النصية عبر المواقع (XSS). لطالما كان XSS ثغرة أمنية شائعة في تطبيقات الويب. في عام 2021 ، خرجت من قائمة أفضل 10 مشروع أمان لتطبيقات الويب المفتوح (OWASP) بسبب التحسينات في أطر تطوير التطبيقات ، لكنها لا تزال واضحة في كل اختبار اختراق نقوم به تقريبًا.

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

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

   عادةً ما تكون الماسحات الضوئية غير محدثة مع تطوير الويب الحديث ولا تقدم أفضل النتائج لتطبيقات JavaScript أحادية الصفحة أو WebAssembly أو Graph. تحتاج الثغرات المعقدة إلى حمولة يدوية للتحقق من صحتها ، مما يجعل الأدوات الآلية أقل فعالية.

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

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

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

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

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

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

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

5. لا يوجد "خارج النطاق" في اختبار اختراق جيد. يمكن أن تصبح تطبيقات الويب معقدة بسرعة بناءً على عدد الموارد والأصول التي تدخل فيها. يجب مراعاة خوادم API الخلفية التي تمكّن وظائف التطبيق الرئيسي.

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

مسألة التوازن

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