محمد شرف

رفع الملفات: الباب الذي نتركه مفتوحًا

لماذا ما زالت خاصية «رفع ملف» من أسهل الطرق لاختراق تطبيقات الويب، وقائمة تحقق قصيرة تصمد فعلًا.

· 3 دقائق قراءة

تقريبًا كل منتج يسمح للناس برفع شيء ما: صورة شخصية، فاتورة، سيرة ذاتية، صورة هوية. تبدو أكثر خاصية عادية في العالم، ولهذا نادرًا ما تحصل على الاهتمام الذي تستحقه.

لكن من وجهة نظر المهاجم، نموذج رفع الملفات دعوة مهذبة: من فضلك ضع ملفي على سيرفرك. وكل ما يحدث بعد ذلك (أين يُحفظ الملف، ومن يقرؤه، ومن يستطيع فتحه لاحقًا) هو ما يحدد إن كانت الدعوة بريئة أم بداية أسبوع سيئ جدًا.

ما الذي يخطئ عادةً

١. الثقة فيما يقوله المتصفح

اسم الملف وامتداده وترويسة Content-Type كلها تأتي من المستخدم، وكلها يمكن أن تقول أي شيء. ملف اسمه avatar.jpg وترويسته image/jpeg قد يكون سكربتًا في الحقيقة. الاكتفاء بهذه القيم يشبه التحقق من بطاقة زائر طبعها بنفسه.

٢. حفظ الملفات حيث يستطيع السيرفر تشغيلها

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

٣. الإبقاء على اسم الملف الأصلي

الأسماء التي يرسلها المستخدم تجلب مشاكلها معها: أسماء تحاول الخروج من مجلد الرفع (../../)، وأسماء تكتب فوق ملف شخص آخر، وأسماء تُفسد السجلات أو صفحات الموقع. نادرًا جدًا ما يوجد سبب جيد لحفظها كما هي.

٤. غياب الحدود

لا حد أقصى للحجم، ولا حد لكل مستخدم، ولا حد لما يمكن أن يتمدد إليه ملف مضغوط. هكذا يملأ ملف واحد القرص، أو تتحول «قنبلة zip» صغيرة إلى جيجابايتات لحظة فك ضغطها.

٥. عرض الملفات من نطاق موقعك الرئيسي

الملفات التي يستطيع المستخدمون فتحها مرة أخرى، مثل صور SVG أو ملفات HTML أو أي شيء قد يتعامل معه المتصفح على أنه HTML، يمكن أن تحمل JavaScript. وإذا عُرضت من نطاقك الرئيسي، يعمل هذا الكود بجلسات مستخدميك. هذا هو XSS المخزَّن، يصل عبر خاصية ظن الجميع أنها مجرد «تنزيلات».

٦. نقطة الضعف في المكتبة التي تقرأ الملف

أحيانًا يكون الملف سليمًا والمكتبة التي تقرؤه ليست كذلك. محولات الصور وأدوات PDF ومحللات المستندات كلها مرت بثغرات خطيرة. ثغرة ImageTragick في ImageMagick عام 2016 سمحت لصورة مصممة بعناية بتنفيذ أوامر على سيرفرات كانت تريد فقط صنع صور مصغرة. وملفات Office وSVG هي في الأصل XML، فتأتي معها هجمات XML أيضًا.

قائمة تحقق تصمد فعلًا

  1. اسمح بالقليل بدل أن تمنع الكثير. حدد أنواع الملفات القليلة التي تحتاجها فعلًا، واقبلها وحدها. وتحقق من المحتوى الحقيقي (أول بايتات الملف)، لا من الامتداد فقط.
  2. غيّر الأسماء كلها. احفظ الملفات باسم أو معرّف عشوائي تولّده أنت، واحتفظ بالاسم الأصلي في قاعدة البيانات إن احتجت إلى عرضه.
  3. احفظ خارج جذر الموقع. والأفضل استخدام تخزين منفصل للملفات. المكان الذي تعيش فيه الملفات يجب ألا يستطيع تشغيل أي شيء.
  4. اعرض بحذر. استخدم نطاقًا منفصلًا لملفات المستخدمين متى أمكن، وأرسل Content-Disposition: attachment لكل ما لا يُفترض عرضه داخل الصفحة، ومعه X-Content-Type-Options: nosniff.
  5. ضع حدودًا. حد أقصى للحجم، وعدد أقصى من الملفات لكل مستخدم، وسقف لما يمكن أن تتمدد إليه الملفات المضغوطة.
  6. أعد معالجة الصور. أعد ترميز الصور المرفوعة في ملف جديد، فهذا يزيل المحتوى المخفي والبيانات الوصفية في الطريق.
  7. اعزل المحللات. شغّل التحويل والصور المصغرة في عامل منفصل بصلاحيات منخفضة، وحدّث تلك المكتبات باستمرار، وافحص المستندات قبل أن يفتحها أحد.
  8. سجّل وراقب. سجّل من رفع ماذا ومتى. ستحتاج هذا التاريخ في اليوم الذي يبدو فيه شيء غير طبيعي.

للتفاصيل التقنية الكاملة، تبقى ورقة OWASP المرجعية لرفع الملفات أفضل مرجع، وتستحق أن تحفظها.

النسخة المملة هي النسخة الآمنة

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

شاركWhatsAppLinkedInXTelegramFacebook