تُعد رسوميات SVG (الرسوميات المتجهية القابلة للتحجيم) من أكثر التنسيقات المحبوبة لدى المطورين والمصممين، وذلك لقابليتها للتحجيم، وصغر حجم ملفاتها، وجودة عرضها العالية. ولكن خلف مظهرها البريء القائم على لغة XML، تختبئ واحدة من أقوى نواقل هجمات البرمجة النصية عبر المواقع (XSS).
في هذا المقال، سنستكشف كيف يمكن تسليح ملفات SVG، والمخاطر الواقعية، والأهم من ذلك — كيفية الدفاع ضدها.
لماذا يُعد SVG كابوسًا أمنيًا
على عكس تنسيقات الصور العادية (JPG، PNG، GIF)، فإن SVG ليس مجرد صورة — بل هو لغة توصيف يمكن أن تحتوي على:
جافا سكريبت
معالجات الأحداث (
onload،onbegin، إلخ)HTML مضمنة
رسوميات CSS المتحركة
كائنات أجنبية (Foreign Objects)
هذه المرونة تجعل SVG قويًا جدًا للاستخدامات المشروعة، ولكنها أيضًا خطيرة للغاية عندما يسمح للمستخدمين برفع أو عرض ملفات SVG غير موثوقة.
نواقل هجمات XSS الشائعة في SVG
إليك الحمولات الأكثر فعالية التي يستخدمها المهاجمون:
1. حمولة onload التقليدية
svg
<svg onload="alert('XSS')"></svg>2. علامة سكربت داخل SVG
svg
<svg><script>alert('XSS')</script></svg>3. هجوم قائم على الرسوم المتحركة (يتجاوز العديد من المرشحات)
svg
<svg><animate onbegin="alert('XSS')" attributeName="x" dur="1s" repeatCount="indefinite"/>4. خدعة ForeignObject (خفية جدًا)
svg
<svg>
<foreignObject>
<body>
<script>alert('XSS')</script>
</body>
</foreignObject>
</svg>5. حقن Data URI + HTML
svg
<svg><desc><![CDATA[</desc><script>alert('XSS')</script>]]></svg>التأثير الواقعي
العديد من المنصات الشهيرة (بما في ذلك بعض أنظمة إدارة المحتوى، والمنتديات، وأدوات SaaS) كانت عرضة لهجمات XSS المخزنة القائمة على SVG.
يمكن للمهاجمين سرقة ملفات تعريف الارتباط، ورموز الجلسات، والاستيلاء على الحسابات، وتسجيل ضغطات المفاتيح، أو تعدين العملات المشفرة باستخدام نصوص تشبه Coinhive داخل ملفات SVG.
حتى رفع الصور الرمزية (avatars) قد أسيء استخدامه عندما تعرض التطبيقات ملفات SVG مع
Content-Type: image/svg+xmlدون تنقية مناسبة.
لماذا تفشل العديد من أدوات التنقية
معظم أدوات تنقية HTML (مثل DOMPurify في الإعدادات الافتراضية، أو مرشحات PHP الأساسية) لا توفر حماية كاملة ضد هجمات SVG إلا إذا تم تهيئتها خصيصًا لذلك.
الأخطاء الشائعة:
إزالة علامات
<script>فقطالسماح بـ
data:URIsعدم تعطيل معالجات الأحداث
تقديم ملفات SVG بأنواع MIME قابلة للتنفيذ
أفضل الممارسات لتأمين استخدام SVG
لا تثق أبدًا في ملفات SVG التي يرفعها المستخدمون
استخدم أداة تنقية صارمة لـ SVG مثل DOMPurify مع إعدادات مناسبة:
js
const cleanSVG = DOMPurify.sanitize(userSVG, { USE_PROFILES: { svg: true, svgFilters: true }, FORBID_TAGS: ['script', 'style', 'foreignObject'], FORBID_ATTR: ['onload', 'onerror', 'onbegin'] });تحويل ملفات SVG إلى تنسيقات آمنة
تحويل SVG إلى صور نقطية PNG على جانب الخادم (باستخدام مكتبات مثل
sharp، أوlibrsvg، أوImageMagick).
تقديم ملفات SVG مع ترويسات صارمة
استخدم
Content-Disposition: attachmentأو سياسة أمان المحتوى (CSP) لمنع تنفيذ النصوص البرمجية.ضع في اعتبارك استخدام خاصية
sandboxإذا كنت تقوم بتضمينها.
استخدم مكتبة تنقية مخصصة
svg-sanitizer (PHP)
DOMPurify (JavaScript)
svgcleaner أو نظام تصفية قائمة بيضاء مخصص من جانب الخادم
تدابير دفاعية إضافية
تنفيذ سياسة أمان المحتوى (CSP) مع
script-srcصارمةالتحقق من تواقيع الملفات (البايتات السحرية) قبل المعالجة
تحديد مدى تعقيد SVG (الحجم، عدد العناصر)
الخلاصة
يعد SVG تنسيقًا مفيدًا للغاية، لكن التعامل معه كصورة عادية هو خطأ خطير. كل تطبيق يقبل ملفات SVG من المصادر غير الموثوقة يجب أن يعاملها كأكواد قابلة للتنفيذ.
قاعدة أمنية ثابتة:
إذا كانت أداة التنقية لديك لا تدعم SVG بشكل آمن وصريح — فافترض أنها عرضة للاختراق.


