SQL Injection في موقع جامعة الفيوم - تجربة حقيقية

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

🔎 بداية اكتشاف الثغرة​

أنا كنت في جامعة الفيوم، وبالتالي بتعامل بشكل مستمر مع موقع الجامعة. وبما إني مهتم بمجال الـ Cybersecurity وعندي خبرة في الـ Bug Bounty Hunting، جت في بالي فكرة إني أراجع أمان الموقع الأساسي للجامعة وأشوف إذا كان فيه أي مشاكل أمنية.
بدأت بعملية Recon بسيطة، وخلالها لقيت ملف قديم جدًا اسمه controlpanel.aspx، على حد ما أتذكر كان راجع لحوالي سنة 2011.
الملف كان عبارة عن صفحة بتطلب إدخال كلمة مرور بس، من غير اسم مستخدم أو أي خطوة تحقق إضافية واضحة.
وقتها فكرت أجرب اختبار بسيط على الصفحة، وأشوف إذا كانت بتتعامل مع المدخلات بشكل آمن ولا لأ. 🤔

---

⚠️ اكتشاف ثغرة SQL Injection​

الاختبار كشف إن الصفحة كانت معرضة لثغرة SQL Injection، وده بسبب طريقة بناء استعلام SQL باستخدام مدخلات المستخدم مباشرة، من غير استخدام Parameterized Queries.
الجزء المسؤول عن المشكلة كان بالشكل ده:

SqlCommand updatecommand1 = new SqlCommand("SELECT [password]  FROM adminuser where [password]='" + TextBox3.Text + "'", newsConection1);

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

---

🚨 ليه الثغرة كانت خطيرة؟​

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

النوع ده من الثغرات ممكن تكون له عواقب خطيرة، منها:

• 🔓 الوصول غير المصرح به لبيانات حساسة.
• 🗃️ كشف معلومات موجودة في قواعد البيانات.
• ⚙️ التأثير على بيانات أو وظائف أخرى لو صلاحيات قاعدة البيانات بتسمح بكده.
• 🎓 احتمالية تعريض بيانات الطلاب أو الأنظمة الإدارية للخطر، حسب نطاق الوصول الفعلي.

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

---

🤝 قررت أبلغ الجامعة بدل ما أنشر الثغرة​

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

---

✅ إيه اللي حصل بعد الإبلاغ؟​

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

---

🛡️ إيه اللي المفروض تعمله لو اكتشفت ثغرة في موقع جامعة أو جهة حكومية؟​

لو أنت بتتعلم Cybersecurity أو Bug Bounty Hunting، ووقعت على ثغرة في موقع مشتركش في برنامج اختبار أمني مصرح بيه، فيه شوية قواعد مهمة لازم تاخد بالك منها:

1. وقف الاختبار عند الحد الضروري لإثبات المشكلة. ما تحاولش تستخرج بيانات حقيقية أو توسع نطاق الوصول لمجرد التأكد من حجم الثغرة.
2. ما تعدلش بيانات وما تنفذش عمليات ممكن تسبب ضرر. الوصول لبيانات حساسة مش مبرر لاستعراضها أو نسخها.
3. وثّق المشكلة بأقل قدر ممكن من الأدلة. وصف واضح للثغرة، والصفحة المتأثرة، وتأثيرها المحتمل غالبًا أفضل من جمع بيانات إضافية.
4. ابحث عن قناة رسمية للإبلاغ. ممكن تكون جهة أمن المعلومات، أو مركز الاستجابة للحوادث، أو برنامج إفصاح عن الثغرات تابع للمؤسسة.
5. ما تنشرش تفاصيل قابلة للاستغلال قبل التنسيق مع الجهة المسؤولة. النشر غير المدروس ممكن يعرض بيانات الناس للخطر أو يسهل استغلال الثغرة.
6. احتفظ بسجل للتواصل. لو أبلغت عن المشكلة، احتفظ بتاريخ البلاغ والردود، واتبع الإجراءات الرسمية المتاحة.

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

---

💡 الخلاصة: الاحتراف مش بس إنك تكتشف الثغرة​

مفيش نظام آمن بنسبة 100%، وده شيء معروف في مجال الأمن السيبراني. لكن الفرق الحقيقي بيظهر في سرعة اكتشاف المشكلات، وطريقة الاستجابة ليها، ومدى استعداد المؤسسة للتعامل مع البلاغات الأمنية بمسؤولية.
تجربتي مع موقع جامعة الفيوم كانت بالنسبة لي مثالًا على إن الإبلاغ المسؤول ممكن يساعد في حل المشكلة بدل ما يحولها لأزمة أكبر.
لو اكتشفت ثغرة، مش لازم تستغلها علشان تثبت إنك قادر، ومش لازم تنشر تفاصيلها علشان تثبت إنك اكتشفتها.
أحيانًا أفضل تصرف ممكن تعمله هو إنك توصل المعلومة للشخص المسؤول، وتساعد في تقليل الضرر، وتحافظ على بيانات الناس.
في النهاية، الاحتراف مش بس إنك تعرف تكتشف ثغرة خطيرة؛ الاحتراف كمان إنك تعرف تتعامل معاها بمسؤولية، وتحترم خصوصية الآخرين، وتلتزم بالحدود القانونية.
خليك محترف في اللي بتكتشفه، ومحترم في اللي بتعمله بعد الاكتشاف. 🔐