مكافحة الاحتيال وإساءة الاستخدام

نحرص في Google Play على ضمان السلامة لكل من المستخدمين والمطوّرين. ندرك أنّ بناء نشاط تجاري ناجح في مجال التطبيقات يعتمد على منصة موثوقة تحمي عائد استثمارك من خلال الدفاع بشكل استباقي ضد الجهات المسيئة.

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

تحسين ميزات الحماية

يمكن أن تحدّ واجهات برمجة التطبيقات والأدوات التالية من المخاطر في تطبيقك:

• واجهة Voided Purchases API: لإبطال إمكانية الوصول إلى الطلبات الملغاة
• معرّف الحساب المموه: يساعد في رصد الحالات التي تجري فيها أجهزة متعددة عمليات شراء من الحساب نفسه خلال فترة قصيرة.
• الاستهلاك من الخلفية: أدوات مثل Purchases.products:consume تنقل منطق النشاط التجاري إلى الخلفيات الآمنة، ما يمنع التلاعب من جهة العميل. بالإضافة إلى استخدام واجهات برمجة التطبيقات هذه، ننصحك باتّباع أفضل الممارسات التالية لتعزيز أمان عمليات الدمج ضد الوصول غير المصرّح به.

منع تزييف الموقع الجغرافي

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

نقل المنطق الحسّاس إلى الخلفية

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

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

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

إثبات ملكية عمليات الشراء قبل منح الأذونات

تُعد عملية التحقّق من عمليات الشراء وإقرارها حالة خاصة من البيانات الحساسة والمنطق الذي يجب التعامل معه في الخلفية. بعد أن يجري المستخدم عملية شراء، عليك اتّخاذ الإجراءات التالية:

• أرسِل الرمز المميز purchaseToken المقابل إلى الخلفية. وهذا يعني أنّه عليك الاحتفاظ بسجلّ لجميع قيم purchaseToken لجميع عمليات الشراء.
• تأكَّد من أنّ قيمة purchaseToken لعملية الشراء الحالية لا تتطابق مع أي قيم purchaseToken سابقة، لأنّ purchaseToken فريد على مستوى العالم، لذا يمكنك استخدام هذه القيمة بأمان كمفتاح أساسي في قاعدة البيانات.
• استخدِم نقطتَي النهاية Purchases.products:get أو Purchases.subscriptionsv2:get في Google Play Developer API للتحقّق من Google من أنّ عملية الشراء قانونية.
• إذا كنت تعتقد أنّ عملية الشراء قانونية ولم يتم استخدامها أو معالجتها في السابق، واجتاز المستخدم جميع عمليات التحقّق من الأهلية والاحتيال، يمكنك بعد ذلك منح المستخدم إذن الوصول إلى المنتج داخل التطبيق أو الاشتراك بأمان.
  • عمليات التحقّق من الأهلية وإساءة الاستخدام: التحقّق من أنّ المستخدم لا يزال مؤهلاً للحصول على السلعة. إذا كنت قد أعددت مسار الفوترة باستخدام obfuscatedAccountId أو obfuscatedProfileId، تأكَّد من أنّ عملية ربط عملية الشراء تتطابق مع حساب المستخدم المتوقّع في نظامك. إجراء أي عمليات تحقّق إضافية من إساءة الاستخدام أو المخاطر أو الأمان يتطلبها الخلفية.
  • عمليات ردّ الأموال الصريحة لعمليات الشراء غير الشرعية: إذا لم تستوفِ عملية الشراء عمليات التحقّق من صحة البيانات أو عمليات التحقّق من إساءة الاستخدام، لا تمنح المستخدم إذن الوصول. بدلاً من السماح بردّ الأموال تلقائيًا بسبب عدم الإقرار بعملية الشراء (وهو أمر غير واضح لأنّه يمكن أن يحدث أيضًا بسبب انتهاء المهلة المحدّدة للمعالجة)، يمكنك ردّ الأموال المدفوعة مقابل عملية الشراء بشكل صريح باستخدام نقطة النهاية Orders:refund (أو واجهة برمجة تطبيقات مشابهة في Play Developer API) مع ضبط المَعلمة revoke على true. يضمن ضبط المَعلمة revoke إبطال إذن الوصول، وبالتالي لن يكون لدى المستخدم إذن بالوصول إلى المنتج الذي تم شراؤه، كما يقدّم إشارة واضحة إلى Google Play بأنّ المطوّر رفض عملية الشراء.
• بالنسبة إلى الاشتراكات، عند ضبط linkedPurchaseToken في Purchases.subscriptionsv2:get، عليك أيضًا إزالة linkedPurchaseToken من قاعدة البيانات وإلغاء الإذن الممنوح إلى linkedPurchaseToken لضمان عدم حصول عدة مستخدمين على الإذن نفسه.
• يجب منح الإذن فقط عندما تكون حالة الشراء PURCHASED، ويجب التأكّد من التعامل مع عمليات الشراء التي تكون حالتها PENDING بشكل صحيح. في حال حدوث ارتفاع كبير في عدد عمليات الشراء التي تم إلغاؤها، قد تكون تمنح المستخدمين أذونات الوصول عندما تكون حالة عملية الشراء لا تزال "في انتظار المراجعة". يمكنك العثور على مزيد من المعلومات في مقالة التعامل مع المعاملات المعلّقة.

• بعد منح الإذن، إذا أردت استهلاك منتج قابل للاستهلاك والإقرار به، استخدِم طريقة Purchases.products:consume في Play Developer API على خادم الخلفية الآمن. للإقرار بمنتج غير قابل للاستهلاك أو اشتراك، عليك استدعاء نقطة نهاية Play Developer API ذات الصلة، إما Purchases.products:acknowledge أو Purchases.subscriptions:acknowledge على خادم الخلفية الآمن. ويجب تقديم إقرار لأنّه يُعلم Google Play بأنّه تم منح المستخدم إذن الوصول إلى ما اشتراه. يجب الإقرار بإتمام عملية الشراء فور منح الإذن للمستخدم.

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

لمزيد من المعلومات حول الإقرار بعمليات الشراء والاستهلاك، اطّلِع على مقالة معالجة عمليات الشراء.