[ مقال تقني ]•الاستضافة الذاتية والمصادر المفتوحة•

٦ سبتمبر ٢٠٢٦

•٧ دقائق قراءة

أرشفة File Browser رسمياً: ثغرات أمنية غير مصلحة ومسارات الهجرة للأنظمة الذاتية

نهاية حقبة: أرشفة مستودع File Browser وتراكم الديون الأمنية

في الأول من سبتمبر 2026، قام المطور والمؤسس إنريكي دياس (Henrique Dias) بنقل مستودع filebrowser/filebrowser رسمياً إلى وضع القراءة فقط والأرشفة على GitHub. بعد مسيرة امتدت لعشر سنوات حصد خلالها أكثر من 35,900 نجمة وملايين التنزيلات عبر منصة دوكر، كان File Browser الخيار الافتراضي لإدارة الملفات عبر المتصفح في الخوادم المنزلية والمصغرة. واليوم أصبح هذا القرار نهائياً، حيث أعلن الفريق المطور إيقاف كافة التحديثات البرمجية، وتجميد معالجة الأخطاء، وعدم إصدار أي تصحيحات أمنية مستقبلية.

يحمل هذا التوقف تداعيات تشغيلية مباشرة لمديري الأنظمة ومهندسي البنية التحتية. فعلى عكس المشاريع التي تتقاعد بعد استقرار بنيتها واكتمال نضجها، يتقاعد File Browser حاملاً مشكلتين بنيويتين موثقتين في سجل التتبع الخاص بالمستودع. وتشغيل هذه المنصة دون تطبيق تدابير احترازية صارمة يترك الخوادم الذاتية عرضة للاختراق وتصعيد الصلاحيات.

دوافع الأرشفة

انطلق File Browser في بدايته كملف تنفيذي بسيط مكتوب بلغة Go بهدف تصفح المجلدات وتحرير الملفات وتنزيلها عبر واجهة ويب خفيفة، بعيداً عن التعقيد واستهلاك الموارد الذي تفرضه منصات كبرى مثل Nextcloud. ومع مرور السنوات، توسع المشروع لدعم إدارة المستخدمين والصلاحيات، وتشغيل الأوامر الخلفية، وتخصيص الواجهات.

أوضح إنريكي دياس أسباب قراره في مقال تحليلي مفصل في يوليو 2026 بعنوان “وداعاً File Browser، هذه المرة نهائياً”، وتلاه الإغلاق الرسمي للمستودع في مطلع سبتمبر. تركزت الأسباب في تزايد أعباء الصيانة التطوعية، وتدفق التنبيهات الأمنية المتكررة للحزم التابعة، وتشتت الجهد في الحفاظ على التوافق الرجعي مع وسائط التخزين المتنوعة. ومع غياب كيان تجاري أو مؤسسة مفتوحة ترعى المشروع، فضل المطورون أرشفته بدلاً من تسليم مفاتيح التحكم لمساهمين غير موثوقين.

ثغرتان بنيويتان لا يمكن إصلاحهما رسمياً

يوضح ملف الأمان الرسمي وتنبيهات المستودع ثغرتين رئيسيتين لن تصدر لهما أي تحديثات رسمية:

الطلب القادم (Incoming Request)
       |
       v
+-----------------------+     رموز JWT عديمة الحالة      +-----------------------+
|   الوسيط العكسي       | ----------------------------> |       File Browser    |
|   (تشفير TLS / مصادقة)|    غياب جدول الإبطال للخادم   | الرمز سارٍ حتى انتهائه |
+-----------------------+                               +-----------------------+
                                                                    |
                                                         --disable-exec=false
                                                                    v
                                                        +-----------------------+
                                                        | تنفيذ أوامر عشوائي    |
                                                        | اختراق صلاحيات الخادم  |
                                                        +-----------------------+

1. رموز مصادقة JWT عديمة الحالة تفتقر لآلية الإبطال (المسألة رقم 5216)

تعتمد المنصة في المصادقة على رموز JSON Web Tokens (JWT) المشفرة محلياً بواسطة مفتاح سري خاص بالخادم. غير أن نواة النظام لا تحتوي على أي جدول لتتبع الرموز الملغاة (Token Revocation List) أو سجل للجلسات النشطة في قاعدة البيانات.

يترتب على هذا الخلل المعماري نتائج أمنية خطيرة:

تغيير كلمة المرور لا ينهي الجلسات القديمة: إذا قام المستخدم بتغيير كلمة المرور أو قام المشرف بتعديل بيانات الحساب، تظل كافة الرموز الصادرة مسبقاً صالحة وقابلة للاستخدام حتى ينتهي تاريخ صلاحيتها الزمني.
تسجيل الخروج ينفذ في المتصفح فقط: النقر على زر “تسجيل الخروج” في الواجهة يمسح الرمز من التخزين المحلي للمتصفح فقط، بينما يبقى التوقيع الرقمي للرمز صحيحاً ومقبولاً لدى الخادم، مما يمكن أي مهاجم اعترض الرمز من إعادة استخدامه.
إعادة استخدام رموز التحديث بلا قيود: يمكن إرسال رموز التحديث (Refresh Tokens) للحصول على رموز مصادقة جديدة دون تحقق الخادم من إلغاء الجلسة السابقة.

في بنية لا تستخدم خادماً مركزياً لقواعد البيانات، تتطلب معالجة هذا الأمر إما ذاكرة مشتركة مؤقتة أو عمليات كتابة متكررة على SQLite مع كل طلب، وهو ما قرر الفريق عدم تنفيذه قبل إغلاق المشروع.

2. مخاطر مشغل الأوامر والتنفيذ العشوائي (المسألة رقم 5199)

تتيح المنصة خاصية اختيارية تسمى مشغل الأوامر (Command Runner)، هدفها السماح للمشرفين بتشغيل نصوص برمجية على الخادم (مثل فك ضغط الملفات أو تحديث الفهارس) مباشرة من واجهة الويب.

على مدار عدة تحديثات سابقة، تعرضت هذه الوظيفة لثغرات حقن أوامر وتجاوز مسارات متكررة. ورغم أن الخيار الافتراضي هو تعطيل الخاصية (--disable-exec=true)، إلا أن تفعيلها (--disable-exec=false) يمنح أي مستخدم يملك صلاحية التنفيذ قدرة كاملة على تشغيل أوامر برمجية عشوائية بصلاحيات المستخدم الذي يدير الحاوية. وفي معظم بيئات الاستضافة المنزلية التي تشغل الحاويات بصلاحيات الجذر (Root)، يعني ذلك السيطرة الكاملة على نظام التشغيل المضيف.

أكد المطورون أن تأمين هذه الخاصية يتطلب إعادة كتابة معمارية شاملة وعزل العمليات في بيئة تشغيل آمنة، ولن يحصل هذا التعديل بعد اليوم.

استراتيجية الحماية للبيئات القائمة

إذا تعذر عليك استبدال File Browser فوراً في بيئتك التشغيلية، يجب اتخاذ الإجراءات الدفاعية التالية لمنع اختراق الخادم:

1. فرض المصادقة الخارجية عبر الوسيط العكسي

لا تجعل منفذ File Browser مفتوحاً مباشرة على شبكة الإنترنت العامة إطلاقاً. ضع الحاوية خلف وسيط عكسي مؤمن مثل Traefik أو Nginx أو Caddy، وافرض طبقة مصادقة مسبقة تمنع وصول أي طلب قبل التحقق من هوية الزائر.

يمكن استخدام أنظمة التحقق مثل Authelia أو Authentik أو بوابات Cloudflare Zero Trust. وعندما تنفذ المصادقة عند بوابة الوسيط العكسي، لا تصل الطلبات المجهولة إلى معالج JWT الداخلي في File Browser.

2. تقييد صلاحيات الحاوية ومنع الكتابة

تأكد من عدم تشغيل الحاوية بصلاحيات الجذر ومنع ربط مقبس دوكر (/var/run/docker.sock). في ملف Docker Compose، اضبط الحاوية لتعمل بمستخدم محدود الصلاحيات واجعل نظام الملفات للقراءة فقط:

services:
  filebrowser:
    image: filebrowser/filebrowser:v2.32.0
    container_name: filebrowser
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
    volumes:
      - /srv/data:/srv/data:rw
      - /srv/filebrowser/config/settings.json:/etc/settings.json:ro
      - /srv/filebrowser/data/filebrowser.db:/filebrowser.db:rw
    environment:
      - FB_NOAUTH=false
    command:
      - "--disable-exec=true"
      - "--address=0.0.0.0"
      - "--port=8080"
      - "--database=/filebrowser.db"
      - "--root=/srv/data"
    restart: unless-stopped

تأكد دائماً من تمرير خيار --disable-exec=true صراحة ضمن سطر الأوامر لتجنب أي تفعيل غير مقصود.

البدائل مفتوحة المصدر الموصى بها للهجرة

تتوفر اليوم مشاريع مفتوحة المصدر نشطة تتبع أفضل الممارسات الأمنية وتوفر مسار انتقال سلس:

الميزة	File Browser (مؤرشف)	SFTPGo	Cloudreve	OwnCloud Infinite Scale
حالة الصيانة	متوقف (1 سبتمبر 2026)	نشط ومحدث (v2.6.x)	نشط ومحدث (v3.8.x)	نشط ومحدث (v5.x)
الرخصة البرمجية	Apache-2.0	AGPL-3.0	GPL-3.0	Apache-2.0
نظام المصادقة	JWT بدون إبطال	Argon2id، OIDC، LDAP	جلسات مؤمنة، MFA	بروتوكول OIDC الحديث
وسائط التخزين	القرص المحلي فقط	محلي، S3، Azure، SFTP	محلي، S3، WebDAV	محلي، محركات EOS
واجهة الويب	متوفرة وخفيفة	متوفرة حديثة ومتكاملة	متكاملة تشبه السحابة	واجهة ويب متطورة
استهلاك الذاكرة	منخفض جداً (~20MB)	منخفض (~45MB)	متوسط (~80MB)	متوسط (~120MB)

1. منصة SFTPGo (الخيار الأول الموصى به)

لمن يبحث عن بديل مباشر يقدم كفاءة لغة Go وخفة الاستهلاك مع ربط المجلدات المحلية، يعد SFTPGo البديل الأقوى. يقدم المشروع لوحة تحكم إدارية وواجهة ويب للمستخدمين، ويدعم بروتوكولات SFTP وWebDAV وFTP وS3 على نفس مساحة التخزين.

يتميز SFTPGo بأمان معماري متين:

تشفير كلمات المرور باستخدام Argon2id أو bcrypt.
دعم المصادقة الثنائية (TOTP).
التكامل مع مزودي الهوية عبر OpenID Connect وLDAP.
تحديد معدل الطلبات وحظر العناوين المشبوهة تلقائياً.

ملف تشغيل SFTPGo عبر Docker Compose:

services:
  sftpgo:
    image: drakkan/sftpgo:v2.6.2-alpine
    container_name: sftpgo
    security_opt:
      - no-new-privileges:true
    ports:
      - "8080:8080"   # واجهة الويب وبروتوكول WebDAV
      - "2022:2022"   # خدمة SFTP
    volumes:
      - /srv/sftpgo/data:/srv/sftpgo
      - /srv/shared_storage:/srv/shared_storage
    environment:
      - SFTPGO_HTTPD__BINDINGS__0__PORT=8080
      - SFTPGO_HTTPD__BINDINGS__0__ENABLE_WEB_ADMIN=true
      - SFTPGO_HTTPD__BINDINGS__0__ENABLE_WEB_CLIENT=true
    restart: unless-stopped

2. منصة Cloudreve

إذا كنت تعتمد على مشاركة الروابط الخارجية وتحديد مدد زمنية للتحميل وإدارة مساحات تخزين متعددة (كالدمج بين أقراص NVMe ومساحات S3 سحابية)، توفر Cloudreve واجهة سحابية متقدمة تدعم التشفير من جهة العميل وتسريع التحميل متعدد المسارات.

3. منصة OwnCloud Infinite Scale (OCIS)

للمؤسسات والفرق التي تبحث عن منصة متكاملة بعيداً عن ديون لغة PHP القديمة، بنيت منصة OCIS بالكامل بلغة Go وفق بنية الخدمات المصغرة (Microservices) دون الحاجة لقواعد بيانات MySQL تقليدية، وتعتمد أصلياً على معايير OpenID Connect.

خلاصة

تسدل أرشفة File Browser الستار على أداة خدمت مجتمع الاستضافة الذاتية بإخلاص على مدار عقد كامل. ورغم كفاءة نواتها في بدايتها، فإن متطلبات الأمان الحديثة لا تقبل التهاون مع برمجيات غير مصانة. يتوجب على مديري الأنظمة فحص بيئاتهم الحالية، والتأكد من إغلاق ثغرة مشغل الأوامر، ووضع الخوادم خلف مصادقة خارجية مشددة، والبدء في الترحيل التدريجي نحو منصات حديثة مثل SFTPGo.