ما هو Mass Assignment وكيف تحمي تطبيقك؟

الكاتب: فريق تحرير Domeny.ForSale تاريخ النشر 21.10.2026

باختصار: Mass Assignment هو إسناد بيانات طلب HTTP تلقائيًا إلى حقول كائن داخلي أو نموذج قاعدة بيانات. ويتحول إلى ثغرة أمنية عندما يسمح التطبيق بهذه الطريقة بتغيير حقول لا ينبغي أن يتحكم فيها المستخدم، مثل الدور الذي يمنح صلاحيات المسؤول. وتعتمد الحماية أساسًا على تحديد الحقول المسموح بها صراحةً والتحقق من الصلاحيات على الخادم.

كيف يعمل الإسناد التلقائي للحقول

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

يتيح Mass Assignment تنفيذ ذلك دفعة واحدة، دون إسناد كل قيمة يدويًا. وتطابق هذه الآلية أسماء الحقول المستلمة مع خصائص الكائن. فإذا احتوت البيانات على الحقل ism، فقد تُسند قيمته إلى الخاصية ism في كائن المستخدم.

يُسمى هذا الربط أيضًا autobinding، أي الربط التلقائي. وفي سياق هذه الثغرة يُستخدم كذلك مصطلح object injection، أي حقن الكائنات، مع أنه قد يشير إلى آليات مختلفة في سياقات أمنية أخرى. الربط التلقائي بحد ذاته ليس خطأ؛ تبدأ المشكلة عندما يقبل الخادم حقولًا أكثر مما ينبغي.

مثال بسيط: تعديل الملف الشخصي وتغيير الدور

لنفترض أن نموذج تعديل الملف الشخصي يسمح بتغيير اسم العرض وعنوان البريد الإلكتروني فقط. تبدو البيانات الصحيحة المرسلة إلى الخادم كما يلي:

{
  "ism": "محمد العلي",
  "email": "mohammed (at) example.com"
}

لكن الحساب يحتوي على خصائص إضافية في قاعدة البيانات. فإلى جانب الاسم والعنوان، يُخزّن الحقل dawr الذي يحدد صلاحيات المستخدم. ولا يعرضه النموذج، لأن المستخدم العادي لا ينبغي أن يتمكن من تغييره.

غير أن المهاجم ليس مضطرًا إلى استخدام النموذج. إذ يمكنه تعديل الطلب المرسل وإضافة حقل آخر:

{
  "ism": "محمد العلي",
  "email": "mohammed (at) example.com",
  "dawr": "مسؤول"
}

إذا نسخ الخادم جميع الخصائص المستلمة إلى الحساب دون قيود، فقد يحفظ الدور الجديد أيضًا. وإذا كان نظام الصلاحيات يعتمد على هذا الحقل، فقد يؤدي ذلك إلى الحصول على صلاحيات المسؤول.

غياب الحقل عن النموذج ليس وسيلة حماية. يجب أن يحدد الخادم ما يمكن تغييره، لا مظهر الصفحة ولا شفرة JavaScript التي تعمل في المتصفح.

ما البيانات الأكثر عرضة للخطر؟

لا يقتصر Mass Assignment على حسابات المستخدمين. يظهر الخطر كلما نُقلت بيانات خارجية تلقائيًا إلى كائنات تحتوي أيضًا على خصائص داخلية.

من أمثلة الحقول التي تتطلب رقابة خاصة:

malik_id — قد يحدد مالك المستند أو الطلب؛
siir — قد يؤثر في المبلغ المحتسب مقابل الشراء؛
halat_daf — قد يوضح ما إذا كان الطلب قد دُفع ثمنه؛
email_muakkad — قد يحدد ما إذا كان يمكن تجاوز تأكيد عنوان البريد الإلكتروني.

فمثلًا، ينبغي لعميل المتجر إرسال معرّف المنتج وعدد الوحدات المطلوبة. وعلى الخادم تحديد السعر وفق الأسعار المعتمدة لديه، بدلًا من قبول القيمة الواردة في الطلب دون قيد.

ليس كل حقل إضافي كافيًا لنجاح هجوم. فلا بد من قبوله وإسناد قيمته واستخدامه بطريقة تؤثر في عمل التطبيق. لذلك يجب عند التحليل فحص تدفق البيانات كاملًا، لا محتويات النموذج وحدها.

كيف تحدّ من مخاطر Mass Assignment بفعالية؟

وسيلة الحماية الأساسية هي قائمة الحقول المسموح بها: لا يقبل الخادم للعملية المعنية سوى الخصائص التي حددها المطور. ففي تعديل الملف الشخصي العادي، قد تشمل القائمة ism وemail، لكن ليس dawr.

يمكن أن تكون الخطوات على النحو التالي:

huqul_masmuh_biha = ["ism", "email"]
bayanat_malaf = ikhtar_huqul(bayanat_talab, huqul_masmuh_biha)
haddith_malaf(mustakhdim_musajjal, bayanat_malaf)

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

لا يكفي التحقق من صحة التنسيق وحده. فقد تكون القيمة مسؤول اسمًا صالحًا لدور، لكن المستخدم العادي لا يملك حق تعيينها. لذا يلزم أيضًا التحقق من التفويض، أي التأكد من أن الشخص مخوّل بإجراء التغيير المعني.

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

كيف تفحص تطبيقك؟

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

لا تكتفِ بفحص استجابة الخادم؛ افحص أيضًا البيانات المحفوظة والصلاحيات الفعلية للحساب. ينبغي للتنفيذ الآمن أن يرفض التغيير غير المسموح به، أو يتجاهل الحقل الإضافي دون تغيير القيمة المحمية.

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

انظر أيضًا: ما هو Path Traversal؟