SilentN0va: تطبيق الأمن السيبراني بالعربي

x32x01
  • بواسطة x32x01 ||
لو بتتعلم Cyber Security، غالبًا عديت بالموقف ده: تقرأ عن Vulnerability، تشوف فيديو عنها، تفهم الـConcept كويس جدًا، لكن أول ما تدخل Lab أو CTF وتقول "يلا أجرب"، تلاقي نفسك مش عارف تبدأ منين.
المشكلة هنا مش بالضرورة في فهمك.
اللي ناقص غالبًا هو التحويل من المعرفة النظرية للتطبيق العملي: تعرف تبص على الـRequest، تحدد إيه اللي يستحق الاختبار، تجرب، تقرأ الـResponse، وتربط النتيجة بالخطوة اللي بعدها.

وده تحديدًا هو الهدف من مشروع SilentN0va Offensive Security: تقديم محتوى عربي عملي يساعدك تنتقل من "أنا فاهم الثغرة" إلى "أنا قادر أكتشفها وأختبرها بنفسي" داخل بيئات تدريبية آمنة.



إيه المشكلة اللي بيحاول SilentN0va يحلها؟​

أغلب الناس وهي بتبدأ في Cyber Security بتقضي وقت كبير في قراءة الـTheory.
وده مهم طبعًا، لكن فيه مرحلة تانية أصعب شوية.
تفتح Burp Suite، تشوف الـRequests والـParameters قدامك، وتبقى فاهم نظريًا إن فيه Vulnerability ممكن تكون موجودة، لكن السؤال الحقيقي يفضل:
"أعمل إيه دلوقتي؟"
تجرب إيه؟
تبص على إيه في الـResponse؟
إزاي تعرف إن الـInput ده يستحق الاختبار؟
ولو أول محاولة فشلت، تجرب إيه بعدها؟

الفجوة دي بين المعرفة النظرية والتطبيق العملي هي واحدة من أهم المشاكل اللي بيحاول المشروع يعالجها.
الفكرة مش إنك تحفظ تعريفات Vulnerabilities، لكن إنك تتعلم طريقة التفكير اللي توصلك للثغرة.
🧠 بدل ما يكون عندك معلومة عن الثغرة فقط، يبقى عندك منهج تفكير تقدر تستخدمه لما تقابل Application جديدة.



المحتوى مبني على التطبيق العملي​

المشروع بيقدم المحتوى بالعربي، وهدفه مش مجرد ترجمة محتوى أجنبي أو تجميع مجموعة Links في مكان واحد.
كل Playlist بتحاول تاخدك في رحلة تبدأ من الأساسيات المطلوبة لفهم الـVulnerability، وبعدها تنتقل للتطبيق العملي خطوة بخطوة داخل بيئة تدريبية.

الفكرة الأساسية هي إنك تتعلم:
  • إيه اللي بتدور عليه؟
  • ليه الـVulnerability بتحصل؟
  • إزاي تختبر الـApplication؟
  • إزاي تقرأ النتيجة؟
  • إزاي تعرف الخطوة التالية؟
  • وإزاي تعتمد على نفسك بدل ما تكون مستني حد يقولك مكان الثغرة؟
وده مهم جدًا لأن الـLabs والـCTFs والشغل الحقيقي مش هيقولولك بشكل مباشر:
"الثغرة موجودة هنا، استخدم الـPayload ده."
أنت اللي المفروض تستكشف وتختبر وتربط المعلومات ببعض.



1. Business Logic Flaws​

Business Logic Flaws مختلفة عن كثير من الثغرات التقنية التقليدية.
الـApplication ممكن تكون شغالة بشكل سليم جدًا من الناحية التقنية، ومفيش SQL Injection أو XSS واضح، لكن المشكلة تكون في منطق العمل نفسه.

مثلًا، ممكن Application تسمح للمستخدم إنه:
  • يضيف كمية غير منطقية من منتج.
  • يتجاوز خطوة مفروضة في عملية معينة.
  • يستخدم Discount بطريقة غير متوقعة.
  • يعدل ترتيب خطوات Workflow بطريقة تكسر القاعدة المفروضة.
هنا الـApplication مش بالضرورة "مكسورة" من الناحية البرمجية، لكن فيه افتراض في الـBusiness Logic المستخدم قدر يكسره.
وده محتاج منك تفكير مختلف.
بدل ما تبص للـApplication كأنها مجرد مجموعة Requests، حاول تفهم:
إيه القواعد اللي الـApplication المفروض تمشي عليها؟
وبعد كده اسأل نفسك:
هل أقدر أوصل لحالة المفروض إنها مستحيلة؟
🎯 الـPlaylist دي بتركز على بناء طريقة التفكير دي، وفهم الـBusiness Logic، واختبار السيناريوهات داخل بيئات تدريبية.
🔗 رابط الـPlaylist:
PortSwigger Business Logic Labs | Full Course & Solutions



2. JWT Authentication​

الـJSON Web Tokens أو JWT مستخدمة بشكل واسع في تطبيقات الويب والـAPIs الحديثة.
فكرة الـToken نفسها بسيطة نسبيًا، وغالبًا بتتكون من:
  • Header
  • Payload
  • Signature
لكن المشكلة الحقيقية بتبدأ لما تسأل:
هل الـApplication بتتحقق من الـToken بالطريقة الصحيحة؟
هنا ممكن تظهر مجموعة مختلفة من المشاكل، مثل:
  • ضعف في التحقق من الـSignature.
  • Secrets ضعيفة يمكن تخمينها أو اختبارها في بيئة تدريبية.
  • مشاكل مرتبطة باختيار الـAlgorithm.
  • Key Confusion في بعض السيناريوهات.
  • أخطاء في طريقة تعامل الـApplication مع بيانات الـToken.
المهم هنا إنك متتعاملش مع JWT كـString من ثلاث أجزاء وخلاص.
لازم تفهم:
إيه اللي بيتم توقيعه؟ وإزاي السيرفر بيتحقق منه؟ وإيه الافتراضات اللي بيعتمد عليها؟
🔐 الـPlaylist بتبدأ من فهم تركيب الـJWT، وبعدها تنتقل إلى اختبار نقاط الضعف المختلفة عمليًا داخل بيئات تدريبية.
🔗 رابط الـPlaylist:
JWT Vulnerabilities Masterclass | شرح وحل جميع لابات JWT في PortSwigger Web Security Academy



3. Path Traversal​

Path Traversal من الثغرات القديمة، لكنها لسه ممكن تظهر في تطبيقات حديثة لما الـApplication تتعامل مع أسماء الملفات أو مساراتها بدون Validation مناسب.
الفكرة ببساطة إن التطبيق يكون عنده مسار أو اسم ملف جاي من المستخدم، وبعدها يستخدم القيمة دي للوصول إلى ملف.

لو مفيش تحكم مناسب، ممكن يحاول المستخدم يخرج من الـDirectory المفروض يكون محصور فيه، وبالتالي يوصل إلى ملفات خارج النطاق المسموح.
وده ممكن يؤدي إلى كشف ملفات إعدادات أو بيانات حساسة حسب صلاحيات التطبيق والبيئة الموجودة.

🧩 المهم في Path Traversal مش مجرد معرفة الفكرة، لكن فهم:
  • إزاي الـInput بيوصل لعملية قراءة الملف.
  • إيه الـValidation الموجودة.
  • هل فيه Normalization للـPath؟
  • هل الحماية بتتعامل مع الحالات غير المتوقعة؟
  • إيه النتيجة اللي ظهرت في الـResponse؟
🔗 رابط الـPlaylist:
Path traversal vulnerabilities | portswigger



4. Information Disclosure​

كتير من المبتدئين بيستهينوا بـInformation Disclosure لأن المعلومة اللي ظهرت ممكن تبدو بسيطة.
لكن أحيانًا المعلومة الصغيرة بتكون جزء من صورة أكبر.
مثلًا، Error Message ممكن تكشف:
  • نوع الـDatabase.
  • إصدار Server أو Framework.
  • مسار داخلي على النظام.
  • اسم ملف أو Endpoint.
  • تفاصيل عن طريقة تنفيذ Request معين.
وممكن تلاقي معلومة في HTML Source، Comment، JavaScript File أو Response Header تكشف Endpoint أو إعداد مهم.
المعلومة وحدها مش معناها إنك حصلت على اختراق، لكن ممكن تساعدك تفهم الـApplication بشكل أفضل وتحدد إيه اللي يستحق الاختبار بعد كده.
🔎 عشان كده الـPlaylist بتركز على البحث المنهجي عن المعلومات، والأهم من كده: إزاي تربط المعلومة اللي لقيتها بالخطوة التالية في الاختبار.
🔗 رابط الـPlaylist:
Information Disclosure | PortSwigger Academy



5. OS Command Injection​

OS Command Injection من الثغرات اللي ممكن تكون خطيرة جدًا، لأنها بتحصل لما Application تستخدم User Input بطريقة غير آمنة داخل أمر يتم تنفيذه على نظام التشغيل.
ممكن تلاقي مثلًا Application بتعمل وظيفة محتاجة تنفيذ أمر على السيرفر، زي أدوات معينة للتعامل مع الملفات أو الشبكات.
لو الـInput وصل لعملية تنفيذ الأمر بدون فصل آمن بين البيانات والأمر نفسه، ممكن يظهر Injection.
⚠️ هنا المشكلة مش في وجود Command Execution كوظيفة فقط، لكن في إدخال بيانات المستخدم في سياق أمر بطريقة تسمح بتغيير السلوك المقصود.

في الـPlaylist بتتعلم الفكرة من الأساس:
  • إزاي الـUser Input ممكن يوصل لتنفيذ Command.
  • إزاي تكتشف نقطة الإدخال.
  • إزاي تفرق بين Input عادي وInput بيتفسر كجزء من Command.
  • إزاي تختبر الحالة داخل بيئة تدريبية.
  • وإزاي تفهم تأثير الـFiltering بدل الاعتماد على تجربة عشوائية.
🔗 رابط الـPlaylist:
OS Command Injection | PortSwigger Walkthrough



6. Broken Access Control​

Broken Access Control من أهم موضوعات Web Security، لأنها مرتبطة بشكل مباشر بسؤال أساسي:
هل المستخدم مسموح له فعلًا يعمل العملية دي أو يشوف البيانات دي؟
المشكلة ممكن تظهر بأشكال مختلفة.
مثلًا، ممكن Application تعتمد على قيمة ID للوصول إلى Resource، لكن الـBackend لا يتحقق بشكل صحيح من إن المستخدم الحالي يملك صلاحية الوصول إلى الـResource ده.
وده ممكن يؤدي إلى حالات معروفة مثل IDOR.

وفي سيناريوهات تانية، ممكن تلاقي:
  • صفحة إدارية غير محمية بشكل صحيح.
  • Endpoint متاح لمستخدم لا يملك الصلاحية.
  • اختلاف بين الصلاحيات اللي الـUI بتعرضها والصلاحيات الفعلية على الـBackend.
  • إمكانية تنفيذ Action المفروض تكون مقيدة على Role معين.
🔐 لذلك فهم Broken Access Control محتاج إنك تفكر في الـAuthorization نفسها، مش مجرد شكل الواجهة.
الـPlaylist بتدخل في أنواع مختلفة من مشاكل الـAccess Control، من الحالات البسيطة لحد السيناريوهات اللي محتاجة فهم أكبر للـApplication Workflow.
🔗 رابط الـPlaylist:
PortSwigger Broken Access Control Labs



تجهيز بيئة العمل: Kali Linux وBurp Suite​

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



تجهيز Kali Linux 2026 على VirtualBox​

الفيديو بيشرح تجهيز Kali Linux 2026 على VirtualBox من البداية، بداية من تنزيل النظام، مرورًا بإعداد الـVirtual Machine، لحد ما يبقى عندك Environment جاهزة للاستخدام.
🔗 الفيديو:
Video thumbnail



إعداد Burp Suite Pro وFirefox​

Burp Suite من الأدوات الأساسية في اختبار Web Applications.
الفيديو بيشرح إعداد الـProxy وربط Burp Suite بمتصفح Firefox من خلال تثبيت الـCertificate، بحيث تقدر تشوف الـRequests والـResponses وتبدأ تختبر الـApplication داخل بيئة تدريبية.
🔗 الفيديو:
Video thumbnail



إيه الهدف الحقيقي من المشروع؟ 🎯​

الهدف مش إنك "تعرف" الثغرة وخلاص.
مش الهدف إنك تحفظ تعريف Business Logic Flaw أو JWT أو Path Traversal وتقدر تشرحه لو حد سألك.
الهدف الحقيقي هو إنك تفهم:
ليه الـVulnerability بتحصل من الأساس؟
ولما تدخل على Application جديدة، تعرف تسأل الأسئلة الصح.
إيه الـInput اللي يستحق الاختبار؟
إيه الـWorkflow اللي ممكن يكون فيه مشكلة؟
هل الـBackend بيتحقق من الصلاحيات؟
إيه المعلومات اللي الـApplication بتكشفها؟
إيه اللي حصل بعد تغيير الـRequest؟
وإيه الخطوة المنطقية اللي المفروض أجربها بعد كده؟
💡 مع الوقت، الطريقة دي في التفكير بتفرق جدًا بين شخص حافظ مجموعة Vulnerabilities وشخص بدأ فعلًا يكتسب خبرة في اختبار التطبيقات.



التطبيق قبل مواجهة الواقع​

لما تدخل Lab أو CTF، محدش هيحدد لك مكان الثغرة.
ومعظم الوقت مش هيقولك: "استخدم الـPayload ده هنا."
أنت المفروض تلاحظ السلوك، تعمل Hypothesis، تختبرها، تشوف النتيجة، وتعدل فكرتك بناءً على اللي حصل.
وده سبب مهم يخلي التدريب العملي مفيد.
لما تجرب Vulnerability بنفسك داخل بيئة آمنة، بتبدأ تكون عندك خبرة عملية تساعدك تفهمها لما تقابل Pattern مشابه بعد كده.

🧠 الهدف هو الانتقال من:
أعرف الثغرة ⬅️ أقدر أشرح الثغرة ⬅️ أقدر أكتشف الثغرة بنفسي.



المشروع لسه في البداية 🚀​

SilentN0va Offensive Security لسه بيتبني، والـSix Playlists الموجودة حاليًا مش هي نهاية المشروع.
الفكرة إن المحتوى يتوسع مع الوقت ليشمل Vulnerabilities إضافية، Playlists جديدة، Labs أكثر، وCheatsheets تكون مرجع سريع أثناء المذاكرة والتطبيق.
يعني المحتوى الموجود حاليًا هو بداية المشروع، وليس الشكل النهائي له.



لو فاتك الجزء الأول​

لو دي أول مرة تسمع عن SilentN0va، فممكن تبدأ بالجزء الأول من السلسلة عشان تاخد الصورة الكاملة عن المشروع، سبب إنشائه، والفكرة اللي مبني عليها.
بعد كده تقدر ترجع للـPlaylists وتبدأ بالموضوع الأقرب لمستواك واهتماماتك.



إزاي تقدر تساعد المشروع؟ ❤️​

لو شايف إن المحتوى ممكن يفيد شخص بيتعلم Cyber Security وواقف في نفس المرحلة، مشاركة المقال ممكن تساعده يوصل للمشروع.
وكمان تقدر تدخل على الـGitHub Repository وتعمل ⭐ Star للمشروع.
الخطوة بسيطة، لكنها بتساعد في زيادة وصول المشروع للناس المهتمة بالمحتوى العربي المجاني في مجال Offensive Security.

🔗 GitHub Repository:
SilentN0va Offensive Security



الخلاصة​

أكبر مشكلة في تعلم Cyber Security مش إنك مش قادر تحفظ Vulnerabilities أكثر.
المشكلة غالبًا إنك محتاج تربط اللي بتتعلمه باللي بتعمله بإيدك.
SilentN0va Offensive Security بيحاول يعالج الجزء ده من خلال محتوى عربي عملي يربط بين فهم الـConcept، تجهيز الأدوات، اختبار الـApplication، وتحليل النتيجة داخل بيئات تدريبية.

ولو أنت حاليًا في مرحلة:
"أنا فاهم الـTheory، بس أول ما أدخل Lab مش عارف أبدأ منين"
فده بالضبط النوع من الفجوة اللي المشروع بيحاول يساعدك تتخطاها.



الأسئلة الشائعة​

-------------

هل SilentN0va مناسب للمبتدئين؟​

مناسب للشخص اللي عنده أساسيات في Cyber Security وعايز ينقل معرفته من الجانب النظري للتطبيق العملي. ومن الأفضل إنك تبني الأساسيات المطلوبة لكل موضوع قبل الدخول في تفاصيل الـVulnerability.

هل المحتوى مجرد ترجمة لمحتوى أجنبي؟​

لا، فكرة المشروع هي تقديم محتوى عربي يركز على الفهم والتطبيق العملي، وليس مجرد ترجمة أو تجميع لمحتوى موجود في أماكن أخرى.

هل التدريب يتم على أنظمة حقيقية؟​

الهدف من المحتوى التدرب داخل Labs وCTFs وبيئات مخصصة للتعلم بشكل آمن. الاختبارات الأمنية يجب أن تتم فقط على الأنظمة التي تملك تصريحًا لاختبارها.

إيه الأدوات الأساسية الموجودة في المحتوى؟​

من الأدوات التي يتم تجهيزها واستخدامها Burp Suite وKali Linux، بالإضافة إلى الأدوات والبيئات المطلوبة حسب موضوع كل Playlist.

هل المشروع هيضيف محتوى جديد؟​

نعم، المشروع ما زال في مرحلة البناء، والخطة تتضمن إضافة Vulnerabilities وPlaylists وLabs وCheatsheets جديدة مع استمرار تطوير المحتوى.
 
التعديل الأخير:
مواضيع مشابهة
x32x01
الردود
0
المشاهدات
10
x32x01
x32x01
x32x01
الردود
0
المشاهدات
43
x32x01
x32x01
x32x01
الردود
0
المشاهدات
48
x32x01
x32x01
إحصائيات المنتدى
المواضيع
2,322
المشاركات
2,388
الأعضاء
16
آخر عضو مسجل
HcN57
عودة
أعلى