قبل الغوص في استراتيجيات معينة لتطوير برمجيات آمنة ومنع الغش، من الضروري فهم المبادئ الأساسية لأمان Roblox. يتم بناء تجربة آمنة على عقلية تتوقع الأعمال العدائية. قبل كتابة سطر واحد من التعليمات البرمجية، يجب أن تستوعب هذه المبادئ الأساسية. يجب أن تؤثر على كل قرار معماري وتصميم تتخذه.
لا تثق في العميل
هذه هي المبدأ الأساسي. لديه المخترق المتعمد سيطرة كاملة على حالته المحلية و حركة الشبكة الخاصة به. نظرًا لأن المخترقين لديهم هذا المستوى من السيطرة، فإن أي إجراء أمني يعتمد على التنفيذ من جانب العميل سيتم تجاوزه في النهاية. هذه ليست قيودًا في Roblox: إنها حقيقة أساسية في معماريات العميل-الخادم. افترض أن كل قطعة من البيانات المرسلة من العميل قد تم تعديلها أو تركيبها أو تم إرسالها بنوايا خبيثة. يشمل ذلك القدرة على:
- فك تجميع أي LocalScript مكرر أو أي ModuleScript، حتى لو لم يتم تشغيلها أبدًا على العميل
- أخذ ملكية الشبكة لشخصيته وأي أجزاء غير مثبتة
- Trigger الأحداث التي يبدأها العميل مثل أحداث Touched أو تنشيط ProximityPrompt على أي مدى أو تردد
- تعديل موقع اللاعب الفيزيائي أو تفاعلاته مع العالم
- إشارة أو استدعاء RemoteEvents و RemoteFunctions بأي تردد مع وسيطات تعسفية (بخلاف وسيط اللاعب الأول)
- تغيير أي شيء في DataModel المحلي الخاص به دون إحداث أي أحداث متوقعة
- تعديل سلوك أي كود يعمل محليًا بشكل تعسفي
بسبب ذلك، يجب التحقق من كل المنطق الحرج على جانب الخادم أو تشغيله حصريًا على الخادم. العواقب لهذه السيطرة مفصلة في ملكية الشبكة والتحقق من الحركة واستغلالات الفيزياء و التحكم في الوصول والسرية.
سلطة الخادم
يجب أن يكون الخادم هو المصدر النهائي للحقيقة لجميع حالات المحاكاة، القواعد، تقدم اللاعب، والقرارات الحاسمة. دور العميل هو عرض العالم وإرسال مدخلات المستخدم إلى الخادم.
دور الخادم هو:
- استقبال المدخلات من العميل
- التحقق من أن الإجراء المطلوب ممكن ومسموح به
- تنفيذ الإجراء وتحديث حالته السلطة
- تكرار النتائج لجميع العملاء المعنيين
على سبيل المثال، إذا قال اللاعب "أريد شراء علبة Bloxy Cola"، يجب أن يعرف الخادم السعر الحقيقي للعنصر، أموال اللاعب، والمسافة الفيزيائية لشخصية اللاعب من المتجر قبل التحقق من صحة الصفقة والموافقة عليها. قدر الإمكان، ينبغي أن يتم الحفاظ على الحالة التي يجب التحقق منها حصريًا بواسطة الخادم وليس بواسطة العملاء. في المثال، إذا تمت الموافقة على صفقة Bloxy Cola، يجب على الخادم طرح سعر Bloxy Cola من أموال اللاعب، ومع ذلك، لا يمكن للخادم السيطرة دائمًا على شخصية اللاعب.
الأمان من التصميم
قم بدمج اعتبارات الأمان في تصميم تجربتك منذ البداية، بدلاً من محاولة إضافتها لاحقًا كفكرة لاحقة.
- نموذج التهديد لكل ميزة جديدة. لكل ميزة جديدة، اسأل
- كيف يمكن لمهاجم استغلال ذلك إذا كان لديه السيطرة الكاملة على عميله؟
- إذا كان بإمكان العميل إرسال أي قيمة لأي معلمات مستخدمة في الميزة، ما هو أسوأ نتيجة ممكنة؟
- ماذا يحدث إذا تم استخدام هذه الميزة 1,000+ مرة في الثانية؟ ما هي أقصى معدل يمكن استخدامها؟
- هل يمكن لمخترق استخدام هذا لتدمير تجربة لاعب آخر؟
- كم من الموارد، في أسوأ الحالات، يمكن أن تستهلكه هذه الميزة بشكل معقول؟
- ما هي الحد الأدنى من المعلومات الداخلية أو الحالة التي أحتاج إلى كشفها لهذه الميزة؟
- قسم المسؤوليات مبكرًا. احتفظ بالمنطق والبيانات في ServerScriptService منذ اليوم الأول. لا تضعها أبدًا في حاويات مكررة مثل ReplicatedStorage أو Workspace.