ثغرة SQL خطيرة في Online Hospital Management System

تم رصد ثغرة SQL Injection عالية الخطورة في Online Hospital Management System 1.0 ضمن الملف /viewappointment.php.
الاستغلال يتم عن بُعد ويرتبط بمعامل delid، مع وجود استغلال علني منشور بالفعل.
في بيئات الاستضافة، الخطر يتركز على التطبيق المتاح عبر الويب وقاعدة البيانات المرتبطة به، ما يستدعي عزل المسار المتأثر فوراً.

التحليل التقني

الثغرة مسجلة تحت CWE-74 وبدرجة CVSS تبلغ 7.3 وتصنيف HIGH. وفق البيانات المتاحة، المنتج المتأثر هو code-projects Online Hospital Management System 1.0، وتحديداً الملف /viewappointment.php. تم وصف المشكلة على أنها SQL Injection ناتجة عن التلاعب بالمعامل delid داخل وظيفة غير معروفة في هذا الملف.

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

للتحقق من موضع الملف داخل جذر التطبيق:

find . -type f -name "viewappointment.php"

وللبحث عن استخدام المعامل delid داخل الشفرة:

grep -R --line-number "delid" .

المراجع المنشورة المرتبطة بهذه الحالة تشمل الموقع الرسمي للمشروع وروابط الإفصاح العام والاستغلال المنشور: code-projects.org، GitHub، VulDB Submit، VulDB Entry، VulDB CTI.

درجة الخطورة

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

هل تم استغلالها؟

نعم، البيانات المتاحة تشير بوضوح إلى أن الاستغلال تم الإفصاح عنه علناً وقد يُستخدم فعلياً. كما أن خانة KEV مذكور فيها “لا”، أي أنها ليست مدرجة ضمن Known Exploited Vulnerabilities في المعطيات التي زودتني بها، لكن وجود استغلال عام منشور يرفع مستوى الاستعجال من زاوية التشغيل والاستضافة، خصوصاً إذا كان التطبيق متاحاً مباشرة من الإنترنت.

للبحث السريع في السجلات عن الوصول إلى الملف المتأثر:

grep -R --line-number "viewappointment.php" /var/log 2>/dev/null

وللبحث عن الطلبات التي تتضمن المعامل delid:

grep -R --line-number "delid=" /var/log 2>/dev/null

الحل والإصلاح

لا تتضمن البيانات المتاحة نسخة مصححة أو تحديثاً رسمياً محدداً، لذلك يجب التعامل مع الحالة على مرحلتين: تخفيف فوري على مستوى الخادم، ثم إصلاح الشفرة داخل /viewappointment.php. الإجراء العاجل في بيئات الاستضافة هو تقييد أو حجب الوصول إلى الملف المتأثر مؤقتاً إذا لم يكن تعطيله سيوقف خدمة حرجة. بعد ذلك، راجع أي استخدام للمعامل delid وتأكد من رفض القيم غير الصحيحة واستخدام استعلامات محضّرة بدلاً من بناء SQL مباشرة من المدخلات.

للتخفيف الفوري على Nginx يمكن استخدام قاعدة حجب مباشرة للمسار:

location = /viewappointment.php { return 403; }

وللتخفيف الفوري على Apache يمكن حجب الملف نفسه:

<Files "viewappointment.php">
    Require all denied
</Files>

وعلى مستوى PHP، ابدأ بمنع أي قيمة غير رقمية للمعامل delid:

$delid = filter_input(INPUT_GET, "delid", FILTER_VALIDATE_INT);
if ($delid === false || $delid === null) {
    http_response_code(400);
    exit("Invalid delid");
}

وللتأكد من وجود نقاط تحتاج مراجعة داخل التطبيق:

grep -R --line-number "viewappointment.php|delid|SELECT |UPDATE |DELETE |INSERT " .

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

الخلاصة والتوصية

هذه ثغرة SQL Injection عالية الخطورة في Online Hospital Management System 1.0، والاستغلال الخاص بها منشور علناً، ما يجعل التأخير في المعالجة مخاطرة تشغيلية واضحة على خوادم الاستضافة. التوصية العملية هي عزل /viewappointment.php فوراً، فحص السجلات لأي طلبات مرتبطة بالمعامل delid، ثم مراجعة الشفرة داخل الملف لتطبيق تحقق صارم من الإدخال ومنع بناء استعلامات SQL من مدخلات المستخدم مباشرة.