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

تخيّل نموذج تسجيل دخول بسيطًا، وخلفه سطر بايثون يبني الاستعلام بدمج ما كتبه المستخدم مباشرة في نص SQL، كما يلي:

query = f"SELECT id, name FROM users WHERE name = '{name}' AND password = '{password}'"

هذا سيناريو شائع في الكود القديم وفي مشاريع المبتدئين. إذا كتب المستخدم اسمه عاديًا وكتب في خانة كلمة المرور النص x' OR '1'='1 فإن الاستعلام الذي يصل إلى قاعدة البيانات يصبح شيئًا آخر تمامًا:

SELECT id, name FROM users WHERE name = 'sara' AND password = 'x' OR '1'='1'

في SQL يُقيَّم AND قبل OR، فيصبح الشرط صحيحًا لكل الصفوف مهما كانت كلمة المرور، وتعيد القاعدة أول مستخدم فيها. هذه هي فكرة حقن SQL (SQL Injection): نص أدخله المستخدم يُعامل على أنه جزء من الأمر، لا على أنه بيانات.

أين يكمن الخلل بالضبط

المشكلة ليست في SQL نفسها ولا في قاعدة البيانات. المشكلة أن التطبيق يخلط في سلسلة نصية واحدة شيئين مختلفين: بنية الاستعلام التي كتبها المبرمج، والقيم التي جاءت من المستخدم. القاعدة لا تعرف أي جزء كتبه المبرمج وأي جزء كتبه الغريب، فتنفذ كل شيء.

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

خذ جملة SQL عادية كمثال:

UPDATE countrySET population = population + 1WHERE name = 'USA';

بنية الجملة هي UPDATE وSET وWHERE وأسماء الجدول والأعمدة. هذه كلها يجب أن تأتي من كود التطبيق. القيمة الوحيدة التي يحق أن تأتي من المستخدم هي 'USA'، ويجب أن تبقى قيمة فقط مهما كان شكلها.

شغّل الفرق بنفسك

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

import sqlite3con = sqlite3.connect(":memory:")cur = con.cursor()cur.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, password TEXT)")cur.executemany(    "INSERT INTO users (name, password) VALUES (?, ?)",    [("sara", "s3cret-1"), ("omar", "s3cret-2")],)def login_unsafe(name, password):    query = f"SELECT id, name FROM users WHERE name = '{name}' AND password = '{password}'"    print("Query:", query)    return cur.execute(query).fetchone()def login_safe(name, password):    query = "SELECT id, name FROM users WHERE name = ? AND password = ?"    return cur.execute(query, (name, password)).fetchone()payload = "x' OR '1'='1"print("unsafe:", login_unsafe("sara", payload))print("safe:  ", login_safe("sara", payload))print("safe, correct password:", login_safe("sara", "s3cret-1"))

الناتج عند التشغيل:

Query: SELECT id, name FROM users WHERE name = 'sara' AND password = 'x' OR '1'='1'unsafe: (1, 'sara')safe:   Nonesafe, correct password: (1, 'sara')

النسخة الهشة سجّلت الدخول بكلمة مرور خاطئة. النسخة الثانية عاملت النص كله كأنه كلمة مرور حرفية، فلم تجد شيئًا، وما زالت تقبل كلمة المرور الصحيحة. يوصي توثيق بايثون الرسمي لوحدة sqlite3 بالصيغة الثانية صراحة: استخدم placeholders دائمًا بدل تنسيق النصوص عند ربط القيم بجمل SQL.

ما الذي يمكن أن يحدث بعد نجاح الحقن

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

في قائمة OWASP Top 10 لعام 2025 جاءت فئة الحقن (Injection) في المرتبة الخامسة، بعد أن كانت في الثالثة. وتصف OWASP حقن SQL بأنه قليل التكرار نسبيًا لكنه عالي الأثر، وتذكر أن عدد الثغرات المسجلة فيه (CVE) يتجاوز 14 ألفًا.

أنواع الحقن بإيجاز

في التصنيف الشائع تنقسم الهجمات إلى ما تظهر نتيجته مباشرة في الصفحة أو في رسائل الخطأ، وما يسمى الحقن الأعمى (blind) حيث لا يرى المهاجم البيانات لكنه يستنتجها من اختلاف سلوك التطبيق أو من زمن الاستجابة، وما يُسرَّب عبر قناة أخرى غير الصفحة نفسها. الرسم التالي يعرض تصنيفًا منشورًا عام 2010 لهجمات حقن SQL، وهو قديم لكنه يعطي فكرة عن تعدد الأشكال.

الأنواع تختلف في طريقة الاستغلال، أما السبب فواحد: استعلام بُني بدمج نص من المستخدم.

ثلاث حوادث موثقة

Heartland وHannaford و7-Eleven

في 17 أغسطس 2009 أعلنت وزارة العدل الأمريكية لائحة اتهام ضد ألبرت غونزاليس، وقالت إنها تتعلق بسرقة بيانات أكثر من 130 مليون بطاقة ائتمان وخصم. تذكر اللائحة من بين الضحايا شركة معالجة المدفوعات Heartland Payment Systems وسلسلة المتاجر 7-Eleven وسلسلة السوبرماركت Hannaford. بحسب اللائحة بدأت الهجمات في أكتوبر 2006 واستمرت حتى مايو 2008، وكانت من نوع حقن SQL، واختير الضحايا بتصفح قوائم كبرى الشركات ومواقعها الإلكترونية. وتذكر اللائحة أيضًا أن المتهمين ثبّتوا برمجيات لاعتراض بيانات البطاقات لحظيًا، أي أن الحقن كان بوابة الدخول وليس نهاية الهجوم.

هذه ادعاءات واردة في لائحة اتهام كما نشرتها وزارة العدل. وما يهمنا تقنيًا أن حملة بهذا الحجم امتدت نحو سنة ونصف بحسب التواريخ الواردة في اللائحة.

TalkTalk، بريطانيا

في أكتوبر 2015 تعرضت شركة الاتصالات البريطانية TalkTalk لهجوم وصل فيه المهاجم إلى بيانات 156,959 عميلًا، منها الأسماء والعناوين وتواريخ الميلاد وأرقام الهواتف والبريد الإلكتروني. في أكتوبر 2016 فرض مكتب مفوض المعلومات البريطاني (ICO) على الشركة غرامة قياسية قدرها 400 ألف جنيه إسترليني.

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

MOVEit Transfer، 2023

في يونيو 2023 نشرت وكالة الأمن السيبراني الأمريكية (CISA) ومكتب التحقيقات الفدرالي (FBI) تنبيهًا مشتركًا عن استغلال مجموعة CL0P لثغرة حقن SQL كانت مجهولة وقتها (zero-day) في برنامج MOVEit Transfer لنقل الملفات من شركة Progress Software، وسُجلت باسم CVE-2023-34362. بحسب التنبيه بدأ الاستغلال في 27 مايو 2023، وجرى تثبيت برمجية web shell اسمها LEMURLOOT على تطبيقات MOVEit المتاحة على الإنترنت، ثم استُخدمت لسرقة البيانات من قواعد البيانات الخلفية.

الفرق هنا أن الثغرة لم تكن في كود كتبته الجهة المتضررة، بل في منتج جاهز اشترته.

ما يجمع هذه الحوادث

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

الدرس العملي مزدوج: لا تبنِ استعلاماتك بالدمج، وافحص ما ورثته أو اشتريته كما تفحص ما كتبته.

كيف تحمي تطبيقك

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

1. استخدم الاستعلامات ذات المعاملات

   اكتب جملة SQL كاملة أولًا بعلامات مكان للقيم، ثم مرّر القيم منفصلة. بهذا تميز قاعدة البيانات دائمًا بين الكود والبيانات مهما كان المدخل. في بايثون مع sqlite3 هذا يعني ? وتمرير tuple كوسيط ثانٍ لـ execute، كما في دالة login_safe أعلاه. وتدعم معظم اللغات وقواعد البيانات الأخرى هذا الأسلوب.

2. قلّل صلاحيات حساب قاعدة البيانات

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

3. تحقق من الأجزاء التي لا تقبل المتغيرات

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

4. لا تعتمد على الهروب من الرموز وحدها

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

ثلاث ملاحظات تصحح اعتقادات شائعة. الإجراءات المخزنة (stored procedures) ليست آمنة تلقائيًا: تذكر OWASP أنها آمنة حين تبنى بمعاملات، وأن الإجراء الذي يدمج النصوص داخليًا ثم ينفذها بـ exec أو EXECUTE IMMEDIATE يعيد المشكلة نفسها. وطبقات التجريد مثل ORM لا تعفيك: توثق OWASP حالة تسمى HQL Injection في Hibernate، وهي حقن عبر لغة الاستعلام الخاصة بالإطار، وتوفر هذه اللغة معاملات مسماة للحماية منه. أما التحقق من المدخلات فتوصي به OWASP كدفاع ثانوي، لكنها تنبه إلى أن البيانات التي اجتازت التحقق ليست بالضرورة آمنة للدمج في الاستعلام.

وفي الجانب التشغيلي، ومن تجربة الحوادث أعلاه وليس من نص مصدر بعينه: ضع قائمة بكل التطبيقات والصفحات القديمة التي ما زالت تعمل، وراقب نشرات الثغرات للبرامج الجاهزة التي تستخدمها، وثبّت التحديثات الأمنية فور صدورها.

الخطوة التي تنفذها اليوم

افتح مشروعك وابحث عن كل استعلام يُبنى بـ f-string أو بعلامة + أو بـ % أو بدالة format. كل ما تجده يحتاج أن يتحول إلى استعلام بمعاملات.

المصادر

• OWASP Top 10:2025، A05 Injection، OWASP
• SQL Injection Prevention Cheat Sheet، OWASP Cheat Sheet Series
• توثيق وحدة sqlite3، Python Software Foundation
• Data Related to More Than 130 Million Credit and Debit Cards Allegedly Stolen، وزارة العدل الأمريكية
• TalkTalk gets record £400k slap-slap from Brit watchdog، The Register
• CISA and FBI Release Advisory on CL0P Ransomware Gang Exploiting MOVEit Vulnerability، CISA