Abdullah Path

 يا جماعة، خلونا نغيّر الزاوية اليوم. المرة اللي فاتت تكلمنا عن منطق الأعمال. اليوم بنفتح شيء ثاني تمامًا، شيء كل واحد يستخدمه كل يوم، بس نادرًا جدًا يوقف ويفهمه بعمق. التخزين في المتصفح… الذاكرة العشوائية الحقيقية لتطبيقات الويب. كثير ناس يظنون إن الأمان كله على السيرفر. يقولون: "الـ 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 ثم تعود النت...