Abdullah Path

أساسيات الشبكات في الأمن السيبراني للمبتدئين اليوم بشرح لكم اهم الاشياء اللي تعلمتها في  منصه TryHackMe عن اساسيات الشيكات  هذه المواضيع تعتبر حجر الاساسي لاي شخص حسب ما تعلمته انا يبي يدخل مجال الامن السيبراني بجديه سوا كان هدفه اختبار الاختراق او امن تطبيقات او حتى الدفاع عن الشبكات انا بشوف ناس كثير تخطون اساسيات الشبكات ويطيرون مباشره على الادوات والثغرات بعدين يضيعون الحقيقه انك لو ما فهمت كيف الشبكه تشتغل راح تستخدم الادوات وانت ما تدري ايش بتسوي بالضبط عشان كذا  فاليوم انا جاي اعلمك من تجربه واقعيه ركز معي وش هي الشبكه ببساطه هي مجموعه اجهزه متصله ببعض عشان تتبادل البيانات ابسط مثال تعرفه جهازك الجوال او اللاب توب  متصله بالراوتر في البيت هذه شبكه محليه صغيره   اسمها  LAN (Local Area Network لو وسعنا الدائره شوي الانترنت كله عباره عن  الشبكه الضخمه جدا تربط ملايين الشبكات الصغيره مع بعض وهذه يسمونها  WAN  Wide Area Network كل جهاز على الشبكه لازم يكون له عنوان فريد تماما زي زي اللي في كل بيت له رقم عنوان بدون  عنوان الجهاز ما يقدر...

 **أمن تطبيقات الويب: الأساسيات اللي ما ينفع تتخطاها أبدًا** يا جماعة، خلونا نوقف شوي ونرجع للبداية بصدق. كثير ناس يدخلون مجال أمن تطبيقات الويب وهم متحمسين، يبون يروحون على طول لـ SQL Injection وXSS وBurp Suite والـ Payloadات، ويظنون إن هذا هو "الأمن". الحقيقة؟ هذي الطريقة تبني لك مهارات سطحية. تقدر تلاقي ثغرة، بس ما تفهم ليش صارت، ولا كيف تمنعها من الأساس، ولا كيف تفكر زي المهاجم الحقيقي. الأساسيات مو شيء "ممل" أو "للمبتدئين فقط". الأساسيات هي اللي تفصل بين واحد يضغط أزرار، وواحد يفهم النظام من جوه. اليوم راح نبني الأساس بقوة. مش مقدمة خفيفة، مقال طويل وواضح وعميق. --- ### أول شيء: وش هو تطبيق الويب أصلًا؟ تطبيق الويب مو بس صفحة تشوفها في المتصفح. هو نظام كامل يتكون من طبقات: - **المتصفح (Client)**: اللي يشتغل عند المستخدم. فيه HTML وCSS وJavaScript، وفيه ذاكرة (Cookies، LocalStorage، SessionStorage...). - **الشبكة**: الطلبات والاستجابات اللي تمشي بين المتصفح والخادم (HTTP/HTTPS). - **الخادم (Server)**: اللي يستقبل الطلب، يعالجه، ويتكلم مع قاعدة البيانات...

 يا جماعة، خلونا نغيّر الزاوية اليوم. المرة اللي فاتت تكلمنا عن منطق الأعمال. اليوم بنفتح شيء ثاني تمامًا، شيء كل واحد يستخدمه كل يوم، بس نادرًا جدًا يوقف ويفهمه بعمق. التخزين في المتصفح… الذاكرة العشوائية الحقيقية لتطبيقات الويب. كثير ناس يظنون إن الأمان كله على السيرفر. يقولون: "الـ Backend محمي، الـ Token صحيح، الـ IDOR مسكر… خلاص". بس هم ينسون إن جزء كبير من حالة التطبيق يعيش في المتصفح نفسه، زي ما الـ RAM تعيش فيها العمليات قبل ما تموت. الـ Cookies، الـ LocalStorage، الـ SessionStorage، الـ IndexedDB… هذي هي الذاكرة الحية للتطبيق. وفيها أسرار كثيرة تموت لو أعدت تحميل الصفحة، وفيها أسرار ثانية تبقى أيام وأسابيع. ليش هالنوع من "الذاكرة" خطير أكثر مما تتخيل؟ لأن المهاجم ما يحتاج يكسر السيرفر دائمًا. أحيانًا يكفي إنه يقرأ اللي موجود في ذاكرة المتصفح في اللحظة الصح. تخيل: الـ Access Token محطوط في LocalStorage. الـ Refresh Token في Cookie بدون HttpOnly. بيانات المستخدم الحساسة مخزنة في SessionStorage عشان "تجربة أفضل". أو حتى مفاتيح مؤقتة للتشفير متولدة في...

 يا جماعة، خلونا نتكلم بصراحة اليوم. في المقالين السابقين فضحنا الـ 7 أخطاء الكارثية في أمن الـ API وشرحنا كيف نصلحها خطوة بخطوة. كثير ناس قرأوا وطبقوا، وهذا كويس. لكن في شيء أكبر وأخطر ما يتكلم عنه أحد بصراحة، وحتى اللي يتكلمون عنه يمرون عليه مرور الكرام كأنه شيء نظري. اليوم بنفتح باب ما ينفتح بسهولة. اللي بيخلي أغلب الـ APIs تنهار مو الثغرات اللي يكتشفها السكانر، ولا الـ IDOR الكلاسيكي، ولا حتى غياب الـ Rate Limiting. اللي بيخليها تنهار هو أخطاء منطق الأعمال (Business Logic Flaws) اللي ما تظهر في أي أداة آلية، وما يقدر يكتشفها إلا إنسان فاهم كيف يشتغل النظام فعليًا. هذي الثغرات ما لها اسم جاهز في أغلب الأحيان، وما تطلع في تقرير OWASP Top 10 كبند واضح. بس هي اللي تسبب أكبر الخسائر المالية والسمعة في الواقع. ليش هالنوع من الثغرات خطير جدًا؟ لأنها مش تقنية. هي منطقية. السكانر ما يفهم إن "الطلب لازم يمر بثلاث مراحل قبل ما يتأكد"، أو إن "المبلغ لازم يكون أقل من رصيد الحساب في اللحظة دي"، أو إن "ما ينفع المستخدم يلغي الطلب بعد ما استلم المنتج". هذي أشياء بشرية...

 كيف تصلح الـ 7 أخطاء الكارثية في أمن واجهات API خطوة بخطوة (دليل عملي للمطورين) يا جماعة، في المقال السابق تكلمنا بصراحة عن 7 أخطاء كارثية في أمن الـ API اللي كثير من المطورين يقعون فيها يوميًا. قلنا إن إخفاء الزر ما يحمي شيء، وإن الـ Token الموجود ما يعني إن كل شيء آمن، وإن تغيير الـ ID ممكن يفتح باب كارثة، وإن المصادقة ما تغني عن الصلاحيات، وإن الاعتماد على الـ Frontend وحده كارثة، وإن نسيان الـ HTTP Methods خطير، وإن غياب الـ Rate Limiting يخلي الـ API مفتوح للتجربة بلا حدود. اليوم مو بس بنعيد الأخطاء. اليوم بنصلحها. خطوة بخطوة. بشكل عملي يقدر أي مطور يطبقه سواء كان يبني API جديد أو يراجع API موجود. الهدف إنك تطلع من المقال وعندك صورة واضحة: وش تسوي بالضبط عشان تمنع هالأخطاء من الأساس. 1. إصلاح خطأ «أنا أخفيت الزر، خلاص محمي» المشكلة: الأمان على الواجهة فقط. الحل خطوة بخطوة: كل Endpoint حساس (حذف، تعديل، عرض بيانات خاصة) لازم يمر بفحص صلاحيات على السيرفر قبل أي تنفيذ. استخدم Middleware أو Guard يفحص: هل المستخدم مسجل دخول؟ وهل عنده الصلاحية المطلوبة على هذا المورد بالذات؟ لا تع...

أخطاء الناس في أمن الـ API… والكوارث اللي تصير بسببها يا جماعة، خلونا نتكلم بصراحة اليوم. كثير ناس يظنون إنهم سووا أمن للتطبيق، بس الواقع إنهم سووا "وهم أمن". الـ API صارت أهم نقطة في أي تطبيق حديث، ومع ذلك الناس يسوون فيها أخطاء تضحك لو ما كانت خطيرة. خلونا نعدد أشهر الكوارث اللي أشوفها كل يوم: 1. "أنا أخفيت الزر، خلاص محمي" هذي من أكثر الأشياء اللي تخلي الواحد ينهار من الضحك. المطور يقول: "المستخدم العادي ما يشوف زر الحذف، يعني ما يقدر يحذف". طيب والـ Endpoint؟ DELETE /api/users/55 لو ما في فحص صلاحيات على السيرفر، أي واحد يقدر يرسل الطلب بنفسه. إخفاء الزر من الواجهة ما يحمي شيء. الأمان الحقيقي يكون على السيرفر، مو على واجهة المستخدم. 2. "الـ Token موجود، خلاص آمن" كثير يرسلون الـ Token في الـ Header ويظنون إن الموضوع خلص. بس ما يتحققون: هل الـ Token منتهي الصلاحية؟ هل يقدرون يستخدمون نفس الـ Token بعد ما يسجلون خروج؟ هل الـ Token فيه صلاحيات أكثر من اللي يحتاجها المستخدم؟ وفي ناس أسوأ من كذا: يحطون الـ API Key أو الـ Secret داخل ملفات JavaScri...

  أمن تطبيقات الويب 5: API Security وكيف تختبر واجهات برمجة التطبيقات في الأجزاء السابقة من سلسلة أمن تطبيقات الويب تعرّفنا على أساسيات حماية تطبيقات الويب، وكيف تحدث بعض الهجمات والثغرات الشائعة. لكن أغلب التطبيقات الحديثة لم تعد تعتمد فقط على صفحات الويب التقليدية؛ بل أصبحت تعتمد بشكل كبير على واجهات برمجة التطبيقات API للتواصل بين الموقع والتطبيقات وقواعد البيانات والخدمات المختلفة. وهنا تظهر مشكلة مهمة: «قد يكون الموقع محميًا بشكل جيد، لكن الـ API الموجود خلفه يحتوي على ثغرة خطيرة.» لذلك في هذا الجزء سنتعرف على API Security وكيف يمكن فحص واجهات API بطريقة آمنة وقانونية. --- 🔹 ما هي API؟ API اختصار لـ Application Programming Interface، وهي الواجهة التي تسمح للبرامج المختلفة بالتواصل مع بعضها. على سبيل المثال، عندما تفتح تطبيقًا على هاتفك وتطلب بيانات حسابك، قد يرسل التطبيق طلبًا إلى API مثل: GET /api/user/profile ويرجع الخادم استجابة تحتوي على البيانات: {   "id": 1024,   "username": "abdullah",   "role": "user" } المستخدم لا يرى هذه...

 في الجزئين السابقين تعرفنا على المفاهيم الأساسية وكيف تحدث الثغرات وكيف يفكر مختبر الاختراق. اليوم ندخل في الجزء العملي الأهم: كيف تحلل التطبيق وترسم خريطته بطريقة منهجية تجعلك تشوف ما لا يراه المطور ولا حتى فريق الأمن أحيانًا. كثير من الناس يظنون إن اختبار الاختراق = تشغيل أدوات جاهزة. الحقيقة إن الأدوات مجرد مساعد. الفرق الحقيقي بين المبتدئ والمحترف هو الخريطة. لماذا رسم خريطة التطبيق أهم خطوة؟ بدون خريطة واضحة أنت زي اللي يمشي في مدينة كبيرة بدون خريطة. ممكن تلاقي شارع هنا وثغرة هناك، لكنك مش هتشوف الصورة الكاملة، ومش هتعرف فين النقاط الحساسة اللي لو سقطت هتقع المنظومة كلها. الخريطة الجيدة توضح لك: نقاط الدخول (Entry Points) التدفقات الحساسة (Sensitive Flows) العلاقات بين المكونات البيانات اللي بتنتقل وأين تُخزن الأسطح الهجومية (Attack Surfaces) المنهجية العملية لرسم خريطة التطبيق جمع المعلومات الأولي (Reconnaissance) ابدأ من الخارج: النطاقات الفرعية، ملفات robots.txt وsitemap، رؤوس الـ HTTP، التقنيات المستخدمة (Wappalyzer أو BuiltWith)، أي واجهات API مكشوفة. تحديد نقاط الدخول ...

 أمن تطبيقات الويب: منهجية عملية لتحليل التطبيق ورسم الخريطة – الجزء الثالث في الجزئين السابقين تعرّفنا على المفاهيم الأساسية، وكيف تحدث الثغرات، وكيف يفكر مختبر الاختراق. الآن ننتقل من النظرية إلى الممارسة. هذا الجزء مخصص لمن يريد أن يتعلم كيف يبدأ اختبار تطبيق ويب بطريقة منظمة داخل بيئة تدريبية (مثل المختبرات التعليمية أو CTF أو الأنظمة التي تملك تصريحًا باختبارها). الهدف ليس «البحث العشوائي عن ثغرات»، بل بناء صورة واضحة عن التطبيق قبل أن تبدأ في محاولة كسره. لماذا رسم الخريطة أهم من اكتشاف الثغرة؟ كثير من المبتدئين يفتحون Burp Suite أو ZAP ويبدأون فورًا في إرسال Payloads. النتيجة غالبًا تكون: ضياع وقت، وفوات نقاط مهمة، وعدم فهم حقيقي للتطبيق. المختبر المحترف يفعل العكس: يجمع المعلومات. يرسم خريطة كاملة قدر الإمكان. يفهم التدفق الطبيعي للبيانات والصلاحيات. ثم يبدأ في الاختبار. بدون خريطة واضحة، أنت تختبر في الظلام. المرحلة الأولى: Reconnaissance (جمع المعلومات المسموح بها) ابدأ دائمًا بما يمكنك رؤيته دون أي تفاعل عدائي: افتح الموقع كمستخدم عادي. سجّل حسابًا إن أمكن. تصفح كل الصفح...

  أمن تطبيقات الويب: كيف تحدث الثغرات وكيف يفكر مختبر الاختراق؟ | الجزء الثاني في الجزء الأول من سلسلة أمن تطبيقات الويب تعرّفنا على الأساسيات والمفاهيم التي يحتاجها أي شخص يريد دخول عالم Web Application Security. أما الآن، فسنبدأ بالدخول إلى المنطقة التي تصبح فيها الصورة أكثر وضوحًا. تطبيق الويب ليس مجرد صفحة تراها في المتصفح. خلف زر تسجيل الدخول، وخلف نموذج البحث، وخلف كل طلب HTTP، توجد مجموعة من العمليات التي تتعامل مع البيانات، الجلسات، الحسابات، قواعد البيانات والصلاحيات. وأي خطأ صغير في واحدة من هذه الطبقات قد يتحول إلى ثغرة أمنية حقيقية. «ملاحظة: الأمثلة والمفاهيم في هذا المقال مخصصة للتعلم والاختبار داخل بيئات تملك تصريحًا لاختبارها، مثل المختبرات التعليمية وCTF والأنظمة التي تملكها.» --- ما الذي يحدث عندما تستخدم تطبيق ويب؟ عندما تفتح موقعًا وتضغط على زر أو ترسل نموذجًا، لا يحدث الأمر بطريقة سحرية. المتصفح يرسل طلبًا إلى الخادم، والخادم يعالج الطلب ثم يعيد استجابة. يمكن تبسيط العملية هكذا: المستخدم → المتصفح → HTTP Request → Web Server → Application → Database ثم تعود النت...

 مرحباً بك في سلسلة أمن تطبيقات الويب. هذه السلسلة ليست مجرد مقالات نظرية، بل مسار عملي مبني على الواقع. هدفها إنك تفهم كيف تُهاجَم تطبيقات الويب، وكيف تكتشف الثغرات، وكيف تحميها باحتراف. اليوم، أغلب المواقع والتطبيقات معرضة للخطر. ثغرة واحدة صغيرة ممكن تسبب تسريب بيانات آلاف المستخدمين، أو اختراق كامل للنظام. واللي يفرق بين موقع محمي وموقع ضعيف هو المعرفة العملية، مو الشهادات ولا العناوين الكبيرة. في هذه السلسلة راح نبدأ من الصفر، ونمشي خطوة بخطوة حتى نصل إلى مستوى احترافي في اختبار الاختراق وأمن التطبيقات. وش راح تتعلم في السلسلة؟ فهم أساسيات أمن تطبيقات الويب بشكل عميق اكتشاف أشهر الثغرات حسب قائمة OWASP Top 10 كيف تعمل هجمات مثل SQL Injection و XSS و CSRF و Broken Access Control استخدام أدوات احترافية مثل Burp Suite و OWASP ZAP و SQLMap و Nmap تحليل الطلبات والاستجابات (HTTP Request & Response) كتابة تقارير احترافية بعد اكتشاف الثغرات بناء عقلية المهاجم والمدافع في نفس الوقت الهدف مو بس إنك تحفظ أسماء الثغرات، الهدف إنك تقدر تشوف الثغرة بعينك، وتستغلها، وبعدين تعرف كيف تصلح...

 داخل Windows: كيف يفكر المحترف عندما يريد أن يفهم ما يحدث خلف الشاشة؟ معظم مستخدمي Windows يتعاملون مع النظام من الخارج. يفتح البرنامج، يستخدم المتصفح، يحذف ملفًا، يثبت تطبيقًا، ثم يغلق الجهاز. لكن خلف هذه الواجهة البسيطة توجد طبقات كاملة تعمل في الخلفية في كل ثانية: عمليات، خدمات، ملفات، صلاحيات، اتصالات شبكية، سجلات أحداث، ومكونات للنظام تتعاون مع بعضها البعض. وهنا يبدأ الفرق الحقيقي. المستخدم يسأل: ماذا حدث؟ أما الشخص الذي يفكر بعقلية أمنية فيسأل: «لماذا حدث؟ ومن الذي سببه؟ ومتى بدأ؟ وماذا فعل بعد ذلك؟» وهذا هو الهدف من هذا المقال. لن نتعامل مع Windows كواجهة رسومية فقط، بل سنحاول النظر إليه كمنظومة يمكن مراقبتها وتحليلها وفهم سلوكها. --- 1. أول تغيير في طريقة التفكير إذا رأيت برنامجًا يستهلك نسبة عالية من المعالج، فليس من المنطقي أن تقول مباشرة: "هذا فيروس." وإذا رأيت اتصالًا بالإنترنت، فهذا لا يعني تلقائيًا أن الجهاز مخترق. وإذا وجدت عملية باسم غريب، فهذا لا يعني أنها خبيثة. المحترف لا يبدأ بالحكم. يبدأ بجمع الأدلة. فبدلًا من: عملية غريبة → فيروس يصبح التفكير: عملية غري...

 Nmap من الداخل: كيف يفكر ماسح الشبكات؟ دليل متقدم لفهم فحص المنافذ وتحليل النتائج إذا كنت تستخدم Nmap فقط بهذه الطريقة: nmap 192.168.1.10 ثم تنظر إلى كلمة "open" وتنتقل إلى الأمر التالي، فأنت تستخدم جزءًا صغيرًا جدًا من قوة الأداة. Nmap ليس مجرد برنامج يبحث عن المنافذ المفتوحة. إنه نظام كامل لجمع الأدلة من الشبكة، يبدأ بسؤال بسيط: «هل يوجد جهاز أصلًا؟» ثم ينتقل إلى: «ما المنافذ التي يمكن الوصول إليها؟» ثم: «ما الخدمة التي تعمل خلف هذا المنفذ؟» ثم: «ما إصدارها؟» ثم: «ما نظام التشغيل المحتمل؟» وأخيرًا يمكن أن يستخدم NSE لأتمتة مجموعة كبيرة من عمليات الاستطلاع والفحص. وهنا تبدأ المتعة الحقيقية. --- 1. Nmap لا يرى "المنفذ" مباشرة هذه نقطة مهمة جدًا. عندما يقول Nmap: 80/tcp open فهو لا ينظر داخل جهاز الهدف ويرى أن المنفذ 80 مفتوح. Nmap يستنتج حالة المنفذ من الردود الشبكية التي يحصل عليها. المنفذ في عالم Nmap ليس مجرد رقم؛ بل هو نتيجة لتفاعل بين: - جهاز المصدر - جهاز الهدف - البروتوكول - الخدمة - الجدار الناري - الشبكة بين الطرفين - نوع الـProbe المستخدم - وطريقة استجابة...