الأمان
كيف يعمل التحليل فعليًا؟
خط الأنابيب: التحقق من المدخل ← التطبيع (Normalization) ← التقنين (Canonicalization) ← فحص SSRF على المضيف المكتوب حرفيًا ← حلّ DNS حقيقي عبر DNS-over-HTTPS ← إعادة فحص SSRF على العناوين الفعلية الناتجة ← طلب HTTP حقيقي نحو الوجهة مع تتبّع أي تحويلات ضمن حدود صارمة ← محرك المخاطر ← النتيجة النهائية. هذا التحقق الحي يتم بالكامل على خادم (Cloudflare Worker) وليس من داخل متصفحك — لأن السماح للمتصفح بإجراء هذا النوع من الطلبات مباشرة غير آمن (SSRF).
حماية SSRF متعددة الطبقات
يُرفض أي رابط يشير صراحة إلى localhost أو نطاقات IP خاصة (10.x، 172.16-31.x، 192.168.x) أو
عناوين Link-local وMetadata مثل 169.254.169.254 — مرتين: أولاً على المضيف
كما كُتب، وثانيًا على عنوان IP الفعلي الناتج عن حل DNS حقيقي (وهو ما يمنع هجمات DNS Rebinding التي تعتمد على
الإبلاغ عن اسم نطاق بريء ثم تحويله لاحقًا لعنوان داخلي). نفس الفحص المزدوج يُطبَّق على كل قفزة
ضمن سلسلة أي تحويل (Redirect) — وليس فقط الرابط الأصلي.
القيد المتبقي الموثّق بأمانة
التحقق الحالي من DNS يتم قبل استدعاء طلب HTTP الفعلي مباشرة (وليس عبر إمساك اتصال Socket خام مثبَّت
على نفس العنوان المُتحقَّق منه). هذا يترك فجوة زمنية نظرية ضئيلة جدًا (TOCTOU) يمكن فيها لمهاجم متقدم جدًا أن
يغيّر إجابة DNS بين لحظة الفحص ولحظة الاتصال الفعلي. الحل الكامل لهذه الفجوة يتطلب فتح اتصال Socket خام
مثبَّت يدويًا على العنوان المُتحقَّق منه (متاح تقنيًا عبر واجهة cloudflare:sockets)، وهو أمر لم
يُنفَّذ في هذه النسخة لتعقيده العالي وصعوبة اختباره بثقة كافية دون بيئة تشغيل Cloudflare Workers حقيقية. هذا
القيد موثّق بالكامل في docs/threat-model.md.
حدود صارمة على كل طلب
- حد أقصى 5 تحويلات (Redirects) لكل فحص.
- مهلة زمنية 5 ثوانٍ لكل طلب فرعي، و12 ثانية كحد أقصى للفحص كاملاً.
- حد أقصى 2 ميجابايت لقراءة أي استجابة — تُقطع القراءة فور تجاوز الحد.
- مخططات مسموحة:
httpوhttpsفقط — حتى ضمن عناوين التحويل نفسها.
المخططات المرفوضة
يُرفض أي رابط لا يستخدم http أو https — مثل javascript: أو
data: أو file: — صراحةً قبل أي تحليل.