هذه هي المادة الأولى من سلسلة من المقالات حول مشروع OWASP Top 10 ، وهو مشروع بدأ كفكرة للهواة وأصبح المصدر الأكثر موثوقية لتصنيف ناقلات الهجوم ونقاط الضعف في تطبيقات الويب.
في هذه المقالة ، سنحلل بإيجاز جميع الثغرات الرئيسية من قائمة OWASP Top 10 ، ونرى أيضًا سبب أهمية معرفة نقاط الضعف النموذجية من أجل تطوير تطبيقات آمنة.
منذ حوالي 10 سنوات ، صاغ شخص شديد الانتباه شعارًا جديدًا - HTTP هو TCP جديد. بالطبع ، ليس بمعنى أن الشخص قرر وضع HTTP على مستوى النقل. مستحيل! إنه فقط بالنسبة للاتصالات الحديثة ، فإن بروتوكول HTTP يؤدي نفس وظيفة بروتوكول TCP على مستواه - الغالبية العظمى من التطبيقات الحديثة ، بما في ذلك التطبيقات المحمولة ، تستخدم HTTP كوسيلة نقل. ومع ظهور HTTP 2.0 ، فإن هذا الوضع قد أصبح برونزيًا وفي المستقبل القريب ، على ما يبدو لن يتغير. أصبح البروتوكول المعيار القياسي لتقديم المحتوى ، ولم يعد من الممكن رؤية HTTP كبروتوكول ويب.
قد يبدو أن HTTP كان موجودًا دائمًا ، وهذا صحيح تقريبًا عندما تفكر في أن المواصفات الرسمية الأولى في RFC ظهرت في عام 1997 ، على الرغم من أن البروتوكول نفسه بدأ استخدامه في وقت أبكر بكثير.
استغرق الأمر بعض الوقت لفهم أنه بمجرد أن يصبح البروتوكول شائعًا ، سيبدأ الجميع في استخدامه لتقديم المحتوى ، غالبًا بدون مؤهلات مناسبة. وستكون النتيجة مئات الآلاف من الأنظمة الضعيفة حول العالم وآفاق غامضة لتصحيح الوضع.
في حالة قرارات بائعين محددين ، يمكنك دائمًا الرجوع إلى مواده أو السؤال مباشرة: "ما هي أفضل طريقة للتصرف؟" - والحصول على إجابة مؤهلة ، لأنه في النهاية يكون البائع وحده هو المسؤول عن منتجه. عندما يتعلق الأمر باستخدام معايير وأدوات مفتوحة لبناء التطبيقات ، هناك حاجة إلى مصدر غير متحيز للمعلومات حول أفضل الممارسات. يمكن أن يكون مثل هذا المصدر متحمسًا ، أو ربما مجتمعًا كاملًا من المحترفين في هذا المجال.
دبور يطير
في مجال أمن تطبيقات الويب ، أصبح OWASP (مشروع أمان تطبيق الويب المفتوح) مثل هذا المجتمع. بالطبع ، OWASP هي منظمة غير ربحية غير تابعة لأي شركة تكنولوجيا. تتيح لك هذه الحالة تقديم معلومات عملية محايدة حول تقنيات حماية تطبيقات الويب للمؤسسات والمؤسسات التعليمية والخدمات الحكومية وحتى الأفراد المهتمين بهذه المشكلة.
إذن ما الذي تفعله OWASP بالضبط؟ ضمن اختصاصها ، لدى OWASP مهمتان رئيسيتان: إنتاج الوثائق وتوفير الأدوات ، مجانًا تمامًا.
في هذه السلسلة من المقالات ، سنقوم بتحليل ، ربما ، المواد الأكثر شعبية مشروع OWASP TOP 10. هذه وثيقة تسرد أهم وأخطر المخاطر لتطبيقات الويب. يستند قرار إدراج الثغرات الأمنية في هذه القائمة إلى رأي خبراء خبراء أمن المعلومات من جميع أنحاء العالم (حيث لا يوجد ذلك) ، وعلى العموم ، فإن فهم هذه الثغرات هو الخطوة الأولى لتغيير ثقافة تطوير البرمجيات.
يجب أن تفهم بوضوح أنه ، كقاعدة عامة ، لا تستند جميع نقاط الضعف هذه على أخطاء مبرمجين محددين أو نقاط ضعف البروتوكولات نفسها ، ولكن على المشاكل المعمارية لتصميم البرمجيات. وبالنسبة للمبتدئين ، فإن هذه القائمة ضرورية للغاية للدراسة!
عشر نوبات قاتلة
يتم تحديث قائمة الثغرات باستمرار ، وبالنسبة لعام 2017 على النحو التالي:
• A1: 2017 - الحقن ، المعروفة أيضًا باسم "حقن الكود"
نحن نتحدث عن جميع أنواع الحقن: SQL ، NoSQL ، LDAP - أي شيء. يصبح إدخال الرمز ممكنًا عندما يتم إرسال بيانات لم يتم التحقق منها إلى المترجم كجزء من أمر أو طلب. يتم تنفيذ مثل هذا الطلب "الخبيث" بأمان ويلحق الضرر به. في 90٪ من الحالات ، عندما تسمع أنه تم الوصول إلى قاعدة بيانات خاصة عبر الويب ، فهذا مجرد A1.
• A2: 2017 - مصادقة غير صحيحة
غالبًا ما يتم استخدام وظائف التطبيق المسؤولة عن المصادقة وإدارة الجلسة بشكل غير صحيح ، مما يستلزم اختراق كلمات المرور والمفاتيح ورموز الجلسة وحتى القدرة على اعتراض جلسة المستخدم تمامًا. عندما تجلس في شبكة wifi عامة وتكتشف فجأة أن بعض الإجراءات يتم تنفيذها نيابة عنك على موارد الويب العامة - هذا هو A2.
• A3: 2017 - إفشاء معلومات حساسة
قد تقوم العديد من تطبيقات الويب وواجهات برمجة التطبيقات (API) بتخزين المعلومات الحساسة ومعالجتها بشكل غير صحيح ، مثل البيانات الشخصية. يمكن للمهاجمين سرقة أو تغيير هذه المعلومات ، والتي يمكن أن تصبح الأساس لخسائر مالية أو خسائر سمعة خطيرة. يجب تخزين المعلومات الحساسة بشكل صحيح وحمايتها أيضًا أثناء الإرسال عبر قنوات الاتصال.
• A4: 2017 - تنفيذ كيانات XML الخارجية (XXE)
يمكن للعديد من معالجات XML القديمة أو التي تم تكوينها بشكل ملتوي استخدام البيانات الخارجية من الروابط الموجودة في ملفات XML. قد تحتوي هذه البيانات الخارجية على تعليمات برمجية ضارة تسمح لك بتنفيذ أي تعليمات برمجية غريبة على الجهاز المستهدف تقريبًا.
• A5: 2017 - مراقبة الدخول المخالفة
يمكن تجربة مصفوفة الوصول ، التي كانت جيدة جدًا على الورق ، بشكل غير صحيح لنظام معين ، بحيث يمكن للمستخدمين غير الشرعيين الوصول بسهولة إلى المناطق المغلقة من المواقع أو الحصول على فرصة لتغيير حقوق الموارد حسب تقديرهم.
• A6: التكوين الخاطئ للأمان 2017 - أخطاء في التكوين
نتحدث هنا عن بعض الأشياء العالمية الأخرى ، مثل عدم وجود تحديثات في الوقت المناسب للخادم وبرامج التطبيقات ، ووجود معلومات مهمة في رسائل الخطأ أو حتى في رؤوس HTTP. قد يكون التطبيق مثاليًا تقريبًا ، ولكن إذا كان خادم الويب الذي يعمل عليه يعاني من مشكلات في التكوين الأساسي ، فإن كل شيء عديم الفائدة.
• A7: 2017 - البرمجة النصية المتقاطعة (XSS)
يحدث XSS عندما يتضمن التطبيق بيانات غير موثوق بها دون التحقق المناسب. على سبيل المثال ، قد يحتوي رمز برنامج إعلان بانر على نص برمجي لاعتراض بيانات المستخدم ، أو وجه الموقع ، أو حتى إعادة التوجيه بشفافية إلى مواقع أخرى.
• A8: 2017 - إلغاء التسلسل غير الآمن
يؤدي إلغاء التسلسل غير الآمن عادةً إلى تنفيذ التعليمات البرمجية عن بُعد. خلاصة القول هي أن البيانات غير الموثوق بها يمكن أن تدمر منطق التطبيق الخاص بك بمجرد أن يتم إلغاء تسلسله. ومع ذلك ، فإن نقطة ضعف غريبة للوهلة الأولى تأخذ مكانها في القائمة.
• A9: 2017 - استخدام المكونات ذات الثغرات المعروفة
يجب تحديث المكتبات والأطر وأنظمة التشغيل والمكونات الأخرى لنظم المعلومات في الوقت المناسب. خلاف ذلك ، يمكن أن تؤثر ثغرة أمنية معروفة في مكتبة واحدة على خدمة كبيرة تستخدم حتى وظيفة واحدة من مكتبة ضعيفة.
• A10: 2017 - تسجيل ومراقبة غير كافية
كل شيء بسيط هنا - لقد قمت ببناء نظام رائع ، ولكنك نسيت ربط أدوات المراقبة. لا يتعلق الأمر حتى بنظام SIEM متصل ، ولكن ببساطة حول التسجيل العادي لأحداث الخادم الرئيسية. لسوء الحظ ، ليس من غير المألوف عند ملاحظة أنظمة القرصنة بعد ستة أشهر من القرصنة نفسها ، ويتعلمون عن ذلك ليس من السجلات ، ولكن من المراقبين الخارجيين.
في المقالات التالية ، سنبدأ في تحليل كل من نقاط الضعف هذه بمزيد من التفصيل. سنسلح أنفسنا بالأدوات اللازمة ونرى كيف يتم تنفيذ هذه الثغرات في الممارسة العملية.
من إعداد
سيرجي بولونين .