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

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

1) الحقن

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

2) المصادقة المعطلة وإدارة الجلسات

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

3) البرمجة النصية عبر المواقع XSS

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

4) مراجع الكائنات المباشرة غير الآمنة

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

5) سوء التهيئة الأمنية

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

6) التعرض للبيانات الحساسة

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

7) التحكم في الوصول على مستوى الوظيفة المفقودة

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

8) تزوير الطلبات عبر المواقع

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

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

9) استخدام المكونات المعروفة بضعفها

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

10) التوجيهات والإحالات غير المصدق عليها

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

تعليق أو اتصل بنا في حالة وجود أي استفسار.

AR
دردشة واتساب
حالة حماية DMCA.com