المشكلة في جملة واحدة
في المرة القادمة يقترح مساعد الذكاء الاصطناعي حزمة لتثبيتهاهل ستتحقق فعلاً من وجود تلك الحزمة؟ معظم المطورين لم يفعلوا ذلك. هذه الفجوة بين الاقتراح والتحقق هي بالضبط نقطة انطلاق هجمات الاستيلاء على أسماء النطاقات، ولهذا السبب أصبح فهم تطور هذه الهجمات وسبل الوقاية منها عملياً أولوية حقيقية لفرق أمن التطبيقات وفرق تطوير البرمجيات الآمنة.
ما هو هجوم القرفصاء المائل؟
هجوم القرفصاء المتهتك هو أحد أشكال هجوم القرفصاء المتهتك. typosquatting (ممارسة تسجيل اسم نطاق أو حزمة برامج يحاكي اسم نطاق أو حزمة برامج شرعية من خلال خطأ إملائي شائع، مثل الطلبات بدلا من طلبات(على أمل أن يقود خطأ إملائي من المستخدم إلى الهدف مباشرةً)، ولكن مع اختلاف جوهري في مصدر الخطأ. يستغلّ هجوم انتحال أسماء النطاقات أخطاء الكتابة البشرية. أما هجوم انتحال أسماء النطاقات غير الدقيق فيستغلّ الأخطاء التي ترتكبها نماذج اللغة الكبيرة: إذ "يتوهم" نموذج اللغة الكبير اسم حزمة يبدو شرعيًا تمامًا ولكنه غير موجود في أي سجل عام، ويسبقه المهاجم بتسجيل هذا الاسم تحديدًا قبل أي شخص ذي نوايا حسنة.
إن الآلية الكامنة وراء هجوم القرفصاء النموذجي بسيطة، وهذه البساطة هي بالضبط ما يجعلها فعالة:
- يطلب مطور برامج من مساعد ذكاء اصطناعي المساعدة في حل مشكلة برمجية.
- يقوم النموذج بإنشاء حل يقوم باستيراد أو التوصية بتثبيت حزمة لم تكن موجودة من قبل.
- يقوم المهاجم الذي يلاحظ تكرار عدة نماذج لنفس الاسم الوهمي بتسجيل تلك الحزمة على npm أو PyPI أو أي سجل عام آخر، مع تضمينها شيفرة خبيثة. عندها يتحول الوهم إلى هجوم انتحال أسماء النطاقات فعلي.
- المطور التالي الذي يتلقى نفس الاقتراح ولا يتحقق منه، يقوم بتثبيت الحزمة الحقيقية الآن، والتي تمثل بابًا خلفيًا إلى بيئتهم.
صاغ سيث لارسون، مطور الأمن المقيم في مؤسسة برمجيات بايثون، مصطلح "slopsquatting"، ونشره أندرو نيسبيت، لوصف هذا النمط تحديدًا: "هلوسة الحزمة" التي تحولت إلى ناقل للهجوم.
تطور السكن العشوائي: كيف تحول فضول بحثي إلى تهديد حقيقي
إن ما يثير الانتباه في تطور أسلوب "slopsquatting" ليس المفهوم فحسب، بل مدى سرعة انتقاله من مجرد ملاحظة بحثية إلى فئة موثقة وقابلة للقياس من الهجمات.
2023: أول إشارة تحذيرية. الباحث الأمني بار لانيادو لاحظت أن العديد من برامج الماجستير في القانون أوصت مرارًا وتكرارًا بحزمة تسمى Huggingface-cli، وهو غير موجود (يتم تثبيت الحزمة الحقيقية باستخدام pip install -U “huggingface_hub[cli]”ولإثبات خطورة الأمر، قام بتحميل نسخة فارغة من تلك الحزمة إلى سجل عام. وفي غضون ثلاثة أشهر، تجاوز عدد مرات تحميلها 30,000 ألف مرة، دون أي ترويج. حتى أن الاسم الوهمي ظهر في ملف README الخاص بمستودع مرتبط ببحث أجرته شركة علي بابا، مما أظهر مبكراً كيف يمكن لهذه الأسماء "الوهمية" أن تتسرب إلى الوثائق الحقيقية وتمهد الطريق لهجمات الاستيلاء على أسماء النطاقات التي ستلي ذلك.
2024: ينتقل الخطر من منشور على مدونة باحث إلى تغطية إعلامية تقنية سائدة. في مارس 2024، السجل أفادت التقارير بأن نماذج الذكاء الاصطناعي كانت تبتكر بثقة أسماءً لحزم البرامج التي كان المطورون يقومون بتنزيلها، وبعضها قد يكون ملوثًا ببرمجيات خبيثة. لم تكن أهمية هذه التغطية التقنية تكمن في دلالتها، بل في دلالتها: لم تعد حالة huggingface-cli مجرد حالة شاذة، بل كانت أول مؤشر على نمط خطير بما يكفي لتنبيه وسائل الإعلام التقنية الرئيسية، قبل الدراسة الأكاديمية واسعة النطاق التي أكدت نطاقه بعد عام.
2025: أول قياس دقيق وواسع النطاق للمشكلة. الورقة البحثية بعنوان "لدينا حزمة لك! تحليل شامل لهلوسات الحزم بواسطة نماذج التعلم الآلي لتوليد الشفرة" (Spracklen et al.، تم تقديمها في ندوة USENIX الأمنيةاختبرت دراسة 16 نموذجًا لتوليد الشفرة، منها نماذج تجارية (GPT-4، GPT-3.5) ونماذج مفتوحة المصدر (CodeLlama، DeepSeek، WizardCoder، Mistral)، على 576,000 عينة من شفرة بايثون وجافا سكريبت. تُشير هذه النتائج إلى نقطة تحول واضحة في تطور ظاهرة الاستيلاء على أسماء النطاقات، إذ انتقلت من كونها مجرد حكايات إلى حقيقة مُثبتة.
- 19.7% من الباقات التي أوصت بها النماذج لم تكن موجودة.
- أظهرت النماذج مفتوحة المصدر حالات هلوسة أكثر بكثير (21.7% في المتوسط) من النماذج التجارية (5.2%).
- في جميع النماذج التي تم اختبارها، سجل الباحثون أكثر من 205,000 اسم حزمة فريد من نوعه، وهو عدد كبير بما يكفي لتغذية هجمات الاستيلاء على النطاقات المستمرة عبر أنظمة بيئية متعددة.
من أهمّ التفاصيل التي كشفت عنها الدراسة، وربما السبب وراء تسارع تطور هجمات الاستيلاء على أسماء النطاقات بدلاً من انحسارها، هو أن الأسماء المُختلقة ليست عشوائية، ولا تتغير في كل محاولة. تميل النماذج نفسها إلى تكرار الأسماء المُختلقة نفسها عند إعطائها مُدخلات مُتشابهة، ما يعني أن المُهاجم لا يحتاج إلى التخمين. كل ما عليه فعله هو مُراقبة سلوك النموذج، وتحديد الأسماء التي تتكرر باستمرار، وتسجيلها قبل أن يُسجلها مُطور حقيقي. وقد أظهر تحليل لاحق لهذه القابلية للتكرار أنه عندما أعاد الباحثون تشغيل المُدخلات المُتطابقة عشر مرات لكل منها، ظهر 43% من أسماء الحزم المُختلقة في كل تشغيل، ما يُثبت أن مُعظم هذه الظواهر المُختلقة هي نتاجات قابلة للتكرار وليست مُجرد ضوضاء عابرة. هذه القابلية للتكرار هي ما يُحوّل ظاهرة مُختلقة عابرة إلى هجوم استيلاء على أسماء نطاقات قابل للتوسع.
2026: من حزم معزولة إلى عوامل مستقلة. من حزم معزولة إلى عوامل مستقلة. شهد هذا العام أوضح دليل حتى الآن على أن الاستيلاء على أسماء النطاقات لم يعد مقتصراً على قيام مطور بنسخ ولصق أمر تثبيت pip أو npm المقترح. ففي يناير 2026، اكتشف الباحث الأمني تشارلي إريكسن أن برامج الذكاء الاصطناعي قد نشرت بالفعل تعليمات تشير إلى حزمة npm وهمية تُدعى react-codeshift (وهو اسم يُحتمل أن يكون مزيجاً بين أداتين حقيقيتين، jscodeshift و react-codemod)، عبر 237 مستودعاً، مع استمرار هذه البرامج في محاولة تثبيتها يومياً. وقد قام إريكسن بتسجيل الاسم بنفسه، كإجراء وقائي، قبل أن يتمكن أي مهاجم من استخدامه كسلاح. وفي سياق منفصل، كانت حزمة خبيثة حقيقية تُدعى unused-imports، وهي اسم وهمي بدلاً من eslint-plugin-unused-imports، لا تزال تُسجل حوالي 233 عملية تنزيل أسبوعياً في أوائل عام 2026 على الرغم من أن npm قد وضعتها تحت حظر أمني، مما يدل على المدة التي يمكن أن يستمر فيها هجوم الاستيلاء على أسماء النطاقات في جذب الضحايا حتى بعد الإبلاغ عنه. في الآونة الأخيرة، في يوليو 2026، وصف الباحثون تقنية ذات صلة، أطلق عليها اسم "HalluSquatting"، والتي تربط بين هلوسة الذكاء الاصطناعي وحقن فوري بحيث يمكن اختطاف وكيل ترميز الذكاء الاصطناعي الذي يجلب موردًا متوهمًا نيابة عن المستخدم لتشغيل التعليمات البرمجية التي يقدمها المهاجم، مما يوسع تطور الاستيلاء على النطاقات من خطر تثبيت سلبي إلى ناقل تنفيذ التعليمات البرمجية عن بعد نشط داخل سير عمل تطوير الوكلاء.
لماذا وسّع "ترميز المشاعر" نطاق هجمات الاستيلاء على المواقع؟
لن تُشكّل هجمات الاستيلاء على أسماء النطاقات (slopsquatting) مشكلة كبيرة لو كان استخدام الذكاء الاصطناعي في البرمجة ممارسةً محدودة الانتشار. لكنها ليست كذلك. فقد أدى ظهور مساعدي البرمجة، والوكلاء المستقلين، وسير عمل "البرمجة التفاعلية" (Vibe Codeing)، حيث يراجع المطورون جزءًا أقل فأقل من الكود قبل تشغيله، إلى تغيير سطح هجوم البرمجيات بطريقتين ملموستين، وكلاهما يُسرّع من تطور الاستيلاء على أسماء النطاقات (slopsquatting):
- لم تعد نقطة الدخول مقتصرة على المطور فقط. كان هجوم انتحال أسماء النطاقات يعتمد في السابق على خطأ إملائي يرتكبه شخص واحد. أما الآن، فقد ينشأ الخطأ داخل النموذج نفسه وينتشر إلى مئات المطورين الذين يطرحون أسئلة متشابهة ويتلقون نفس التوصية الخاطئة، مما يضاعف نطاق هجوم انتحال أسماء النطاقات.
- لقد انتقل سطح الهجوم إلى مستوى أعلى في السلسلة. لم يعد كافيًا مجرد مراقبة الكود الذي يكتبه الإنسان. تحتاج الفرق أيضًا إلى مراقبة التبعيات التي يقترحها مساعد الذكاء الاصطناعي، وخوادم MCP التي يتصل بها، والوكلاء الذين يقومون بتثبيت الحزم تلقائيًا دون مراجعة بشرية مباشرة. تم تصميم أمن التطبيقات التقليدي لمراجعة المستودعات والبشر. commitلم يتم تصميم s مطلقًا لمراقبة هذا التفاعل الجديد بين المطور والذكاء الاصطناعي وسجل الحزم، وهو بالضبط المكان الذي تختبئ فيه هجمات الاستيلاء على أسماء النطاقات الآن.
لا يعني أيٌّ من هذا أن الذكاء الاصطناعي التوليدي غير آمن بطبيعته. بل يعني أنه يُدخل نوعًا جديدًا من مخاطر سلسلة التوريد التي لم تُصمَّم أدوات الأمان التقليدية لرصدها، وهي مخاطر تستدعي تطبيق مبادئ التحقق نفسها التي نطبقها بالفعل على أي تبعية خارجية: عدم الثقة بشكل افتراضي، والتحقق من المصدر، وأتمتة هذا التحقق بدلًا من الاعتماد على ذاكرة كل مطوّر أو يقظته. هذه الأتمتة هي أساس أي استراتيجية فعّالة لمنع الاستيلاء غير المشروع على أسماء النطاقات.
منع التلاعب بالنتائج: ما يمكن للفرق فعله اليوم
الخبر السار هو أن منع الاستيلاء غير المدروس على التبعيات لا يتطلب أدوات معقدة. بل يتطلب تطبيقًا منهجيًا لممارسات إدارة التبعيات السليمة الموجودة بالفعل، والتي تتهاون فيها العديد من الفرق بمجرد أن "يقترح" الذكاء الاصطناعي الذي تثق به الكود. عادةً ما يجمع النهج الفعال لمنع الاستيلاء غير المدروس بين ما يلي:
- تحقق يدويًا من أي حزمة جديدة قبل تثبيتهاخاصةً عندما يأتي الاقتراح من مساعد ذكاء اصطناعي. تأكد من وجوده في السجل الرسمي، ومن الجهة المسؤولة عنه، وتاريخ نشره، وما إذا كانت أرقام تنزيلاته تبدو حقيقية. هذه العادة البسيطة هي أرخص وسيلة متاحة لأي فريق لمنع الاستيلاء غير المشروع على أسماء النطاقات.
- لا تفترض أبدًا أن الكود الذي يولده الذكاء الاصطناعي آمن بشكل افتراضي. لا يعني عمل جزء من الكود بالضرورة أن تبعياته سليمة. يجب أن تكون مراجعة التبعيات جزءًا لا يتجزأ من مراجعة الكود، لا استثناءً منها.
- استخدم ملفات القفل والتحقق من التجزئة لتثبيت الإصدارات الدقيقة ومنع التحديث الصامت من استبدال الحزمة بحزمة مختلفة عن تلك التي تم تدقيقها في الأصل.
- قم بتطبيق فحص التبعيات الذي يحدد أنماط المخاطر التي تتجاوز الثغرات الأمنية المعروفة (CVEs).تتضمن هذه الهجمات استخدام حزم غير مألوفة، أو أسماء مشابهة بشكل مثير للريبة لأسماء موجودة، أو مطورين جدد ليس لديهم سجل حافل، أو برامج تثبيت ذات سلوك غير عادي. إن نشر حزمة جديدة بدون تاريخ تقريبًا، تحمل اسمًا مشابهًا لاسم شيء مألوف، هو النمط السائد في معظم هجمات الاستيلاء على أسماء النطاقات التي تم توثيقها حتى الآن.
- تعامل مع السجلات العامة بنفس القدر من التحفظ.cism مثل أي مصدر خارجي آخر غير موثق. حقيقة أن تثبيت نقطة or تركيب npm عدم ظهور خطأ لا يُعد دليلاً على صحة العملية.
- فرق تطوير القطارات على حقيقة أن البرمجة بمساعدة الذكاء الاصطناعي لا تلغي مسؤولية التحقق مما يتم تثبيته؛ إنها تضيف فقط خطوة يجب تضمينها في سير العمل كجزء من أي خطة جادة لمنع الاستيلاء غير المشروع على المواقع.
لا يُعد أيٌّ من هذه الإجراءات جديدًا بحد ذاته. ما تغيّر هو النطاق: فعندما لا يأتي اقتراح التبعية من موقع Stack Overflow أو من زميل، بل من نموذج قادر على تكرار الخطأ الوهمي نفسه لآلاف المطورين المختلفين، فإن التحقق اليدوي، مع أنه لا يزال ضروريًا، لم يعد كافيًا بمفرده. لهذا السبب، تقوم المزيد من الفرق بأتمتة هذه الطبقة من منع الاستيلاء غير المصرح به ضمن أنظمتها. تحليل تكوين البرمجيات (SCA) الأدواتبدلاً من ترك الأمر ينحصر في انضباط المطورين الأفراد.
هذا هو قبلcisلماذا إيلي ASPM منصات مثل زيجيني دمج خاصية الكشف عن التبعيات المشبوهة، والتي تشمل انتحال أسماء النطاقات، والخلط بين التبعيات، والحزم الخبيثة المعروفة، في نفس تحليل التبعيات مفتوح المصدر والذكاء الاصطناعي. pipelineلذا فإن منع الاستيلاء غير المصرح به لا يعتمد على أن يتذكر كل مطور التحقق منه في كل مرة يقترح فيها مساعد الذكاء الاصطناعي تبعية جديدة.
الأسئلة الشائعة
هل هجوم الاستيلاء على أسماء النطاقات غير المتقنة هو نفسه هجوم الاستيلاء على أسماء النطاقات المطبعية؟
ليس تمامًا. كلاهما يتضمن تسجيل اسم حزمة وهمي لخداع من يقوم بتثبيتها، لكن مصدر الخطأ يختلف. يستغل هجوم انتحال أسماء النطاقات أخطاء الكتابة البشرية. أما هجوم انتحال أسماء النطاقات العشوائي فيستغل أسماء الحزم التي تخترعها (أو تتخيلها) نماذج الذكاء الاصطناعي، والتي يقوم المهاجم بتسجيلها قبل وجودها فعليًا.
هل يستطيع مدير الحزم منع هذا النوع من الهجمات تلقائيًا؟
ليس تمامًا، ولهذا السبب تحديدًا لا يمكن أن يقتصر منع انتحال أسماء النطاقات على مستوى مدير الحزم. فإذا قام مهاجم بتسجيل الحزمة الوهمية قبل أن يحاول مطور تثبيتها، فسيكتمل التثبيت دون أي خطأ لأن الحزمة موجودة بالفعل، حتى وإن كانت خبيثة. يتطلب المنع الفعال تحققًا إضافيًا من مصدر الحزمة وسلوكها.
هل يؤثر هذا فقط على النماذج مفتوحة المصدر؟
لا. وجدت دراسة سبراكلين وآخرون حالات هلوسة في جميع النماذج التي تم اختبارها، بما في ذلك النماذج التجارية، وإن كان ذلك بمعدل أقل بكثير (5.2% مقابل 21.7% للنماذج مفتوحة المصدر التي تم تقييمها). لا يوجد نموذج خالٍ تمامًا من هذه المشكلة، وهذا جزء من سبب مواكبة تطور الاستيلاء غير المدروس لنمو البرمجة المدعومة بالذكاء الاصطناعي بشكل عام.
هل هذا خطر نظري، أم أنه تم استغلاله بالفعل؟
استخدم Huggingface-cli تُظهر هذه الحالة، وهي حزمة فارغة قام بتحميلها باحث وتم تنزيلها أكثر من 30,000 مرة في ثلاثة أشهر بدون أي ترويج، أن الخطر ليس نظريًا فقط: يكفي أن يكون الاسم المتخيل متسقًا بدرجة كافية عبر المطالبات المختلفة حتى يتمكن شخص ما من تحويله إلى هجوم حقيقي للاستيلاء على أسماء النطاقات.
