Crusader Research

الفوز بثغرات حالة السباق في الويب باستخدام single-packet attack

Sun, 05 Jul 2026 00:00:00 +0000

معظم الشروحات تخبرك أن race condition هي “نافذة زمنية بين الفحص والاستخدام”. صحيح، لكنه عديم الفائدة — لأن سبب فشل هجمات السباق لديك ليس أنك لا تفهم المفهوم. السبب أن النافذة أصغر مما هي عليه دقة الإنترنت.

نافذة السباق النموذجية — الفجوة بين قراءة التطبيق لـbalance وكتابته لـbalance - amount — تُقاس بـالميكروثواني إلى بضعة مللي ثوانٍ. أما التذبذب بين طلبَي HTTP تُرسلهما في اللحظة نفسها، بحلول وقت وصولهما وجدولتهما على الخادم، فيتراوح عادةً بين 1 و10 مللي ثوانٍ، وأسوأ عبر الإنترنت العام. فتصل طلباتك “المتزامنة” في صفٍ أنيقٍ صغير، ويعالجها الخادم واحدًا تلو الآخر، ويصمد الحد، فتستنتج أن نقطة النهاية آمنة. إنها ليست كذلك. أنت فقط خسرت السباق أمام التذبذب الشبكي قبل أن يكون للخادم رأي أصلًا.

القفز فوق الطابور: كيف تختطف أداة MCP مسمومة نموذجًا لم يُستدعَ قط

Sun, 05 Jul 2026 00:00:00 +0000

معظم مقالات أمن MCP تُخبرك بأن كل خادم هو “حدود ثقة جديدة”. صحيح، وعديم الفائدة — لأنه يجعلك تتخيل بابًا تختار أن تعبره. المشكلة الحقيقية أنك لا تفعل. تنطلق التعليمة الخطيرة لحظة اتصالك بالخادم، قبل أن تستدعي أي شيء. يُطلَق الهجوم عند لحظة المصافحة (handshake)، لا عند لحظة الاستدعاء.

إليك التفصيلة البروتوكولية التي تجعل MCP مختلفًا عن كل تكامل دقّقته من قبل. حين يتصل العميل، يستدعي tools/list فيُعيد الخادم اسم كل أداة، ومخطط إدخالها، ووصفًا description بلغة طبيعية. هذا الوصف لا يُعرض على النموذج حين تُستدعى الأداة — بل يُحمَّل في سياق النموذج فورًا، عند لحظة tools/list، كي يعرف النموذج أي الأدوات موجودة ومتى يلجأ إليها. الوصف موجود في المُوجّه (prompt) منذ أول رمز في المحادثة فصاعدًا.

تجاوز الفلاتر السهلة في SSRF: التباس محلّل الـ URL ونقطة نهاية بيانات التعريف

Sun, 05 Jul 2026 00:00:00 +0000

تزوير الطلب من جانب الخادم (SSRF) هو أحد أصناف الثغرات القليلة التي تسلّمك فيها ثغرة واحدة بيانات اعتماد سحابية. الآلية تافهة في وصفها — تجعل الخادم يجلب URL تتحكم فيه — وكل شرح يتوقف عند هذا الحد، وهذا بالضبط سبب عدم جدواها. الحمولة التعليمية، http://169.254.169.254/ الملصقة في حقل URL، محجوبة في كل مكان بقوائم الحظر. السبب في أن SSRF لا يزال أحد أكثر أصناف الثغرات إنتاجية في 2026 ليس أن المطوّرين نسوا الفلترة. بل هو أن الفلتر الخاص بهم وعميل الـ HTTP لديهم يقرآن الـ URL بطريقتين مختلفتين، وأنت تعيش في تلك الفجوة.

‏IDOR يسكن في المعرّف الثاني: العثور على BOLA عبر Shadow Replay بحسابين

Sat, 04 Jul 2026 00:00:00 +0000

كل دليل تعليمي عن IDOR يسلّمك التمرين نفسه: اعثر على /api/orders/48210، وغيّره إلى 48211، وابحث عن 200. هذا التمرين يدرّبك على مهاجمة المعرّف الوحيد الذي يُرجَّح أن يتحقق منه التطبيق. المفتاح الأساسي في مسار الـ URL هو حيث تعيش تعليقة @authorize التي يضعها إطار العمل، وحيث تُحصر استعلامات الـ ORM، وحيث تركّزت المراجعة. إنه الطُّعم. تعبث به، وتحصل على استجابات 403، وتصف النقطة بأنها آمنة، وتمرّ بجوار الثغرة مباشرةً.

لأن الثغرة تكاد لا تكون أبدًا في الـ ID الذي تراه. إنها في المعرّف الثاني — ذاك الذي نسي التطبيق أنه معرّف من الأساس.

حقن الأوامر النصية غير المباشر هو SSRF في عصر الوكلاء

Fri, 03 Jul 2026 00:00:00 +0000

معظم المقالات تخبرك أن حقن الأوامر النصية هو «حين يتّبع النموذج تعليمات موجودة في مدخلاته». صحيح، وعديم الفائدة — لأن هذا التأطير يجعله يبدو كنزوة في روبوت محادثة تُرقّعها بـ system prompt أفضل. لكنه ليس كذلك. إنه ثغرة معمارية تعرفها بالفعل باسم آخر.

حدث SSRF لأن الخادم كان يجلب URL تتحكم أنت فيه ويثق بالـ response. ويحدث حقن الأوامر النصية غير المباشر لأن الـ agent يقرأ محتوًى تتحكم أنت فيه — صفحة ويب، أو PDF، أو بريدًا إلكترونيًا، أو دعوة تقويم — ويثق به كـ تعليمات. الخلل نفسه، وسيط جديد. صار الجلب من جانب الخادم قراءةً من جانب النموذج؛ وصار الـ response الموثوق أمرًا موثوقًا.