TechCamp Solutions

ليه الـ Firewalls وأدوات الـ Scanners التلقائية مش هتحميك لو عندك ثغرة Race Condition في الـ Backend بتاعك؟ 💣
(قصة ثغرة برمجية ممكن تكلّف أي شركة FinTech ملايين في ثواني!) 👇

تخيل معايا إن عندنا تطبيق بنكي (أو محفظة إلكترونية)، يوزر عنده في رصيده 100 جنيه بس، وعايز يسحبهم.

الـ Logic الطبيعي اللي أي مبرمج بيكتبه بيكون كالتالي:
1️⃣ السيرفر بيشيك (Check): هل رصيد اليوزر أكبر من أو يساوي 100؟

2️⃣ لو الإجابة أيوة، بيطلع فلوس للمستخدم.

3️⃣ السيرفر بيحدث الداتابيز (Update) ويخصم الـ 100 جنيه، ويبقى الرصيد صفر.

الكود ده شغال ومفيهوش أي Error.. صح؟

خطأ كارثي! 🚨
هنا بيجي دور الـ Attacker. لو الهكر استخدم أداة زي (Burp Suite Intruder) وبعت 10 طلبات سحب (Requests) في نفس الميكرو-ثانية!

اللي بيحصل في السيرفر هو الـ "Race Condition" (حالة سباق):
السيرفر بيستقبل الـ 10 طلبات مع بعض في نفس اللحظة.. بيدخلهم على خطوة رقم (1).. بيلاقي الرصيد 100 جنيه (لأن مفيش ولا طلب لحق يوصل لخطوة 3 ويخصم الرصيد لسه!).
النتيجة؟ السيرفر بيوافق على الـ 10 عمليات، والهكر بيسحب 1000 جنيه وهو أصلاً معندوش غير 100! 🤯💸

🛠️ إزاي نقفل الثغرة دي هندسياً؟ (The Fix)
المشكلة دي حلها مش في الـ Security Tools، حلها في الـ Architecture والداتابيز:

✔️ الحل الأول (Pessimistic Locking):
استخدام الـ Transactions مع (SELECT ... FOR UPDATE). الفكرة هنا إن أول Request يدخل، بيعمل "قفل" (Lock) على الصف (Row) الخاص باليوزر في الداتابيز. أي طلبات تانية بتفضل "واقفة مستنية" لحد ما الطلب الأول يخلص تماماً ويخصم الرصيد.

✔️ الحل الثاني (Database Constraints):
إننا نحط شرط صارم في الداتابيز نفسها إن خانة الرصيد مستحيل تنزل تحت الصفر: CHECK (balance >= 0). وقتها الداتابيز هترفض أي عملية تخلي الرصيد بالسالب.
الـ Business Logic Vulnerabilities هي الكابوس الحقيقي لأي سيستم لأن مفيش أداة بتكتشفها أوتوماتيك بسهولة.

قولي يا هندسة: إيه الطريقة المفضلة ليك لقفل ثغرات الـ Concurrency؟ هل بتعتمد على الـ Database Locks، ولا بتفضل تستخدم Distributed Locks عن طريق Redis؟ شاركنا رأيك في الكومنتات! 👇💬
#برمجة

إزاي قدرت أعمل Account Takeover (استحواذ كامل على أي حساب) بتغيير رقم واحد بس في الـ Request؟ 🤯🔥

الأسبوع اللي فات، كنت بعمل اختبار اختراق (Pe*******on Testing) لتطبيق مالي (Fintech App) بيخدم آلاف المستخدمين. التطبيق كان متأمن كويس جداً، لحد ما وصلت لخاصية "تغيير كلمة المرور" (Password Reset).

عشان أغير الباسورد، التطبيق كان بيطلب مني الباسورد القديم والجديد. منطقي جداً، صح؟

لكن قررت أشغل Burp Suite وأعترض الطلب (Intercept the Request) عشان أشوف الـ API بيكلم السيرفر إزاي في الكواليس.

لقيت الـ Request رايح بالشكل ده:
{"user_id": "8475", "old_password": "MyOldPassword", "new_password": "NewStrongPassword"}

لفت انتباهي بارامتر الـ user_id. ليه التطبيق بيبعت الـ ID بتاعي في الـ Request طالما أنا مسجل دخول (Logged in)؟ 🤔
قررت أعمل اختبار بسيط لثغرة IDOR (Insecure Direct Object Reference).

1️⃣ عملت حساب تاني (Victim Account) وخدت الـ ID بتاعه (مثلاً: 8476).

2️⃣ رجعت للحساب الأول (Attacker Account)، وطلبت تغيير الباسورد.

3️⃣ في Burp Suite، غيّرت الـ user_id لـ 8476، وسبت الباسورد القديم والجديد زي ما هما.

4️⃣ عملت Forward للـ Request... والمفاجأة؟ السيرفر رد بـ 200 OK وتم تغيير باسورد الضحية بنجاح! 🚩

السيرفر كان بيثق في الـ Data اللي جاية من الـ Client-side بشكل أعمى، ومكانش بيعمل Validation هل الـ Session Token الحالي يخص الـ user_id المبعوت في الطلب ولا لأ!

الحل:
الـ Backend لازم يتجاهل أي user_id مبعوت في الـ Request، ويعتمد كلياً على استخراج الـ User ID من الـ Secure Session (زي الـ JWT Token) الموثقة في السيرفر.

غلطة برمجية بسيطة جداً (Trusting Client Input) كان ممكن تتسبب في كارثة تسريب بيانات مالية لآلاف العملاء!

قولي في الكومنتات: إيه أغرب وأمتع ثغرة IDOR قابلتك في شغلك أو في الـ Bug Bounty؟ وهل بتفضل تستخدم أدوات معينة لاكتشافها؟ 👇💬

#برمجة

الـ Developer الشاطر مش هو اللي بيخلص الـ Tasks بسرعة.. الـ Developer الشاطر هو اللي عارف الكود اللي جوه الـ node_modules أو الـ NuGet بتاعه فيه إيه! 📦⚠️
​تلاقي الـ Project شغال زي الفل، وفجأة يجيلك طلب: "احنا محتاجين Feature بتعمل الحوار الفلاني".
وبدل ما نكتبها، بنستسهل ونعمل:
npm install package-x
​والـ Feature بتشتغل في دقيقتين، والكل بيبقى مبسوط بـ الـ Speed to market. 🚀
​بس الحقيقة؟ 🤔
إنت مش منزّل الـ Package دي لوحدها.. إنت نزلت معاها شجرة كاملة من مكتبات تانية مبنية على مكتبات تانية إنت متعرفش عنها حاجة!
​الـ Attackers مابقوش يضيعوا وقتهم في كسر الـ Firewall بتاع شركتك الكبيرة.. هما بيروحوا لـ Package صغيرة مفتوحة المصدر (Open Source) بيستخدمها ملايين الـ Developers، ويحقنوا جواها Malicious Code. 🕵️‍♂️
​أول ما تعمل Update أو Deploy.. الـ Malware بيبقى جوه السيرفر بتاعك، وبيبدأ يسرب بيانات عملائك والـ Environment Secrets للـ Attacker وهو حاطط رجل على رجل.
​🛠️ الحل إيه عشان مانعيشش في رعب؟
1️⃣ بلاش استسهال: لو الـ Feature بسيطة ومحتاجة كام سطر كود، اكتبها بنفسك بدل ما تعتمد على Package كاملة مجهولة.
2️⃣ فحص دوري (SCA): شغل أدوات الـ Software Composition Analysis في الـ Pipeline بتاعتك عشان تقفش أي ثغرات أو مكتبات مسمومة قبل ما تطلع Production.
​الـ Application Security مش مجرد قفل على الباب الخارجي.. الـ Security بيبدأ من الأدوات والمكتبات اللي إنت بتبني بيها بيتك من جوه. 🧱
​❓ سؤال للـ Developers:
إيه أكتر Package نزلتها في مشروعك وحسيت إنها "Black Box" إنت مش فاهم شغال إزاي؟ شاركوني تحت في الكومنتات. 👇
​

لو قدامك خيار واحد بس كـ Developer: تشتغل ريموتلي بمرتب أقل، ولا في الشركة بمرتب أعلى؟

البوست ده هجومي شوية وموجه للشركات اللي فاكرة إن الـ Security عبارة عن تول بتطلع تقرير PDF.
​
​لو فاكر إن الـ Automated Vulnerability Scanners هتحميك.. فإنت بتشتري "وهم" برقم كبير! 💸❌

​شركات كتير بتدفع آلاف الدولارات في تولز تقيلة عشان تعمل Scan للمواقع والـ APIs بتاعتها، وأول ما التقرير يطلع "Zero Vulnerabilities" باللون الأخضر، الـ Management بتنام وتطمن.

​بس في الحقيقة، الـ Scanner ده أعمى قدام الـ Business Logic Flaws.. الحاجات اللي محتاجة مخ بشري يفكر فيها ويكسرها. 🧠

​الـ Scanner مستحيل يفهم السيناريو ده:
🛑 إنت عندك موقع تجارة إلكترونية.. المشتري دخل يشتري منتج تمنه 1000$، وفي الـ Request بتاع الدفع، غير الـ Quantity لـ (1-) والسعر الإجمالي بقى بالسالب.. السيرفر قبل الـ Request وشحن المنتج، ورجع فلوس لحساب العميل!
​الـ Scanner هيشوف الـ Request راجع بـ 200 OK وهيعديها كأنها فل الفل.. لكن الـ Hacker البشري هيخرب بيت الشركة في دقيقة.

​الأدوات ممتازة في صيد الثغرات التقليدية السريعة، بس الـ Pentesters الشاطرين عارفين إن الثغرات الحقيقية اللي بتعمل Data Breaches بتيجي من فهم الـ Flow وسوء إدارة الصلاحيات (Access Control).

​الـ Automation بيوفر وقت.. بس العقل البشري هو اللي بيحمي. 🛡️

​❓ شاركوني: إيه أغرب ثغرة Business Logic قفشتوها أو سمعتوا عنها والـ Scanners مكنتش شايفاها؟ 👇
​

فيه برضه تريند شغال في الـ Web Development.. 🖥️
​أول ما الـ Team يخلص الـ Features الكبيرة، وقبل الـ Release بكام يوم، تلاقي الـ Manager بيقول:
"يا جماعة احنا محتاجين نعمل Pentest على الـ Web App والـ APIs قبل ما نطلع لايف".

​وتتحول العملية لـ "Checklist" أو خانة عايزين نعلم عليها عشان نرضي الـ Management أو الـ Compliance.

​بس الحقيقة؟ 🤔
الـ Web Application Pentesting مش مجرد خطوة بتتعمل في آخر الـ Project.
​وإنك تجيب Pentester في آخر ٥ أيام، ده أشبه باللي بيبني عمارة ويفتكر يحط حديد تسليح بعد ما صب الخرسانة! 🧱

​الـ Web Apps مابقتش زي زمان؛ المواقع بقت معقدة، شاشات الـ Frontend بتكلم عشرات الـ APIs، والـ Business Logic بقى متشابك جداً.

​الـ Script Kiddie حافظ كام ثغرة من الـ OWASP Top 10 زي الـ SQL Injection أو الـ XSS، وبيعتمد على الـ Automated Scanners عشان تجيبهم.

​لكن الـ Web Pentester المحترف عارف إن الـ Scanners دي "عمياء" قدام الكوارث الحقيقية في الـ Production، زي:
​🛑 BOLA / IDOR: (تعديل الـ ID في الـ Request عشان تشوف بيانات مستخدم تاني).

​🛑 Mass Assignment: (تبعت Field زي is_admin: true في الـ Register request والسيرفر يقبله عمياني).

​🛑 Broken Rate Limiting: (تخطي حماية الـ API عشان تعمل Brute-force أو تستهلك الـ Resources).

​الأدوات مش هتفهم الـ Logic بتاع الـ Application بتاعك.. البني آدم هو اللي بيفهمه ويكسره. 🧠

​💡 المعضلة: الـ Pentest التقليدي بيعطّل الـ Agility
​في عصر الـ DevOps، الـ Teams بتعمل Deploy لكود جديد كذا مرة في اليوم أو الأسبوع.

​لو اعتمدت على الـ Pentest التقليدي: هتجيب شركة برة كل 6 شهور تعمل فحص. التقرير هيطلع فيه 50 ثغرة، الـ Developers هيكونوا نسوا اصلاً هما كتبوا الكود ده إزاي، وتعطيل الشغل يبدأ هنا.

​الحل؟ إننا ننقل الـ Security من فكرة "البوابة اللي بتعطلنا في الآخر" لـ فكرة "الـ Pipeline الشغالة معانا" = DevSecOps. 🔄
​🛠️ إزاي الـ Web Pentesting بيتكامل مع الـ DevSecOps Pipeline؟

​المهندس الشاطر بيقسم الـ Security Tests لـ مستويات جوه الـ CI/CD Pipeline، بناءً على السرعة والعمق (Shift Left Security):
​1️⃣ الـ Automated Automation (في كل Commit)
​الـ SAST & Secret Scanning: تولز بتفحص الكود وهو مكتوب للتأكد إن مفيش Password مكتوبة بالغلط.
​الـ SCA (Software Composition Analysis): فحص الـ dependencies للتأكد إن الـ Third-party packages مفيش فيها ثغرات معروفة.
(ودي حاجات سريعة بتشتغل في دقائق مع كل PR او Git Push).

​2️⃣ الـ Dynamic Automation (في الـ Staging/QA)
​الـ DAST: أول ما الكود يترفع على سيرفر الـ Staging، بتبدأ تولز تعمل Automated Scans سريعة على الـ Endpoints المفتوحة عشان تصيد الثغرات الظاهرة.

​3️⃣ الـ Human-Led Pentesting (الـ Continuous Pentesting)
بعد ما الـ Automation ينضف الكود من الثغرات العبيطة.. هنا يجي دور الـ Pentester البشري. 🎯

​بدل ما يضيع وقته في تدوير على نسخة قديمة من مكتبة معينة، هو بيدخل على سيستم "نضيف تقنياً"، ويبدأ يركز كل مجهوده وذكائه في الـ Business Logic Flaws والـ Chaining Vulnerabilities.

​📢 الخلاصة: الـ Security مش فرامل.. الـ Security حزام أمان
​الـ DevSecOps مش جاي يلغي الـ Pentester، وجاي يقول إن الـ Automation لوحده مش كفاية. هو جاي يوفر وقت الـ Pentester للحاجات المعقدة اللي محتاجة تفكير، ويضمن إن الثغرات الواضحة بتتصلح وهي لسه في الـ Development stage.

​المهندس الشاطر مش اللي بيصلح الثغرة بعد ما السيستم يتفضح.. المهندس الشاطر هو اللي بيبني Pipeline تمنع الثغرة من إنها تشوف الـ Production أصلاً.

​❓ سؤال للـ Developers والـ Security Engineers:
الـ Security عندكم في الشركات بيبدأ من أول الـ Design والـ Pipeline، ولا لسه "Checklist" بتتعمل قبل الـ Deploy بيومين؟ شاركوني تجاربكم في الكومنتات. 👇
​