إلى الخلف
اتجاهات عامة
جدول المحتوى

 

تشكل تطبيقات الويب جزءًا كبيرًا من سطح هجوم المؤسسة ووفقًا لـ تقرير التحقيق في خرق البيانات لعام 2020 لشركة Verizon، تطبيقات الويب هي السبب الوحيد الأكثر أهمية لانتهاكات البيانات. تمثل هجمات تطبيقات الويب 43٪ من جميع خروقات البيانات الناجحة.

تحتوي مواقع الويب هذه على العديد من نقاط الضعف مثل تنفيذ التعليمات البرمجية عن بُعد (RCE) وتزوير الطلبات من جانب الخادم (SSRF) وإدراج الملفات المحلية (LFI) وإدخال القالب من جانب الخادم (SSTI) والمزيد. تسمح بعض نقاط الضعف هذه بتطفل شبكات الشركات. نقاط الضعف هذه هي نتيجة الأخطاء التي يرتكبها المبرمجون. يثق المطورون ويأملون أن تنتهي تطبيقاتهم في الأيدي اليمنى، والذي غالبًا ما يتبين أنه أكبر خطأ ارتكبوه على الإطلاق.

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

 

القاعدة #1: لا تثق أبدًا في إدخال المستخدم

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

 

تنفيذ التعليمات البرمجية عن بُعد

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

 

تضمين ملف محلي 

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

 

مثال

عنوان URL للاختبار: https://vulnerable.site/somefile.php?file=validpdffile.pdf

إلى 

عنوان URL الهجومي: https://vulnerable.site/somefile.php?file =.. /وما إلى ذلك/تم تمريره

 

تزوير الطلب من جانب الخادم

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

 

مثال

عنوان URL للاختبار: https://vulneralbe.site/somefile.php?filetocall=https://external.site/somefile.js

إلى

عنوان URL الهجومي: https://vulneralbe.site/somefile.php?filetocall=file:///etc/passwd

 

حقن إس كيو إل

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

 

مثال

عنوان URL للاختبار:https://targetsite.com/somefile.php?id=2

ومع ذلك، إذا لم يتحقق تطبيق الويب من صحة إدخال المستخدم، فيمكن للمهاجم إرسال شيء كالتالي:

عنوان URL الهجومي: https://targetsite.com/somefile.php?id =' أو '1' = '1' — +

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

 

كيف يمكنك تقليل نقاط الضعف ومنع الهجمات

دعونا نلقي نظرة على المشكلة المطروحة قبل أن نقترح حلاً. يلخص المثال التالي المشكلة:

هذا تطبيق اختبار يقبل إدخال المستخدم ويعيد النتائج بناءً عليه.

Web App normal search

يبحث المستخدم العادي عن مواضيع مثل Python أو JAVA، بينما يقوم المتسللون الذين لديهم نية ضارة بإرسال شيء مثل هذا:

Web App unvalidated

هناك عدد من الرموز التي يمكننا إدخالها، مثل الاقتباس المفرد (')، وعلامات الاقتباس المزدوجة («)، والأقواس ذات الزاوية المفتوحة والمغلقة (<>)، والتي تساوي (=)، والأقواس المفتوحة والمغلقة، وإذا قبل تطبيق الويب هذه الرموز دون التحقق منها، يمكن للمهاجمين استخدام هذا كسلاح لسرقة ملفات تعريف الارتباط الخاصة بالجلسة لأشخاص آخرين، باستخدام حمولات XSS المتقدمة (حمولات البرمجة النصية عبر المواقع).

الآن، دعونا نحاول فهم منطق الكود:

Web App coding gone bad

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

The right way to code

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

 

ملخص

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

لم يتم العثور على أية عناصر.

مدونات ذات صلة