נלחמים בהונאות ובהתנהלות פוגעת

אנחנו ב-Google Play מחויבים לשמור על הבטיחות של המשתמשים והמפתחים. אנחנו מבינים שפיתוח עסק אפליקציות משגשג מסתמך על פלטפורמה מהימנה – פלטפורמה שמגנה באופן יזום מפני גורמים זדוניים כדי להבטיח את ההחזר על ההשקעה שלכם.

במאמר הזה מוסברות המלצות למניעת מתקפות על מערכת החיוב ולהפחתת ההשפעה של ניצול לרעה באפליקציה.

שיפור ההגנות

הכלים וממשקי ה-API הבאים יכולים לצמצם את הסיכונים באפליקציה:

  • ‫Voided Purchases API: ביטול הגישה להזמנות שבוטלו.
  • מזהה חשבון שעבר טשטוש: עוזר לזהות מקרים שבהם כמה מכשירים מבצעים רכישות באותו חשבון בפרק זמן קצר.
  • צריכה בקצה העורפי: כלים כמו Purchases.products:consume מעבירים את הלוגיקה העסקית לקצוות העורפיים המאובטחים שלכם, וכך מונעים שינויים בצד הלקוח. בנוסף לשימוש בממשקי ה-API האלה של הפלטפורמה, כדאי לאמץ את השיטות המומלצות הבאות כדי לאבטח עוד יותר את השילובים מפני גישה לא מורשית.

מניעת זיוף המיקום

ב-Google Play יש אמצעי הגנה מובנים שמונעים מגורמים זדוניים להשתמש במיקומים כוזבים כדי לנצל הבדלים בין מטבעות אזוריים (פעולה שנקראת גם זיוף מיקום), לנצל לרעה מבצעים ותמריצים על מינויים ולנסות לבצע הונאות בכרטיסי מתנה.

העברת לוגיקה רגישה לקצה העורפי

ככל שעיצוב האפליקציה מאפשר, כדאי להעביר נתונים רגישים ולוגיקה לשרת backend שאתם שולטים בו. ככל שיש יותר נתונים ולוגיקה במכשיר קצה, כך הוא חשוף יותר לשינויים או לפעולות לא מורשות.

לדוגמה, משחק שחמט אונליין צריך לאמת את כל המהלכים בקצה העורפי, במקום להניח שהקצה הקדמי תמיד שולח מהלכים חוקיים.

בנוסף, אם תמצאו נקודות חולשה או בעיות אבטחה, בהתאם לעיצוב המערכת, יכול להיות שיהיה קל יותר לנפות באגים, לתקן ולפרוס עדכונים בקצה העורפי ולא בקצה הקדמי.

אימות רכישות לפני הענקת הרשאות

מקרה מיוחד של נתונים רגישים ולוגיקה שצריך לטפל בהם בקצה העורפי הוא אימות ואישור של רכישות. אחרי שמשתמש מבצע רכישה, צריך לבצע את הפעולות הבאות:

  • שולחים את ה-purchaseToken התואם לקצה העורפי. כלומר, צריך לשמור תיעוד של כל הערכים של purchaseToken לכל הרכישות.
  • מוודאים שהערך של purchaseToken עבור הרכישה הנוכחית לא תואם לאף ערך קודם של purchaseToken. הערך של purchaseToken הוא ייחודי באופן גלובלי, כך שאפשר להשתמש בו בבטחה כמפתח ראשי במסד הנתונים.
  • כדי לוודא עם Google שהרכישה לגיטימית, צריך להשתמש בנקודות הקצה Purchases.products:get או Purchases.subscriptionsv2:get בממשק API של Google Play למפתחים.
  • אם לדעתכם הרכישה לגיטימית, לא נעשה בה שימוש או שהיא לא עברה עיבוד בעבר, והמשתמש עבר את כל הבדיקות שלכם לגבי זכאות והונאה, תוכלו להעניק בבטחה זכאות לפריט באפליקציה או למינוי.
    • בדיקות זכאות וניצול לרעה: מוודאים שהמשתמש עדיין זכאי לפריט. אם הגדרתם את רצף פעולות החיוב באמצעות obfuscatedAccountId או obfuscatedProfileId, צריך לוודא שהמיפוי של הרכישה תואם לחשבון המשתמש הצפוי במערכת שלכם. מבצעים בדיקות נוספות של ניצול לרעה, סיכון או אבטחה שנדרשות על ידי הקצה העורפי.
    • החזרים כספיים מפורשים על רכישות לא חוקיות: אם הרכישה נכשלת בבדיקות האימות או בבדיקות למניעת ניצול לרעה, אל תעניקו את ההרשאה ואל תאשרו את הרכישה או תצרכו אותה. במקום לאפשר החזר כספי אוטומטי על הרכישה בגלל חוסר אישור (שמקורו לא ברור כי הוא יכול לנבוע גם מפסק זמן של העיבוד), צריך לבטל את הרכישה ולהחזיר את הכסף באופן מפורש באמצעות נקודת הקצה purchases.subscriptionsv2:revoke (עם "fullRefund": {}) למינויים, או נקודת הקצה Orders:refund עם הפרמטר revoke שמוגדר לערך true למוצרים חד-פעמיים. ביטול הרכישה מבטיח שלמשתמש אין יותר הרשאה לרכישה, ומספק ל-Google Play סימן ברור לכך שהרכישה נדחתה על ידי המפתח.
  • במינויים, כש-linkedPurchaseToken מוגדר ב-Purchases.subscriptionsv2:get, צריך גם להסיר את linkedPurchaseToken ממסד הנתונים ולבטל את ההרשאה שניתנה ל-linkedPurchaseToken כדי לוודא שלריבוי משתמשים אין הרשאה לאותה רכישה.
  • צריך להעניק זכאות רק כשמצב הרכישה הוא PURCHASED, וחשוב לטפל ברכישות ממתינות בצורה נכונה. אם יש עלייה פתאומית במספר הרכישות שבוטלו, יכול להיות שאתם מעניקים זכויות כשהרכישה עדיין במצב 'בהמתנה'. מידע נוסף זמין במאמר טיפול בעסקאות בהמתנה.

  • אחרי הענקת הרשאה, אם אתם רוצים לצרוך ולאשר מוצר שניתן לצריכה, השתמשו ב-Play Developer API‏ Purchases.products:consume בשרת בק-אנד המאובטח שלכם. כדי לאשר מוצר שלא ניתן לצריכה או מינוי, צריך לבצע קריאה לנקודת הקצה ל-API הרלוונטית ל-Play Developer,‏ Purchases.products:acknowledge או Purchases.subscriptions:acknowledge, בשרת הבק-אנד המאובטח. חובה לאשר את הרכישה, כי האישור מודיע ל-Google Play שהמשתמש קיבל הרשאה לרכישה. צריך לאשר את הרכישה מיד אחרי שהמשתמשים מאשרים אותה.

    שימו לב שאפשר לאשר את הרכישה או להשתמש בה בצד הלקוח דרך האפליקציה, אבל ממשקי API בצד השרת מספקים הגנה נוספת מפני בעיות כמו קישוריות רשת לקויה ופעילות זדונית. לדוגמה, נניח שמשתמש רכש פריט מהאפליקציה, אבל איבד את החיבור לרשת בזמן שהרכישה נבדקה. בלי אישור מהשרת, יכול להיות שהם יצטרכו להתחבר שוב דרך האפליקציה כדי להשלים את תהליך האישור. אחרת, אם המשתמש לא יתחבר מחדש תוך שלושה ימים, הוא יקבל החזר כספי באופן אוטומטי כי הרכישה לא אושרה. אישור השרת מונע את התרחיש הזה על ידי שליחת אישור ברגע ש-Google Play מודיעה לשרת שהרכישה תקינה.

מידע נוסף על אישור רכישה וצריכה זמין במאמר בנושא עיבוד רכישות.

הגנה על תוכן לא נעול

כדי למנוע ממשתמשים זדוניים להפיץ מחדש את התוכן שפתחתם, אל תכללו אותו בקובץ ה-APK. במקום זאת, צריך לבצע אחת מהפעולות הבאות:

  • להשתמש בשירות בזמן אמת כדי להעביר את התוכן, כמו פיד תוכן. העברת תוכן דרך שירות בזמן אמת מאפשרת גם לשמור על עדכניות התוכן.
  • להשתמש בשרת מרוחק כדי להעביר את התוכן. כשמספקים תוכן משרת מרוחק או משירות בזמן אמת, אפשר לאחסן את התוכן שנפתח בזיכרון המכשיר או בכרטיס ה-SD של המכשיר. אם אתם מאחסנים תוכן בכרטיס SD, הקפידו להצפין את התוכן ולהשתמש במפתח הצפנה ספציפי למכשיר.

זיהוי וטיפול ברכישות מבוטלות

רכישות מבוטלות הן רכישות שבוטלו או שבוצע בהן החזר כספי. אם רכישה שבוטלה העניקה בעבר למשתמש פריטים באפליקציה או תוכן אחר, אתם יכולים להשתמש ב-Voided Purchases API כדי לקבל את הסיבה לביטול הרכישה, יחד עם כל תוכן משויך שאתם יכולים להחזיר.

אפשר לבטל רכישות של פריטים באפליקציה ומינויים ממגוון סיבות, כולל:

  • רכישה בוטלה על ידי המשתמש, על ידי המפתח או על ידי Google (כולל רכישות שבוטלו אוטומטית ולא אושרו). במינויים, שימו לב שהכוונה היא לביטול הרכישה של המינוי, ולא לביטול המינוי עצמו.
  • בוצע החזר כספי על רכישה.

  • מפתח האפליקציה מבטל הזמנה של משתמש או מבצע החזר כספי, ומסמן את האפשרות "ביטול" במסוף. על סמך הסיבה לביטול הרכישה, ובהתחשב בנתוני התנהגות המשתמשים הקודמים, תוכלו להחליט על דרך פעולה. מומלץ להטמיע אחת או יותר מהפעולות הבאות:

  • ביצוע החזרות: כשמבטלים רכישה, אפשר להחזיר פריטים שלא נעשה בהם שימוש כאילו הם מעולם לא נרכשו. לדוגמה, אם רכישה של כסף וירטואלי במשחק בוטלה, אתם יכולים להחזיר את המטבע שכבר הוענק למשתמש. אם המשתמש כבר הוציא את המטבע, כדאי להגדיר את יתרת המטבע כערך שלילי ולהגביל את הפעילות באפליקציה ואת הרכישות העתידיות עד שיתרת המטבע תהיה חיובית.

  • הטמעה של מערכת פסילות: כדאי לשקול נקיטת פעולות פחות דרסטיות כלפי משתמשים שמפרים את המדיניות בפעם הראשונה, כמו הצגת אזהרות באפליקציה. אם מדובר במפרים חוזרים, כדאי לשקול נקיטת צעדים חמורים יותר.

  • השבתה זמנית של רכישות: בדומה להטמעה של מספר פסילות, כדאי להשבית את הרכישות למשתמשים עם רכישות מבוטלות עד שתוכלו לבדוק לעומק למה הרכישות בוטלו.

  • השעיה זמנית או ביטול סופי של הגישה לאפליקציה: במקרים קיצוניים של פעילות זדונית חוזרת, כדאי לשקול השעיה זמנית או ביטול סופי של הגישה לאפליקציה.

  • שולחים קריאות תכופות ל- Voided Purchases API: כשמזהים רכישה מבוטלת אחת או יותר, כדאי לשלוח קריאות תכופות יותר ל-Voided Purchases API כדי להחזיר את הרכישות לפני שהמשתמש יוכל לצרוך אותן. מידע נוסף על המכסות של Voided Purchases API זמין במאמרי העזרה של Voided Purchases API.

עוזרים ל-Google לזהות הונאות לפני שהן מתרחשות

חלק מסוגי ההונאות קשורים למשתמשים זדוניים שיוצרים כמה חשבונות Google וחשבונות בתוך האפליקציה כדי להסתיר את הפעילות שלהם.

כדי לעזור ל-Google למפות חשבונות Google לחשבונות באפליקציה, משתמשים בשיטות setObfuscatedAccountId ו-setObfuscatedProfileId בכלי ליצירת BillingFlowParams.

‫Google משתמשת בנתונים האלה כדי לזהות התנהגות חשודה ולחסום סוגים מסוימים של עסקאות שמקורן בתרמית לפני שהן מסתיימות.

נקיטת פעולות נגד הפרה של סימנים מסחריים וזכויות יוצרים

אם אתם משתמשים בשרת מרוחק כדי להציג או לנהל תוכן, האפליקציה צריכה לאמת את מצב הרכישה של התוכן שהגישה אליו נפתחה בכל פעם שמשתמש ניגש לתוכן. כך תוכלו לבטל את השימוש כשצריך ולצמצם את הפיראטיות. אם אתם רואים שהתוכן שלכם מופץ מחדש ב-Google Play, חשוב לפעול במהירות ובנחישות. פרטים נוספים זמינים בדף שאלות נפוצות בנושא זכויות יוצרים במרכז העזרה בנושא זכויות יוצרים.