أمان تسجيل الدخول
تساعد ميزات تسجيل دخول فيسبوك مثل رموز الوصول والأذونات على توفير الأمان والسلامة للأشخاص والتطبيقات عند استخدامها، ولكن يلزم إجراء بعض خطوات الأمان من جانب التطبيقات نفسها.
قائمة مراجعة الأمان
يجب اعتبار القائمة التالية الحد الأدنى المطلق الذي ينبغي تنفيذه من كل التطبيقات التي تستخدم تسجيل دخول فيسبوك. وسيتفرد تطبيقك ببعض الميزات الأخرى وستحتاج للتفكير دائمًا في كيفية تأمين تطبيقك بأكبر درجة ممكنة. إذ تخسر التطبيقات غير الآمنة ثقة جمهورها ويتوقف الأشخاص عن استخدامها.
المفتاح السري للتطبيق
يتم استخدام المفتاح السري للتطبيق في بعض حالات دفق تسجيل الدخول لإنشاء رموز الوصول؛ ويهدف المفتاح السري ذاته إلى تأمين استخدام تطبيقك وقصره على الأشخاص الموثوق بهم. يمكن استخدام المفتاح السري في إنشاء رموز وصول التطبيق بسهولة والتي يمكنها تقديم طلبات API نيابة عن أي مستخدم للتطبيق، وهو ما يجعل عدم اختراق المفتاح السري للتطبيق أمرًا في غاية الأهمية.
لذا يجب ألا يتم تضمين المفتاح السري للتطبيق أو رمز وصول التطبيق في أي رمز.
نوصي بعدم استخدام رموز وصول التطبيق إلا من خوادم تطبيقك مباشرة لتوفير أفضل قدر من الأمان. بالنسبة للتطبيقات الأصلية، نوصي بتواصل التطبيق مع خادمك ليقوم الخادم بتقديم طلبات API إلى Facebook باستخدام رمز وصول التطبيق. لهذا السبب، في حالة تعيين "نوع التطبيق" ضمن الإعدادات المتقدمة في لوحة معلومات التطبيق إلى Native/Desktop، فإننا نفترض أن تطبيقك الأصلي يحتوي على المفتاح السري للتطبيق أو رمز وصول التطبيق في الملف الثنائي ولا نسمح بمتابعة إجراء استدعاءات موقّعة برمز وصول التطبيق. ستعمل API كما لو أنه لم يتم تقديم رمز وصول.
استدعاءات آمنة من جانب الخادم تتضمن appsecret_proof
يمكنك تقليل التعرّض للبرامج الضارة ومُرسلي المحتوى غير المهم أو الاحتيالي عن طريق طلب التوقيع على استدعاءات خادم إلى خادم لواجهة API في فيسبوك بالمعلمة appsecret_proof. يكون إثبات المفتاح السري للتطبيق عبارة عن تجزئة sha256 لرمز الوصول لديك، باستخدام المفتاح السري للتطبيق الخاص بك باعتباره المفتاح. يمكن العثور على المفتاح السري للتطبيق في لوحة معلومات التطبيق لديك في الإعدادات > الأساسية.
إنشاء الإثبات
يوضح نموذج الرمز التالي ما يبدو عليه الاستدعاء بلغة PHP:
$appsecret_proof= hash_hmac('sha256', $access_token.'|'.time(), $app_secret); ستُرجع بعض أنظمة التشغيل ولغات البرمجة طابعًا زمنيًا في صورة رقم عشري. تأكد من تحويل القيمة إلى عدد صحيح قبل حساب إثبات المفتاح السري للتطبيق. تعمل بعض لغات البرمجة على إنشاء التجزئة في صورة كائن مشفر. تأكد من عرض التجزئة في صورة كائن سداسي عشري.
إضافة الإثبات
تضيف النتيجة كمعلمة appsecret_proof مع تعيين appsecret_time إلى الطابع الزمني الذي استخدمته عند تجزئة المفتاح السري للتطبيق لكل استدعاء تجريه:
curl \
-F 'access_token=ACCESS-TOKEN' \
-F 'appsecret_proof=APP-SECRET-PROOF' \
-F 'appsecret_time=APP-SECRET-TIME' \
-F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/accounts"}]' \
https://graph.facebook.comسيتم اعتبار إثباتات مفتاح التطبيق التي تحتوي على طابع زمني منتهية الصلاحية بعد 5 دقائق، لذلك يوصى بإنشاء إثبات جديد سارٍ عند إجراء أي استدعاء في Graph API.
طلب الإثبات
لتمكين طلب المفتاح السري للتطبيق لكل استدعاءات API من جانبك، انتقل إلى لوحة معلومات تطبيق Meta وانقر على إعدادات التطبيق > الإعدادات المتقدمة في القائمة على الجانب الأيمن. مرّر إلى قسم الأمان، وانقر على زر تبديل طلب المفتاح السري للتطبيق.
إذا تم تمكين هذا الإعداد، فيجب توجيه جميع الاستدعاءات التي بدأها العميل عبر الواجهة الخلفية حيث يمكن إضافة معلمة appsecret_proof إلى الطلب قبل إرساله إلى Graph API، وإلا سيفشل الاستدعاء.
استدعاءات آمنة من جانب الوكيل من خلال رموز قصيرة المدى ودفق الرمز البرمجي
مع بعض حالات التكوين، تستخدم التطبيقات رمز وصول طويل الأمد عبر كل العملاء. لا تفعل ذلك. بل استخدِم الرموز قصيرة الأجل التي يتم إنشاؤها باستخدام دفق الرمز البرمجي، على النحو الذي تم وصفه في وثائق رمز الوصول.
الاستيلاء على الرمز
لفهم كيفية حدوث ذلك، تخيل أن تطبيق iOS أصلي يريد إجراء استدعاءات API، وبدلاً من القيام بذلك مباشرة، يتصل بالخادم المملوك لنفس التطبيق ويمرر لهذا الخادم رمزًا تم إنشاؤه باستخدام مجموعة SDK لنظام iOS. عندها سيستخدم الخادم الرمز لإجراء استدعاءات API.
قد تكون نقطة النهاية التي يستخدمها الخادم لتلقي الرمز مخترقة ويمكن للآخرين تمرير رموز وصول تخص تطبيقات مختلفة تمامًا إليه. قد يفتقد ذلك إلى الأمان بشكل واضح، لكن هناك طريقة للحماية منه - يجب ألا يُفترض مطلقًا أن رموز الوصول آتية من التطبيق الذي يستخدمها، وينبغي بدلاً من ذلك فحصها باستخدام نقاط نهاية تصحيح الأخطاء.
التحقق من صلاحية رمز الوصول بانتظام
إذا لم تكن تستخدم مجموعات Facebook SDK، فتحقق بانتظام مما إذا كان رمز الوصول صالحًا أم لا. وعلى الرغم من أن رموز الوصول تتضمن فترة انتهاء صلاحية مجدولة، فإنه يمكن أن تنتهي صلاحية الرموز المميزة مبكرًا لأسباب تتعلق بالأمان. أما إذا لم تستخدم مجموعات Facebook SDK في تطبيقك، فمن المهم للغاية أن تقوم يدويًا بإجراء عمليات تحقق من صحة رمز الوصول بشكل متكرر، على الأقل يوميًا، وذلك للتأكد من أن تطبيقك لا يعتمد على رمز مميز انتهت صلاحيته مبكرًا لأسباب تتعلق بالأمان.
معلمة الحالة
إذا كنت تستخدم مربع الحوار تسجيل دخول فيسبوك على موقعك على الويب، فستكون المعلمة state سلسلة فريدة تحمي تطبيقك من التعرض لهجمات تزوير الطلب عبر الموقع.
تمكين الوضع الصارم
يحافظ الوضع الصارم على أمان التطبيقات عن طريق منع المحتالين من الاستيلاء على رمز عملية إعادة التوجيه الخاصة بك. ويلزم تمكين الوضع الصارم لكل التطبيقات.
قبل تشغيل الوضع الصارم في لوحة معلومات التطبيق، يجب التأكد من استمرار عمل زيارات إعادة التوجيه الحالية إلى الآن باتخاذ الإجراءات التالية في إعدادات تسجيل دخول فيسبوك:
وبالنسبة إلى التطبيقات التي لها محددات URI لعمليات إعادة التوجيه الديناميكية، استخدِم معلمة الحالة لإرجاع المعلومات الديناميكية التي يتم تجميعها إلى عدد محدود من محددات URI لعمليات إعادة التوجيه. وبعد ذلك، أضِف كل محددات URI لإعادة التوجيه المحدودة إلى قائمة محددات URI صالحة لإعادة توجيه OAuth.
بالنسبة إلى التطبيقات ذات عدد محدود من محددات URI لإعادة التوجيه، يمكنك إضافة كل واحدة إلى قائمة محددات URI صالحة لإعادة توجيه OAuth.
- بالنسبة للتطبيقات التي تستخدم مجموعة SDK للغة JavaScript من Facebook فقط، تتم حماية زيارات إعادة التوجيه بالفعل. لا يوجد أي إجراءات إضافية مطلوبة.
وبعد اتخاذ هذه الإجراءات، تأكد من تمكين الوضع الصارم.
طريقة عمل الوضع الصارم
يمنع الوضع الصارم الاستيلاء على محددات URI لإعادة التوجيه من خلال طلب تطابق تام من قائمة محددات URI صالحة لإعادة توجيه OAuth. على سبيل المثال، إذا كانت القائمة التي تستخدمها تحتوي على www.example.com، فلن يسمح الوضع الصارم بفتح www.example.com/token كعنوان إعادة توجيه صالح. ولن يسمح كذلك بأي معلمات استعلام إضافية غير موجودة في قائمة محددات URI صالحة لإعادة توجيه OAuth.
استخدام بروتوكول HTTPS
يمكنك استخدام HTTPS بدلاً من HTTP كبروتوكول الإنترنت؛ لأنه يستخدم التشفير. ويحافظ HTTPS على خصوصية البيانات التي يتم إرسالها ويحميها من عمليات هجوم التنصت. وكذلك يحمي البيانات من التلاعب بها أثناء عملية الإرسال من خلال، على سبيل المثال، تقديم إعلانات أو رمز برمجي ضار.
في 6 أكتوبر 2018، سيكون مطلوبًا من كل التطبيقات استخدام HTTPS.
تمكين مجموعة SDK للغة JavaScript لتسجيل دخول Facebook
عندما تشير إلى أنك تستخدم مجموعة SDK للغة JavaScript لتسجيل الدخول عن طريق تعيين زر التبديل تسجيل الدخول باستخدام مجموعة SDK للغة JavaScript إلى "نعم"، يجب أن يتطابق نطاق صفحتك التي تستضيف مجموعة SDK مع أحد المُدخلات في قائمة النطاقات المسموح بها في مجموعة SDK للغة JavaScript. ويضمن ذلك إرجاع رموز الوصول إلى الاستدعاءات الموجودة في النطاقات المُصرَّح بها فقط. صفحات https فقط هي المدعومة لإجراءات المصادقة مع مجموعة SDK للغة JavaScript من Facebook.
فيما يتعلق بعمليات دمج مجموعة JSSDK التي تم إنشاؤها حتى 10 أغسطس 2021، فقد تمت إعادة تعبئة هذه القائمة بالقيم استنادًا إلى الاستخدام الحالي. لا توجد أي إجراءات إضافية مطلوبة.
أما بالنسبة لعمليات الدمج الجديدة التي تمت بعد 10 أغسطس 2021، فيتعين عليك إضافة القيم إلى هذه القائمة.
إذا وجدت أن حقل نطاق مجموعة JSSDK الخاص بتطبيقك يتضمن عناوين url تبدأ بالرمز *.، فيُرجى تغييرها بحيث يتم استبدالها بعناوين url مطلقة للحصول على درجة أعلى من الأمان.
كيفية عمل التحقّق من إعادة التوجيه عنوان URI
تتم هجمات إعادة التوجيه المفتوحة عندما يحاول أحد المحتالين توفير معلمة redirect_uri غير مُصرح بها في طلب تسجيل الدخول، الأمر الذي يؤدي إلى احتمالية تسرب المعلومات الحساسة مثل رمز الوصول عبر سلسلة الاستعلام أو جزء من مُحدِد URI لإعادة التوجيه.
فيما يتعلق بعمليات دمج الويب المخصصة، يجب عليك توفير محددات URI مُصرَح بها لإعادة التوجيه في إعدادات تطبيقك لتجنُّب تلك الهجمات. وأثناء تنفيذ طلب تسجيل الدخول، سيتم فحص المعلمة redirect_uri في مقابل الإدخالات في هذه القائمة. يجب أن يكون محدد URI الكامل مطابقًا تمامًا، بما في ذلك جميع المعلمات، باستثناء معلمة الحالة الاختيارية، والتي يتم تجاهل قيمتها.
المتصفحات داخل التطبيق ومجموعة SDK للغة JavaScript
تعتمد مجموعة SDK للغة JavaScript بشكل طبيعي على الإشعارات المنبثقة والاستدعاءات لإكمال تسجيل الدخول. وقد يفشل هذا الأمر بالنسبة إلى بعض المتصفحات داخل التطبيق التي تمنع الإشعارات المنبثقة. عندما يحدث ذلك، ستحاول مجموعة SDK إعادة التوجيه تلقائيًا، من خلال رمز وصول، إلى الصفحة التي استدعتها. ويمكن فقط إجراء إعادة التوجيه هذه بأمان إذا كان محدد URI الكامل للصفحة مدرجًا في ضمن محددات URI الصالحة لإعادة توجيه OAuth.
إذا كانت سيناريوهات المتصفح داخل التطبيق ذات أهمية بالنسبة إلى تطبيق الويب لديك، فيجب إضافة نطاق صفحة تسجيل الدخول إلى النطاقات المسموح بها، وأيضًا إضافة محدد URI الكامل التابع لها (بما في ذلك معلمات المسار والاستفسار) إلى محددات URI صالحة لإعادة توجيه OAuth. إذا كانت لديك العديد من التركيبات الفريدة في محددات URI حيث يتم تسجيل الدخول إلى تطبيقك، فيمكنك تحديد fallback_redirect_uri يدويًا كخيار في استدعاء FB.login() بحيث تحتاج فقط إلى إضافة هذا الإدخال الأوحد إلى قائمة محددات URI الصالحة لإعادة التوجيه OAuth.
تأمين إعدادات تطبيق Facebook
يمكنك تمكين و/أو تعطيل أي حالات دفق مصادقة لا يستخدمها التطبيق لتقليل فرص التعرض للهجمات.
استخدِم رموز وصول قصيرة الأجل يتم إنشاؤها بواسطة الرمز البرمجي لدى العملاء بدلاً من رموز الوصول التي يتم إنشاؤها بواسطة العميل أو رموز الوصول طويلة الأجل من جانب الخادم. يتطلب دفق رمز الوصول قصير الأجل الذي يتم إنشاؤه بواسطة الرمز أن يقوم خادم التطبيق باستبدال الرمز بواسطة برمز وصول، وهي طريقة أكثر أمنًا من الحصول على رمز وصول في المتصفح. يجب أن تتجه التطبيقات إلى استخدام هذا الدفق متى أمكن لتصبح أكثر أمنًا، إذا قام تطبيق ما بتمكين هذا الدفق فقط، فلن تتمكن البرامج الضارة التي تعمل على كمبيوتر المستخدم من الحصول على رمز الوصول وإساءة استخدامه. تعرَّف على المزيد في وثائق رموز الوصول.
تعطيل تسجيل دخول العميل باستخدام OAuth إذا لم يكن تطبيقك يستخدمه. تسجيل دخول العميل عبر OAuth هو مفتاح تمكين/تعطيل استخدام حالات دفق رمز عميل OAuth. إذا لم يكن تطبيقك يستخدم أي حالات دفق OAuth للعميل، والتي تشتمل على دفق مجموعات SDK لتسجيل دخول فيسبوك، يجب تعطيل هذا الدفق. يرجى العلم أنه على الرغم من ذلك، لا يمكنك طلب أذونات لرمز الوصول إذا قمت بتعطيل تسجيل الدخول باستخدام OAuth للعميل. يمكن العثور على هذا الإعداد في قسم المنتجات > تسجيل دخول فيسبوك > الإعدادات في لوحة معلومات التطبيق.
تعطيل دفق OAuth للويب أو تحديد قائمة سماح لإعادة التوجيه. تعمل إعدادات تسجيل الدخول على الويب عبر OAuth على تمكين أي حالات دفق رمز عميل OAuth تستخدم مربع حوار تسجيل دخول فيسبوك على الويب لإعادة الرموز إلى موقع الويب الخاص بك. يوجد هذا الإعداد في قسم المنتجات > تسجيل دخول فيسبوك > الإعدادات في لوحة معلومات التطبيق. يمكنك تعطيل هذا الإعداد في حالة عدم إنشاء دفق تسجيل دخول ويب مُخصَّص أو استخدام مجموعة SDK لتسجيل دخول فيسبوك على الويب.
إنفاذ بروتوكول HTTPS. يتطلب هذا الإعداد توفير بروتوكول HTTPS لعمليات إعادة توجيه OAuth، ويتطلب إجراء استدعاءات مجموعة SDK للغة JavaScript من Facebook التي تعمل على إرجاع رمز وصول من صفحات HTTPS فقط، أو تطلبه. وتتضمن جميع التطبيقات الجديدة التي تم إنشاؤها اعتبارًا من مارس 2018 هذا الإعداد افتراضيًا، ويجب التخطيط لترحيل أي تطبيقات موجودة لاستخدام عناوين URL لبروتوكولات HTTPS فقط بحلول 6 أكتوبر 2018. توفر معظم خدمات الاستضافة السحابية الكبرى للتطبيقات عمليات تكوين مجانية وتلقائية لشهادات TLS لتطبيقاتك. إذا كنت تستضيف تطبيقك ذاتيًا أو كانت خدمة الاستضافة التي تستخدمها لا توفر HTTPS بشكل افتراضي، فيمكنك الحصول على شهادة مجانية لنطاقك (نطاقاتك) من Let's Encrypt.
تعطيل دفق OAuth للمتصفح المُضمَّن إذا لم يكن تطبيقك يستخدمه. تقوم بعض التطبيقات الأصلية لأجهزة الكمبيوتر والأجهزة المحمولة بمصادقة المستخدمين عن طريق دفق OAuth للعميل داخل طريقة عرض ويب مضمنة. إذا لم يكن تطبيقك يقوم بذلك، فيمكنك تعطيل هذا الإعداد من قسم المنتجات > تسجيل دخول فيسبوك > الإعدادات في لوحة معلومات التطبيق.
تعطيل حالات دفق تسجيل الدخول الموحد عبر الهواتف المحمولة إذا لم يكن تطبيقك يستخدمها. وإذا كان تطبيقك لا يستخدم إعداد تسجيل الدخول لنظام iOS أو Android، فيمكنك تعطيل إعداد "تسجيل الدخول الموحد" في القسمين الإعدادات > أساسي في نظامي iOS وAndroid.
تحتوي لوحة معلومات التطبيق على عدد من الإعدادات الإضافية التي تُتيح للمطورين تحصين الثغرات التي يمكن مهاجمتها والتي قد تؤدي لمشكلات أمنية حال اختراقها:
- أساسي > المفتاح السري للتطبيق إذا تم اختراق المفتاح السري لتطبيقك، يمكنك إعادة تعيينه من هنا.
- أساسي > نطاقات التطبيق استخدِم هذا الإعداد لتأمين النطاقات والنطاقات الفرعية التي يمكن استخدامها لتنفيذ تسجيل دخول فيسبوك نيابةً عن تطبيقك.
- إعدادات متقدمة > نوع التطبيق عند إنشاء تطبيق أصلي للهواتف المحمولة أو لأجهزة الكمبيوتر يحتوي على المفتاح السري للتطبيق بداخله، قم بتعيين ذلك إلى
Native/Desktopلحماية تطبيقك من إلغاء التحويل البرمجي وسرقة المفتاح السري لتطبيقك. - إعدادات متقدمة > قائمة السماح لعناوين IP للخادم تحدد قائمة بعناوين IP التي يمكن إجراء استدعاءات واجهة Graph API من خلالها باستخدام المفتاح السري لتطبيقك. وستفشل كل استدعاءات Graph API التي تتم باستخدام المفتاح السري لتطبيقك من خارج هذه القائمة. ولن تتأثر بهذا الإعداد الاستدعاءات التي تتم باستخدام رموز وصول المستخدم.
- إعدادات متقدمة > تحديث إعدادات قائمة السماح لعناوين IP تعمل على تأمين عناوين IP التي يمكن من خلالها لأي شخص تعديل إعدادات التطبيق هذه إلى نطاق معين. ويجب توخي الحذر عند تعيين قائمة سماح لعناوين IP في اتصال إنترنت منزلي واسع النطاق. إذا تغير عنوان IP، فلن تتمكن من تعديل إعدادات تطبيقك.
- إعدادات متقدمة > البريد الإلكتروني لإشعارات التحديث يرسل إشعارات لعنوان بريد إلكتروني متى يطرأ تغيير على إعدادات التطبيق بلوحة معلومات التطبيق.
- إعدادات متقدمة > أمان النشر ببث لعنوان URL سيؤدي ذلك إلى إيقاف نشر تطبيقك لأي عناوين URL لا تقود إلى النطاق الخاص بالتطبيق. قد لا يكون ذلك مفيدًا دائمًا، وخاصةً إذا كنت تعرف أن تطبيقك سينشر روابط لمواقع أخرى.