ثغرة SQL Injection عبر Host Header في المواقع

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

بداية القصة مع تغيير كلمة المرور 🔐​

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

403 Forbidden

وكان ضمن الاستجابة Header مشابه لـ:

X-Amz-Cf-Id: abc123xyz

---

ليه المعلومة دي مهمة؟ 🤔​

الـ Header ده غالبًا بيشير لاستخدام خدمات CDN الخاصة بـ Amazon CloudFront.
وده معناه إن الطلبات بتمر عبر طبقة وسيطة قبل ما توصل للسيرفر الأصلي.
وجود معلومات من النوع ده ممكن يساعد الباحث يفهم البنية التحتية للتطبيق بشكل أفضل، وده يعتبر نوع من أنواع Information Disclosure.

---

إيه علاقة AWS Load Balancer بالموضوع؟ ☁️​

بعد البحث في طريقة عمل البنية التحتية، اتضح إن التطبيق بيعتمد على خدمات AWS مع Load Balancer.
الخدمات دي بتضيف Headers إضافية للحفاظ على معلومات الطلب الأصلي، ومن أشهرها:

X-Forwarded-For
X-Forwarded-Proto
X-Forwarded-Host

كل Header من دول بيستخدم لنقل معلومات مهمة للسيرفر الخلفي.

---

اكتشاف سلوك غريب في X-Forwarded-Host 🚨​

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

مثال على شكل الـ Header:

X-Forwarded-Host: example.com

في بعض التطبيقات الضعيفة أمنيًا، القيم دي ممكن يتم استخدامها في عمليات التحقق أو المقارنات داخل قاعدة البيانات بدون فلترة كافية.
وده بيفتح الباب لمشاكل أمنية خطيرة جدًا.

---

من Host Header لثغرة SQL Injection 😲​

الباحث بدأ يشك إن التطبيق بيستخدم قيمة الـ Host Header للتحقق من قائمة نطاقات مسموح بيها (Whitelist).
لو التطبيق بيعمل استعلام لقاعدة البيانات بالشكل التقليدي غير الآمن، فده ممكن يؤدي لظهور ثغرات SQL Injection.

مثال تعليمي على كود غير آمن:

$query = "SELECT * FROM whitelist WHERE domain='$domain'";

المشكلة هنا إن إدخال المستخدم بيتضاف مباشرة للاستعلام.

أما الطريقة الصحيحة فتكون باستخدام Prepared Statements:

$stmt = $pdo->prepare(
    "SELECT * FROM whitelist WHERE domain = ?"
);
$stmt->execute([$domain]);

ليه SQL Injection لسه من أخطر الثغرات؟ ⚠️​

رغم إن الثغرة قديمة جدًا، لكنها لسه بتظهر في تطبيقات كتير بسبب:

✅ عدم فلترة المدخلات بشكل صحيح.​

✅ الاعتماد على استعلامات SQL مباشرة.​

✅ غياب اختبارات الأمان الدورية.​

✅ أخطاء المطورين أثناء بناء الأنظمة.​

---

مفاجأة أكبر داخل قاعدة البيانات 😬​

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

كلمات المرور لازم يتم تخزينها باستخدام خوارزميات Hash قوية زي:

bcrypt
Argon2
PBKDF2

وتخزين كلمات المرور كنصوص عادية (Plain Text) يعتبر كارثة أمنية حقيقية.

---

الدروس المستفادة للمطورين 👨‍💻​

لو بتطور تطبيق ويب، لازم تركز على النقاط دي:
🔹 استخدم Prepared Statements دائمًا.
🔹 فلتر كل المدخلات القادمة من المستخدم.
🔹 لا تثق في قيم Headers القادمة من العميل.
🔹 فعّل Web Application Firewall (WAF).
🔹 خزّن كلمات المرور باستخدام Hash قوي.
🔹 نفّذ اختبارات اختراق دورية على التطبيق.

---

الدروس المستفادة للباحثين الأمنيين 🛡️​

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

عشان كده أي عملية Bug Bounty ناجحة بتعتمد على:

✅ الملاحظة الدقيقة.​

✅ فهم طريقة عمل البنية التحتية.​

✅ التفكير خارج السيناريوهات التقليدية.​

---

الخلاصة 🎯​

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