استراتيجيات الأمان والتخفيف من الغش

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

لا تثق في العميل

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

• فك تجميع أي LocalScript مكرر أو أي ModuleScript، حتى لو لم يتم تشغيلها أبدًا على العميل
• أخذ ملكية الشبكة لشخصيتهم وأي أجزاء غير مثبتة
• تفعيل الأحداث التي يبدأها العميل مثل أحداث Touched أو تفعيل ProximityPrompt على أي مدى أو تردد
• تعديل موقع اللاعب، أو الفيزياء، أو التفاعلات مع العالم
• إطلاق أو استدعاء RemoteEvents وRemoteFunctions بأي تردد مع وسائط تعسفية (بخلاف الوسيطة الأولى Player)
• تغيير أي شيء في DataModel المحلي الخاص بهم دون إطلاق أي أحداث متوقعة
• تغيير سلوك أي كود يعمل محليًا بشكل تعسفي

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

سلطة الخادم

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

دور الخادم هو:

• تلقي المدخلات من العميل
• التحقق من أن الإجراء المطلوب ممكن ومسموح به
• تنفيذ الإجراء وتحديث حالته الموثوقة
• تكرار النتائج لجميع العملاء المعنيين

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

الأمان من خلال التصميم

ادمج اعتبارات الأمان في تصميم لعبتك من البداية، بدلاً من محاولة إضافتها لاحقًا كفكرة لاحقة.

• نموذج التهديد لكل ميزة جديدة. لكل ميزة جديدة، اسأل

  • كيف يمكن لمهاجم استغلال ذلك إذا كان لديه السيطرة الكاملة على عميله؟
  • إذا كان بإمكان العميل إرسال أي قيمة لأي معلمات مستخدمة في الميزة، ما هي أسوأ نتيجة ممكنة؟
  • ماذا يحدث إذا تم استخدام هذه الميزة 1,000+ مرة في الثانية؟ ما هو الحد الأقصى لمعدل استخدامها؟
  • هل يمكن لمستغل استخدام ذلك لتدمير تجربة لاعب آخر؟
  • كم من الموارد، في أسوأ الحالات، يمكن أن تستخدمه هذه الميزة بشكل معقول؟
  • ما هي الحد الأدنى من المعلومات الداخلية أو الحالة التي أحتاج إلى كشفها لهذه الميزة؟
• قسم المسؤوليات مبكرًا. احتفظ بالمنطق والبيانات في ServerScriptService من اليوم الأول. لا تضعها أبدًا في حاويات مكررة مثل ReplicatedStorage أو Workspace.