حقن SQL SQLi
هجوم على المواقع يكتب فيه شخص أوامر لقاعدة البيانات داخل نموذج أو في عنوان الصفحة، فينفّذها الموقع ويكشف بيانات يجب أن يحميها أو يغيّرها أو يحذفها.
يُعرف أيضًا بـ SQLi SQL Injection هجوم حقن SQL حقن أوامر SQL حقن قاعدة البيانات هجوم الحقن
التعريف
ما هو حقن SQL
لديك متجر إلكتروني. يكتب زائر شيئًا غريبًا في مربع البحث ويضغط Enter، فتعرض له الصفحة أسماء كل العملاء وأرقام هواتفهم وسجل طلباتهم. لم يسرق أحد كلمة مرور. كتب الزائر الكلمات المناسبة في المكان الخطأ، وتولّى موقعك الباقي. هذا هو حقن SQL.
تحفظ معظم المواقع معلوماتها في قاعدة بيانات: مخزن منظّم من الجداول، يشبه مجموعة من جداول البيانات. ولكي يقرأ الموقع هذه المعلومات أو يغيّرها، يستخدم لغة اسمها SQL (لغة الاستعلام البنيوية). وكل طلب يرسله يسمى استعلامًا، مثل "ابحث عن العميل صاحب هذا البريد الإلكتروني".
يحدث حقن SQL عندما يأخذ الموقع ما يكتبه الزائر ويضعه مباشرة داخل أحد هذه الاستعلامات. فإذا كتب الزائر أوامر SQL بدل النص العادي، لا تستطيع قاعدة البيانات أن تفرّق بينهما، فتنفّذ أمر المهاجم كأن الموقع هو من كتبه. ويختصر كثيرون الاسم إلى SQLi.
كيف يعمل هجوم حقن SQL
تخيّل موظفًا في بنك ينقل أي ورقة يسلّمها له العميل، كلمة بكلمة، إلى موظفي الخزنة. الورقة العادية تقول "أظهروا لي رصيدي". والورقة الماكرة تقول "أظهروا لي رصيدي، وافتحوا كل الخزائن أيضًا". وإذا لم يقرأ الموظف الورقة أولًا، ينفّذ موظفو الخزنة ما فيها.
في الموقع الإلكتروني، تسير الخطوات عادة هكذا:
- يبحث المهاجم عن مكان يرسل نصًا إلى قاعدة البيانات: نموذج تسجيل دخول، أو مربع بحث، أو نموذج تواصل، أو عنوان الصفحة نفسه، مثل صفحة منتج تنتهي بـ "?id=25".
- يكتب جزءًا صغيرًا من SQL بدل النص العادي. ومن الأمثلة المعروفة كتابة ' OR '1'='1 في خانة كلمة المرور في نموذج تسجيل الدخول.
- يضيف الموقع هذا النص إلى استعلامه دون أن يتحقق منه. فيصبح الاستعلام كأنه يقول "اسمح لهذا الشخص بالدخول إذا كانت كلمة المرور صحيحة، أو إذا كان 1 يساوي 1".
- وبما أن 1 يساوي 1 دائمًا، تجيب قاعدة البيانات بنعم، ويدخل المهاجم دون أن يعرف أي كلمة مرور.
بعض الهجمات أهدأ من ذلك. ففي حقن SQL الأعمى لا تعرض الصفحة أي بيانات، فيطرح المهاجم على قاعدة البيانات أسئلة جوابها نعم أو لا، ويراقب كيف تتغير الصفحة أو كم تستغرق حتى تظهر. هذا عمل بطيء إذا تم يدويًا، ولهذا يستخدم المهاجمون أدوات آلية مجانية تقوم به عنهم.
ما الذي يستطيع المهاجم فعله
عندما تبدأ قاعدة البيانات في تنفيذ أوامره، يتوقف حجم الضرر على الصلاحيات التي يملكها حساب الموقع في قاعدة البيانات. وكثيرًا ما تكون هذه الصلاحيات أكبر بكثير مما يحتاجه الموقع. قد يتمكن المهاجم من:
- قراءة البيانات الخاصة، مثل أسماء العملاء وعناوينهم وبريدهم الإلكتروني وسجل طلباتهم والسجلات الطبية أو كلمات المرور المحفوظة
- الدخول باسم مستخدم آخر، حتى لو كان مدير الموقع
- تغيير البيانات، مثل الأسعار أو الأرصدة أو حالة الطلبات
- حذف جداول كاملة، أو قاعدة البيانات كلها
- في بعض الإعدادات، الوصول إلى الخادم نفسه ووضع ملفات ضارة عليه
لماذا يهم هذا عملك
حقن SQL من أقدم هجمات الويب، وما زال موجودًا حتى اليوم. فمجتمع OWASP المفتوح، الذي ينشر قائمة OWASP Top 10 المعروفة لأخطر مشكلات تطبيقات الويب، أبقى هجمات الحقن في هذه القائمة لسنوات. فهي سهلة التجربة، وما زالت مواقع كثيرة تحتوي على نموذج واحد منسي مفتوح لها.
بالنسبة لصاحب العمل، نادرًا ما تكون الخسارة الحقيقية تقنية. فهي قائمة عملاء مسرّبة، أو متجر يبيع بسعر خاطئ، أو نظام حجوزات يفقد مواعيد أسبوع كامل، أو رسالة تضطر إلى إرسالها لعملائك تخبرهم فيها أن بياناتهم انكشفت. وفي بلدان كثيرة، تطلب قوانين حماية البيانات مثل GDPR أن تحمي البيانات الشخصية وأن تبلّغ عن أي تسريب.
هل بُني كل نموذج في موقعك مع وضع هذا الخطر في الحسبان؟ المواقع التي جُمعت بسرعة من إضافات قديمة، أو عدّلتها أيدٍ كثيرة على مرّ السنين، أكثر عرضة لأن تخفي نقطة ضعف.
كيف تحمي موقعك من حقن SQL
الحل الأساسي معروف، وهو يعمل. ومعظم الحماية تكمن في طريقة بناء الموقع، لذلك هذه أسئلة جيدة تطرحها على المطورين أو على مزوّد الخدمة.
- الاستعلامات المُعدّة مسبقًا. وتسمى أيضًا الاستعلامات ذات المعاملات. يرسل الموقع الاستعلام ونص الزائر كلًّا على حدة، فتتعامل قاعدة البيانات مع النص دائمًا كبيانات عادية ولا تنفّذه كأمر أبدًا. هذا هو الدفاع الأساسي. وأطر العمل الحديثة مثل Laravel تفعل ذلك تلقائيًا عندما يستخدم المطورون أدواتها المدمجة للتعامل مع قاعدة البيانات.
- فحص المدخلات. خانة رقم الهاتف يجب أن تقبل الأرقام فقط، وخانة التاريخ يجب أن تقبل التواريخ فقط. رفض المدخلات الغريبة مبكرًا يغلق أبوابًا كثيرة.
- أقل قدر من الصلاحيات. الحساب الذي يستخدمه الموقع للوصول إلى قاعدة البيانات يجب أن يملك الصلاحيات التي يحتاجها فقط. صفحة بحث عامة لا سبب يجعلها تحذف الجداول.
- رسائل خطأ هادئة. رسالة خطأ مفصّلة من قاعدة البيانات على الشاشة تعطي المهاجم خريطة. اعرض على الزوار رسالة قصيرة وبسيطة، واحفظ التفاصيل في سجلات خاصة.
- التحديثات. حدّث المنصة والإضافات والمكتبات باستمرار، لأن الإصدارات القديمة كثيرًا ما تحتوي على ثغرات معروفة.
- جدار حماية تطبيقات الويب. وهو مرشّح يقف أمام الموقع ويحجب كثيرًا من أنماط الهجوم المعروفة قبل أن تصل إلى الكود. إنه مفيد، لكنه لا يصلح الكود غير الآمن.
- الاختبار المنتظم. اختبار الاختراق (هجوم آمن ومخطط ينفّذه خبراء) وفحص الثغرات يكشفان نقاط الضعف قبل أن يجدها المهاجم.
وهذه مقارنة بين عادات يومية:
| عادة خطرة | عادة أكثر أمانًا |
|---|---|
| إضافة نص الزائر مباشرة إلى الاستعلام | استخدام الاستعلامات المُعدّة مسبقًا في كل استعلام |
| حساب واحد لقاعدة البيانات بصلاحيات كاملة لكل شيء | حساب محدود لكل جزء من الموقع |
| عرض أخطاء قاعدة البيانات كاملة على الصفحة | رسالة قصيرة للزوار، والتفاصيل في سجلات خاصة |
| إضافات تبقى بلا تحديث لشهور | تحديثات منتظمة وقائمة واضحة بكل ما هو مثبّت |
| اختبار أن الميزات تعمل فقط | اختبار ما يحدث أيضًا عندما يكتب أحدهم شيئًا ضارًا |
أخطاء يقع فيها الناس
- الاعتماد على الفحص في المتصفح. الفحص الذي يعمل على جهاز الزائر نفسه سهل التجاوز، لذلك يجب أن يفحص الخادم كل شيء مرة أخرى.
- الظن أن الموقع الصغير في أمان. الأدوات الآلية تفحص أعدادًا هائلة من المواقع ولا تهتم بحجمها.
- إصلاح نموذج واحد ونسيان الباقي. مربع البحث وأدوات التصفية وعنوان الصفحة والـ API الذي يعمل خلف تطبيق الجوال، كلها تحتاج إلى العناية نفسها.
- حفظ كلمات المرور كنص عادي. إذا تسرّبت البيانات، فكلمات المرور المحفوظة بتجزئة قوية (أي محوّلة إلى رمز مبعثر لا يمكن قراءته مرة أخرى) أصعب بكثير في استغلالها.
- الاكتفاء بجدار الحماية. المرشّح يمنحك وقتًا. أما الاستعلام غير الآمن خلفه فما زال يحتاج إلى إصلاح.
كيف نساعدك
في Linkysoft، اختبار حقن SQL جزء من خدمات الأمن السيبراني التي نقدمها. ننفّذ هجمات آمنة ومحاكاة على موقعك وتطبيقك والـ API، ونراجع الكود، ثم نعطيك قائمة بلغة بسيطة بما وجدناه وكيف تصلحه. وبعد الإصلاح نختبر من جديد. يصلح هذا أيضًا للمواقع التي بنتها فرق أخرى، والفحص الأمني المجاني خطوة أولى سهلة.
هل تخطط لنظام جديد؟ تطبيقات الويب وأنظمة الإدارة التي نبنيها آمنة منذ التصميم، مع تقوية الحماية وفق OWASP Top 10 واختبار الاختراق قبل الإطلاق.
أسئلة حول حقن SQL
ما هو حقن SQL بكلمات بسيطة؟
هل يمكن أن يتعرض موقع صغير لحقن SQL؟
كيف أعرف إن كان موقعي معرّضًا لحقن SQL؟
ما أفضل طريقة لمنع حقن SQL؟
هل يوقف جدار الحماية حقن SQL؟
ما هو حقن SQL الأعمى؟
ماذا أفعل إذا تعرض موقعي لحقن SQL؟
هل حقن SQL مشكلة تخص المواقع فقط؟
ما زلت غير متأكد كيف ينطبق هذا على مشروعك؟
أخبرنا بما تبنيه وسنجيبك بلغة واضحة.