الثغرات الأمنية -ببساطة- هي نقطة ضعف موجودة في النظام يستطيع المهاجم استغلالها.

وفي ضوء هذا التهديد الدائم؛ لا بدَّ للمنظَّمات ومبرمجي المواقع والمستخدمين من اتِّباع نهج وطرائق مختلفة للحماية، وسدِّ الثغرات لمنع المهاجمين من تدمير أنظمتهم وسرقة معلوماتهم.

المشروع المفتوح لأمن تطبيقات الويب (OWASP): وهو مجتمع مفتوح، مختصّ لتمكين المنظمات من تطوير التطبيقات وشرائها على نحو يمكن الوثوق به، ويمكن الحصول مجانًا -ضمن هذا المشروع- على ما يأتي: أدوات أمن التطبيقات ومعاييره، وكتب متكاملة في اختبار أمن التطبيقات، والتطوير الآمن للنصوص البرمجية، إضافة إلى أبحاث متطوِّرة..
وتُعَدُّ مؤسسة (OWASP) منشأةً غير ربحية، تضمن النجاح المستمر للمشروع، وجميع المنتسبين فيها  -تقريبًا- هم من المتطوِّعين، وقد أصدرت (OWASP) في عام 2003م مشروع (OWASP Top Ten) تضمَّن وثيقةً تبيِّن أبرز المخاطر الأمنية الحرجة التي قد تواجهها المنظمات.
وفي عام 2010م، أُعيد تنسيق الوثيقة ليكون ترتيب المخاطر بناءً على قيمة الخطر، وليس بمقدار الانتشار فقط. ويبيِّن الجدول الآتي الثغرات التي حُدِّدت في مشروع (OWASP Top Ten) لعام 2013م:

Image: SYR-RES

1- ثغرات الحقن:
يستطيع المهاجم استغلال ثغرة حقن الكود بواسطة تقديم دخل يدوي خبيث يجعل تطبيق الويب يؤدِّي عملًا غير مسموح به؛ مثل عرض المعلومات الحساسة (الأسماء وكلمات السر)، أو تنفيذ تعليمات معينة (إضافة حساب المدير)، إذ يكون هجوم حقن الكود نتيجةً لنقص في إجراءات الحماية.

وفيما يأتي بعض أنواع ثغرات الحقن في تطبيقات الويب:
-  ثغرة حقن طلبات قواعد البيانات (SQL injection)
- ثغرة حقن تعليمات نظام التشغيل (injection operating system commands)
- ثغرة حقن طلبات (lightweight directory access protocol- LDAP)
- ثغرة حقن طلبات (XML path language- XPATH)

2- ثغرة البرمجة عبر الموقع (Cross-Site Scripting- XSS):
هي ثغرة منتشرة جدًّا في تطبيقات الويب، بحيث عندما يزور المستخدم موقع الويب؛ يطوِّر متصفَّحه علاقة موثوقة مع تطبيق الويب، ويفترض المتصفِّح أنَّ هذه العلاقة موثوقة لأنَّه يطلب من موقع الويب، ويجب عليه أن يثق بأيَّة إجابة تعود إليه من تطبيق الويب.

تسمح هذه العلاقة الموثوق بها للصور والمستندات والـ(script) من تطبيق الويب بالظهور على متصفِّح الويب، ولكن هذه العلاقة لا تكون آمنة عندما يكون التطبيق مصابًا بثغرة (XSS)؛ التي تمكِّن المهاجم من خلق طلب لعنوان (URL) يحوي سكريبت خبيث، ثمَّ يمرِّر عنوان (URL) إلى المستخدم الهدف، فإذا ضغط الهدف على هذا الرابط؛ فإنَّ الطلب الخبيث سُيرسَل إلى تطبيق الويب، الذي بدوره سيردُّ عن طريق إرسال إجابة إلى المستخدم تحوي على سكريبت خبيث؛ هذا السكريبت يتولَّد في السيرفر، ويُرسَل إلى متصفِّح الهدف، ومن ثمَّ يُنفَّذ في المتصفِّح الذي ينفِّذ الـ(script) لأنَّه يثق بتطبيق الويب.

بمعنى أنَّ المهاجم يجب أن يجد ثغرة (XSS) في مكان ما من موقع الويب، وعندما يضغط الهدف على الرابط سيُرسَل طلب إلى التطبيق، وسوف يردُّ التطبيق بإرسال إجابة تُنفَّذ في متصفِّح الهدف؛ وهذا يسمح للمهاجم بحقن سكريبت خبيث في إجابة التطبيق التي تُرسَل إلى متصفِّح الهدف.

وسائل التخفيف من الهجوم (XSS):

-تشفير جمل لغة (HTML) أو تحييد جمل البرمجة؛ إمَّا بإلغائها، وإمَّا بتعديلها.
-استخدام بيئة برمجية، وتعليمات تؤمِّن الحماية من (XSS) مثل (net).
-إذا كان الموقع شديد الأهمية؛ فلا يُحبَّذ الاعتماد كليًّا على لغة البرمجة أو المنصة في توفير الحماية، لأنَّها قد لا توفِّر تقنيات للتخطِّي؛ لذا من الأفضل استخدام سياسة (white list&black list) بحيث يُقيَّم الإدخال بكلِّ أنواعه، فعلى سبيل المثال، إذا كان الحقل المُراد إدخال البيانات به هو رقم هاتف؛ فإنَّ جهاز الخادم يلغي أيَّ رموز أخرى غير الأرقام، ولذلك لن يحتوي الإدخال إلَّا على أرقام فقط.

ولكن هذا النوع يصبح غير فعَّال عندما يجب على الحقل أن يقبل بعض الرموز الخاصة؛ إذ يغدو من الصعب قبول بعضها ومنع البعض الآخر.

3- ثغرة تزوير الطلبات عبر الموقع  (Cross-Site Request Forgery- CSRF):
تتطلَّب هذه الثغرة ثقة المتصفِّح بتطبيق الويب، وأن يخلق المهاجم طلبًا خبيثًا حتى يُضغط عليه من قبل مستخدم جاهل أو قليل الخبرة، ولكن بدلًا من حقن السكريبت الخبيث كما في (XSS)، يُنفِّذ هجوم (CSRF) عملًا شرعيًّا في التطبيق بدون معرفة المستخدم الهدف.

ومعظم العمليات التي يدعمها التطبيق؛ مثل خلق مستخدم جديد، أو تغيير كلمة السر، أو حذف محتوى موقع الويب.. يمكن أن تحدث بدون إدراك المستخدم لهجوم (CSRF)؛ وهذا هو سبب تسميته بتزوير الطلب (request forgery).

المصادر:
هنا
هنا
هنا